Projekte anlegen

Jedes Projekt beginnt im Assistenten unter Neues Projekt - oder, wenn dir das lieber ist, über die Kommandozeile oder den MCP-Server. Die drei Schritte erklärt Dein erstes Projekt. Hier geht es um den spannenden Teil: was im neuen Projektordner landet.

Envoryx legt den Ordner unter /projects an, und er gehört PUID:PGID. Ein Template, ein Repository oder eine hochgeladene Website brauchen ihn leer oder noch gar nicht vorhanden, weil sie ihn von Grund auf füllen. Ein Projekt ohne all das ist anders: Zeig damit auf einen Ordner, in dem schon Code liegt, und Envoryx übernimmt die Dateien so, wie sie sind. So bekommt eine Anwendung, die du schon auf dem Host hast, am schnellsten einen eigenen Stack.

Aus einem Template

Ein Template baut dir eine frische Anwendung. Das passiert in einem kurzlebigen Container aus dem Runtime-Image des Projekts, als Projektbesitzer, und wo das Framework eine Datenbank braucht, wird es gleich mit der des Projekts verbunden. Downloads landen in einem geteilten Paket-Cache - darum steht dein zweites Laravel-Projekt deutlich schneller als das erste.

Runtime	Templates	Nach dem Anlegen
PHP	Laravel	artisan migrate im Bereich Aktionen ausführen.
PHP	Symfony (Skeleton plus webapp-Pack)	doctrine:migrations:migrate ausführen.
PHP	WordPress	Die Seite öffnen, um den WordPress-Installer zu starten.
PHP	Drupal (mit Drush)	Die Seite öffnen oder drush site:install ausführen - es gibt das Admin-Passwort aus.
PHP	TYPO3	typo3 setup im Bereich Aktionen ausführen - es gibt das Admin-Passwort aus - oder den Web-Installer auf der Seite nehmen.
PHP	Shopware	Shopware system:install im Bereich Aktionen ausführen; der Login ist admin / shopware.
PHP	Craft CMS	craft install ausführen oder /admin/install öffnen.
Node.js	Vite + React (TypeScript), Next.js (App Router, TypeScript), Nuxt	Der Dev-Server antwortet unter der Projekt-URL.
Python	Django, Flask, FastAPI	Django: manage.py migrate ausführen.
Go	Go (net/http), Gin, Echo	air baut den Server bei jeder Änderung neu.
Ruby	Rails, Rails (API only), Sinatra	Rails: Envoryx führt rails db:prepare aus, sobald das Projekt läuft; hast du es gestoppt angelegt, startest du es im Bereich Aktionen.
Java	Spring Boot, Quarkus REST	Der Server antwortet unter der Projekt-URL; der erste Build füllt den Maven-Cache.
.NET	ASP.NET Core Web API, ASP.NET Core MVC, ASP.NET Core Razor Pages, Blazor Web App	dotnet watch übernimmt Änderungen per Hot Reload.

Die CMS-Templates - Drupal, TYPO3, Shopware und Craft CMS - kommen ohne Datenbank nicht aus, deshalb wählt der Assistent gleich eine vor. In der Galerie des Assistenten stehen die beliebten Vorlagen vorn, den Rest findest du über Alle Vorlagen zeigen, die Suche und den Runtime-Filter. Die Einzelheiten zu jedem Template stehen auf der Seite der jeweiligen Runtime.

Aus einem Git-Repository

Wähl unter Oder starte mit Git-Repository und gib die Repository-URL an - https://…, git@host:pfad.git oder ssh://… -, dazu einen Branch, falls du nicht den Standard-Branch willst. Envoryx klont das Repository in den leeren Projektordner, auch hier in einem kurzlebigen Container als Projektbesitzer. Sag Envoryx noch, was im Repository läuft (PHP-Anwendung, Node.js-Anwendung und so weiter); hast du dem Projekt noch keinen Namen gegeben, übernimmt es den Namen des Repositorys.

Ein privates Repository über HTTPS braucht ein Zugriffstoken und, wenn dein Host das verlangt, einen Benutzernamen. Bei GitHub reicht ein Fine-grained-Token mit Contents: read, bei GitLab nimmst du den Benutzernamen oauth2 plus Token.

Für SSH-Repositories verwendet Envoryx seinen Deploy-Key. Kopier den öffentlichen Schlüssel aus Einstellungen → Git-Deploy-Key (oder aus dem Bereich Git des Projekts) als Read-only-Deploy-Key ins Repository, bevor du das Projekt anlegst. Der Schlüssel selbst wird nie in die Container deines Projekts eingebunden.

Eine Option verdient noch einen Satz: envoryx.yml des Repositorys verwenden, standardmäßig an. Bringt das Repository eine envoryx.yml mit, bestimmt diese Datei Laufzeiten, Dienste, Domains, Umgebung, Worker und Cron-Jobs, und der Rest des Assistenten zählt nur, wenn es keine gibt. So gibst du ein Projekt am einfachsten an jemand anderen weiter.

Für einen Node.js-Dev-Server muss der Assistent Skript und Preset raten, bevor er das Repository sieht. Sobald der Klon da ist, schaut Envoryx in dessen package.json: Fehlt dort das Skript, das der Assistent gewählt hat, nimmt es dev oder start (bei einem Produktions-Build start oder preview) und das Preset des Frameworks, das es in den Abhängigkeiten findet, also Next.js, Nuxt oder Vite, sonst Sonstiges. Die Abhängigkeiten selbst installiert der Dev-Server bei seinem ersten Start aus dem Lockfile des Repositorys, wie die Node.js-Seite erklärt.

Danach holt der Bereich Git neue Commits, wechselt Branches (ein Branch, den es nur auf dem Remote gibt, wird zu einem lokalen, der ihm folgt; wurde er nach dem Klonen gepusht, hol vorher einmal die Commits) und zeigt dir den Status. Zieht das Repository um, änderst du dort die Repository-URL; beim Speichern zeigt auch das origin des Checkouts auf die neue Adresse, der nächste Pull kommt also von der richtigen Stelle.

Eine bestehende Website importieren

Bestehende Website unter Oder starte mit ist für Seiten, die schon woanders leben - beim alten Shared Hoster, in einem Backup, als FTP-Download. Lad die Dateien als ZIP- oder tar-Archiv hoch (.zip, .tar.gz, .tgz oder ein einfaches .tar), und wenn es einen gibt, einen Datenbank-Dump (.sql oder .sql.gz). Ein einzelner umschließender Ordner wie public_html/ fällt automatisch weg. Envoryx schaut sich das Archiv an und füllt den Rest des Assistenten mit dem, was es gefunden hat. Ändern kannst du alles davon trotzdem.

Ein aus Envoryx heruntergeladenes Backup geht hier auch: Statt es als Website zu analysieren, stellt Envoryx es in ein neues Projekt wieder her, mit den Einstellungen, mit denen es gemacht wurde.

Das erkennt es:

Seite	Erkannt an	Vorschlag
WordPress	wp-config.php, wp-includes/version.php	PHP bis zu dem, was die WordPress-Version unterstützt, mysqli, MariaDB
Laravel	artisan + laravel/framework	Document Root public, Datenbank aus .env
Symfony	bin/console + symfony/framework-bundle	Document Root public (web bei Symfony 2/3), Datenbank aus DATABASE_URL
Drupal	core/lib/Drupal.php (auch unter web/), Drupal 7	Document Root, PHP nach Hauptversion
TYPO3	typo3/sysext, typo3/cms-core	Document Root public im Composer-Modus
Joomla	configuration.php mit JConfig	PHP nach Version, mysqli
Shopware, Craft CMS, andere Composer-Apps	composer.json	PHP aus require.php, ext-*-Erweiterungen
Einfaches PHP	.php-Dateien	Document Root dort, wo index.php liegt; die Dateien, die eine Datenbankverbindung öffnen
Statische Seite, Node.js, Python, Go, Ruby, Java, .NET	index.html, package.json, manage.py/requirements.txt, go.mod, Gemfile, pom.xml/build.gradle, .sln/.slnx/.csproj oben im Projekt	die passende Runtime

Bei PHP nimmt Envoryx die neueste Version, die es anbietet und die composer.json und die CMS-Version zulassen. Nutzt der Code Funktionen, die PHP 8 entfernt hat, bekommst du PHP 7.4. Und liegt eine .htaccess im Document Root, schlägt es Apache vor - der einzige Webserver, der sie liest.

Konfiguration an Envoryx anpassen ist standardmäßig an und verbindet die Seite mit der Projektdatenbank. WordPress liest in wp-config.php die eingespeisten Datenbankvariablen. Drupal, TYPO3 und Joomla bekommen die Verbindung in ihre Konfiguration geschrieben. WordPress, Drupal und TYPO3 bekommen außerdem dieselben Zeilen wie ein neues Projekt von ihnen: Adresse, vertrauenswürdige Hosts, Redis und Mail richten sich nach dem Projekt, wie die PHP-Seite erklärt. Laravel, Symfony und Shopware brauchen gar nichts, weil die eingespeisten DB_* und DATABASE_URL ihre .env überschreiben. Symfony bekommt allerdings eine Zeile: Die .env der Seite nennt die Serverversion meist in DATABASE_URL, die eingespeiste URL nicht, und Doctrine würde mit Invalid platform version abbrechen. Deshalb liest config/packages/doctrine.yaml dann server_version aus DB_SERVER_VERSION, wie im Symfony-Template, außer die Datei legt selbst eine Version fest. Diese Datei ändert Envoryx direkt, ohne Kopie daneben, weil Symfony eine Kopie in config/packages als Konfiguration laden würde. Jede andere Datei, die Envoryx ändert, behält ihr Original direkt daneben als <name>.envoryx-original.php - und das antwortet mit 404, die alten Zugangsdaten werden also nie ausgeliefert. Eines kann es dir nicht abnehmen: WordPress selbst und wp-admin folgen der neuen Adresse, aber die Links in Beiträgen und Seiten stehen mit der alten in der Datenbank. WP-CLI steckt im PHP-Image, also erledigt das wp search-replace 'https://old-blog.example' 'https://old-blog.test' im PHP-Terminal.

Der Dump wird importiert, sobald die Container stehen. Anweisungen, die ihn an den alten Server binden - CREATE DATABASE, USE, Benutzer, Eigentümer, Rechte, Rollen -, werden übersprungen. Hosting-Panels und phpMyAdmin exportieren gern die GRANT- und CREATE USER-Zeilen des alten Benutzers, und die halten den Import nicht mehr auf. Eine MySQL-View, ein Trigger oder eine Routine verliert außerdem ihren DEFINER: Diesen Benutzer gab es nur auf dem alten Server, und MySQL würde das Objekt zwar anlegen, aber nicht ausführen. Ohne die Angabe gehört es dem Benutzer, der den Dump importiert. Mit dem Custom-Format von pg_dump klappt es nicht; exportier stattdessen reines SQL mit pg_dump --format=plain. Schlägt der Import fehl, wird das Projekt zurückgerollt, und der Upload bleibt für einen neuen Versuch liegen.

Uploads warten 24 Stunden. Ein Archiv darf bis zu 20 GiB groß sein und höchstens 64 GiB entpacken. Von der Kommandozeile geht das genauso:

envoryx import ./old-blog "Old Blog" --db old-blog.sql.gz --start
envoryx import backup.zip --php 8.2 --web nginx --no-adapt
envoryx import ./site --dry-run          # nur zeigen, was Envoryx erkennt

Bevor du auf Erstellen klickst

Der Schritt Erstellen zeigt den Plan - die Container, Volumes und Images, die Envoryx anlegen wird - und warnt dich, wenn etwas nicht aufgeht, etwa ein eingeschalteter Server, obwohl noch nichts die Anwendung erzeugt. Bevor irgendetwas läuft, fragt Envoryx die Registry nach dem aktuellen Build jedes Images im Plan. Ein anderes Projekt hat vielleicht einen älteren Build desselben Tags auf dem Host hinterlassen, und dem könnten Werkzeuge fehlen, auf die das aktuelle Envoryx setzt. Ohne Verbindung nimmt es das lokale Image. Hast du einmal gestartet, läuft das Anlegen auf dem Server bis zum Ende durch, auch wenn du den Browser-Tab schließt.