Umgebung und envoryx.yml

Einstellungen kommen über Umgebungsvariablen in deine Anwendung. Einen Teil davon setzt Envoryx selbst, der Rest gehört dir. Und wenn die ganze Projekteinrichtung neben deinem Code liegen soll, gibt es envoryx.yml.

Was Envoryx für dich setzt

Jeder Anwendungscontainer bekommt die Verbindungsdaten der Projektdienste als Umgebungsvariablen. Für die Datenbank sind das DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD und DATABASE_URL, für die übrigen Dienste REDIS_URL, MAIL_*, MAILER_DSN und so weiter (die Seiten zu Datenbanken und Diensten listen alle auf). Die meisten Frameworks lesen sie direkt - Laravel, Symfony und Rails brauchen für die Datenbank keine einzige Zeile in ihrer .env.

Dazu kommt ENVORYX_URL, die Adresse, unter der das Projekt antwortet. Schreib APP_URL=${ENVORYX_URL} in deine .env, dann zieht die Adresse mit, auch nach einer Umbenennung. Das Laravel-Template erledigt das für dich, und das Symfony-Template schreibt DEFAULT_URI=${ENVORYX_URL} in die .env.local. So zeigen Links in Mails und alles andere, was außerhalb einer Anfrage entsteht, aufs Projekt statt auf http://localhost.

Ein Projekt mit einem Node.js-Dev-Server bekommt außerdem ENVORYX_DEV_URL, die eigene Adresse des Dev-Servers (https://shop-dev.test für shop). Die ist für eine Backend-Seite gedacht, die ihre Skripte vom Dev-Server lädt. Laravel mit Vite ist der klassische Fall: Die Seite kommt von PHP, die Assets und der Socket fürs Hot Reload von Vite, und der Browser muss Vite über den Proxy erreichen, nicht unter http://0.0.0.0:5173. Die vite.config.js des Laravel-Templates nimmt ihren Origin und die Hot-Reload-Einstellungen aus der Variable, dort klappt das also von selbst; was du in einer mitgebrachten Laravel-App ergänzt, zeigt die PHP-Seite.

Deine eigenen Variablen

Im Bereich Umgebung (oder im Assistenten unter Erweiterte Einstellungen → Umgebung) stehen die Variablen, die du selbst anlegst. Sie erreichen jeden Container des Projekts und haben Vorrang vor dem, was Envoryx für die Dienste setzt. Markierst du eine Variable als Secret, wird ihr Wert in der Oberfläche maskiert; Betrachter und read-Tokens bekommen ihn gar nicht.

Meist liegt ohnehin schon eine .env herum, und .env importieren übernimmt sie. Füg sie ein oder wähl die Datei aus. Verstanden wird das Format, das Laravel, Symfony und docker compose schreiben (export, Kommentare, Anführungszeichen, ${ANDERE}-Verweise), und bevor irgendetwas gespeichert wird, siehst du, was gefunden wurde. Aufgelöst wird ein Verweis nur, wenn ANDERE weiter oben in derselben Datei steht. Einer, der woandershin zeigt, etwa APP_URL=${ENVORYX_URL} aus dem Laravel-Template, ist mit verweist auf markiert und nicht angehakt: Auflösen kann ihn nur der .env-Loader deiner Anwendung, als Projektvariable käme er wörtlich als dieser Text in den Containern an. Solche Zeilen lässt du in der .env.

Dabei ist der Import mit Absicht etwas wählerisch. Neue Variablen und geänderte Werte sind vorausgewählt, unveränderte nicht. Variablen, die Envoryx schon für einen der Projektdienste setzt (DB_HOST, DB_PASSWORD, REDIS_HOST, MAIL_* …), bleiben abgewählt, bis du sie selbst anhakst - sonst würde ein altes DB_HOST=127.0.0.1 deine Anwendung unbemerkt von der Projektdatenbank weglenken. Namen, die Envoryx nicht annimmt (Kleinbuchstaben, MARIADB_*, POSTGRES_*, ENVORYX_* …), und Werte mit Zeilenumbrüchen werden zwar angezeigt, lassen sich aber nicht importieren. Secrets erkennt Envoryx am Namen (*_PASSWORD, *_SECRET, *_TOKEN, APP_KEY, *_KEY …) oder an einem Passwort in einer URL.

Gespeichert wird erst, wenn du speicherst. Andersherum geht es auch: .env exportieren lädt deine Variablen als .env-Datei herunter, Secrets im Klartext. Die Dienstvariablen sind nicht dabei.

Das Projektmanifest (envoryx.yml)

envoryx.yml beschreibt ein Projekt in seinem eigenen Repository: Laufzeiten, Dienste, Domains, Umgebung, Worker und Cron-Jobs. Committest du die Datei mit dem Code, ist jeder mit einem frischen Klon nur einen Befehl von derselben Umgebung entfernt:

git clone git@github.com:acme/shop.git && cd shop
envoryx up                        # legt "shop" auf dem Server an oder gleicht es an
envoryx up --dry-run              # nur zeigen, was sich ändern würde
envoryx project manifest shop -o envoryx.yml   # die Datei für ein bestehendes Projekt schreiben

So kann eine vollständige Datei aussehen:

version: 1
name: shop
docroot: public
web: {server: nginx}             # caddy (Standard), apache, nginx
php:
  version: "8.4"
  extensions: [bcmath, intl, pdo_mysql, redis, zip]
  memoryLimit: 512M              # auch uploadMaxFilesize, postMaxSize, maxExecutionTime,
  xdebug: true                   # displayErrors, errorReporting, xdebugMode, xdebugIdeKey
database: {type: mariadb, version: "11.4", exposePort: true}
databases:                       # zusätzliche Datenbanken, erreichbar unter ihrem Namen
  analytics: {type: postgres}    # Host analytics, Variablen ANALYTICS_DB_*
redis: true                      # oder {version: "8", exposePort: true}
mailpit: true                    # auch memcached, rabbitmq, meilisearch, typesense,
opensearch: {dashboards: true}   # opensearch, storage: {publicRead: true}
domains: [api.shop.example.com]
env:
  APP_ENV: local
secrets: [STRIPE_SECRET]         # nur Namen - Werte landen nie im Repository
workers:
  - {name: queue, preset: "laravel:queue", arg: default}
cron:
  - {name: prune, schedule: "0 3 * * *", command: php artisan model:prune, timeout: 5m}
limits:
  app: {cpus: 2, memory: 2G}
  services: {memory: 1G}
  pids: 4096
healthcheck:
  path: /health
addons:                          # installierte Addon-Dateien, siehe die Addon-Seite
  phpmyadmin: true

node:, python:, go:, ruby:, java: und dotnet: nehmen dieselben Felder wie der Assistent - bei Ruby etwa server, mode, preset, port, debug und debugPort, Java kennt zusätzlich jar, und .NET nimmt statt der Debug-Felder project und dll. Was du weglässt, bedeutet den Standard von Envoryx; dadurch ist die Datei der komplette Sollzustand. Unbekannte Schlüssel sind Fehler, ein Tippfehler lässt also nie still einen Dienst verschwinden. Eine exportierte Datei legt jede Version fest, und genau deshalb kann envoryx up ein Projekt exakt nachbauen. Addons stehen mit ihrem Namen unter addons:, und auf dem Server, gegen den du envoryx up laufen lässt, muss die Addon-Datei installiert sein. Ein Standard, den du kennen solltest: storage: true legt einen privaten Bucket an, erst storage: {publicRead: true} macht ihn für alle lesbar.

Ein paar Dinge bleiben bewusst draußen: Host-Ports (die verteilt der Server), erzeugte Zugangsdaten, das Repository selbst, Backup-Zeitpläne und der Xdebug-Client-Host. Auch Secret-Werte kommen nie ins Repository - envoryx up fragt im Terminal nach jedem, den das Projekt noch nicht hat, oder du übergibst einen mit --secret KEY=VALUE.

Beim Entfernen ist envoryx up vorsichtig. Ein Dienst, eine Variable, Domain, ein Worker oder Cron-Job, den die Datei nicht mehr nennt, wird als behalten aufgeführt und verschwindet erst mit --prune - eine Datenbank oder ein Dienst mit Volume samt seinen Daten. Eine niedrigere Datenbankversion als die aktuelle des Projekts wird nie angewendet.

Um das Projekt zu finden, nimmt envoryx up den name: aus der Datei, --name oder den Ordnernamen. Kennt der Server noch kein Projekt mit diesem Namen, klont er das Repository selbst (den Remote origin und den ausgecheckten Branch) und legt das Projekt wie beschrieben an. Gibt es das Projekt schon, wendet er die Unterschiede mit einem einzigen Neustart an.

In der Weboberfläche zeigt der Bereich Git das Projekt als envoryx.yml - zum Kopieren, Herunterladen oder Speichern im Projektordner - und vergleicht die Datei im Projektordner mit dem Projekt. Hat ein git pull ein geändertes Manifest mitgebracht, übernimmt Auf das Projekt anwenden die Änderungen. Und der Assistent wendet das Manifest jedes Repositorys an, das er klont.