Die Umgebung einer Site ist ihre .env-Datei: die Einstellungen und Secrets, die deine App zur Laufzeit liest, etwa den App-Key, das Datenbankpasswort und API-Keys. In Vimonto Deploy bearbeitest du sie auf der Seite Umgebung der Site. Sie wird verschlüsselt gespeichert und als eine Datei auf den Server geschrieben, die sich alle Releases teilen.
Weil die .env außerhalb der Releases liegt, bleibt sie von einem Deployment zum nächsten gleich, und du legst nie Secrets in deinem Repository ab. Jede gespeicherte Version wird aufbewahrt, sodass du sehen kannst, was sich geändert hat, und eine frühere wiederherstellen kannst.
Wo wird die .env gespeichert?
Auf dem Server liegt die .env unter shared/.env im Verzeichnis der Site, zum Beispiel /home/vimonto/shop.example.com/shared/.env. Sie gehört dem Benutzer der Site, und nur dieser Benutzer (und seine Gruppe) kann sie lesen.
Bei jedem Deployment bekommt das Release einen Link darauf: releases/{release}/.env zeigt auf shared/.env. Bei einem Monorepo wird der Link im Root-Verzeichnis der App innerhalb des Release angelegt. Jedes Release liest also dieselbe Datei, und ein Rollback ändert deine Einstellungen nicht.
In Vimonto Deploy wird der Inhalt verschlüsselt in der Datenbank gespeichert. Was du auf der Seite Umgebung speicherst, wird auf den Server geschrieben.
Die .env ansehen und bearbeiten
- Öffne die Site und geh zu Umgebung.
- Die Keys sind sichtbar, die Werte aber maskiert und unscharf. Klicke auf Anzeigen, um den echten Inhalt in den Editor zu laden.
- Nimm deine Änderungen vor und klicke auf Speichern und schreiben oder drücke ⌘ S (Strg S).
Beim Speichern wird die Datei sofort auf den Server geschrieben, als Hintergrundaufgabe, die du in der Kopfzeile der Site verfolgen kannst. Speichern ist erst nach Anzeigen möglich, damit du nie eine Datei überschreibst, die du nicht gesehen hast.
Beim Speichern den Config-Cache erneuern und die Worker neu starten
Manches liest die .env nur beim Start oder aus einem Cache. Bei einer Laravel-Site und bei jeder Site mit Prozessen oder Site-Features öffnet Speichern und schreiben zuerst .env speichern mit zwei Optionen:
| Option | Was sie bewirkt |
|---|---|
| Config-Cache erneuern | Nur bei Laravel-Sites. Führt php artisan config:cache im Live-Release aus, damit eine gecachte Konfiguration nicht die alten Werte behält. |
| Worker neu starten | Laravel-Queue-Worker beenden ihren Job und starten neu (queue:restart); Horizon, Reverb und die anderen Prozesse der Site starten ebenfalls neu, damit sie die neuen Werte lesen. |
Beim ersten Mal sind beide aktiv. Vimonto Deploy merkt sich deine Auswahl für diese Site, für dich, und nutzt sie beim nächsten Mal als Standard. Klicke im Dialog auf Speichern und schreiben, um zu speichern. Andere Sites speichern sofort, ohne den Dialog.
Frühere Versionen ansehen und wiederherstellen
Jede gespeicherte .env wird zu einer Version, egal wer oder was sie geändert hat: du auf dieser Seite, das Anlegen der Site, der erste Deploy, der sie auf Grundlage der .env.example aufgebaut hat, ein Site-Feature, das seine Keys gesetzt hat, oder eine Wiederherstellung. Klicke auf Verlauf, um sie zu sehen, die neuesten zuerst. Die 50 neuesten Versionen jeder Site werden aufbewahrt.
Jede Version zeigt, woher sie stammt (Site erstellt, Auf .env.example aufgebaut, Von einer anderen Site kopiert, Bearbeitet oder Wiederhergestellt), wer sie gespeichert hat (System für Änderungen von Vimonto Deploy selbst) und wann, und welche Keys sich geändert haben: + hinzugefügt, − entfernt und ~ geändert. Die Werte siehst du erst, nachdem du auf Anzeigen geklickt hast; vorher siehst du nur die Keys.
Um zu einer früheren Version zurückzukehren, klicke daneben auf Wiederherstellen und bestätige. Ihr Inhalt ersetzt die aktuelle .env und wird auf den Server geschrieben. Die ersetzte Version bleibt im Verlauf, sodass sich eine Wiederherstellung auf dieselbe Weise rückgängig machen lässt. Eine Wiederherstellung erneuert weder den Config-Cache, noch startet sie Worker neu; deploye erneut oder speichere noch einmal mit diesen Optionen, wenn deine App das braucht.
Was steht in der .env einer neuen Site?
Für Laravel- und Statamic-Sites schreibt Vimonto Deploy beim Erstellen der Site eine .env für die Produktion:
| Key | Wert |
|---|---|
APP_NAME |
Der erste Teil der Domain. |
APP_ENV, APP_DEBUG |
production und false. |
APP_KEY |
Ein neu erzeugter Key. |
APP_URL |
http:// und die Domain der Site. |
APP_LOCALE, APP_FALLBACK_LOCALE |
en. |
LOG_CHANNEL, LOG_LEVEL |
daily und error. |
DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD |
Die Datenbank, die beim Erstellen der Site verbunden wurde, falls vorhanden. |
SESSION_DRIVER, CACHE_STORE, QUEUE_CONNECTION |
redis auf einem App-Server (der Redis hat), sonst database. |
REDIS_HOST, REDIS_PORT |
127.0.0.1 und 6379. |
MAIL_MAILER |
log, bis du einen Maildienst einrichtest. |
Nutzt die Datenbank den eigenen Datenbankbenutzer des Servers und kennt Vimonto Deploy dessen Passwort nicht mehr, bleibt DB_PASSWORD leer, mit einem Kommentar, der dich bittet, es einzutragen.
Andere Sites starten ohne .env. Du kannst jederzeit eine auf der Seite Umgebung schreiben, wenn deine App sie braucht. Eine Site auf einem Load Balancer hat keine Seite Umgebung: Lege die .env der Site auf jedem App-Server dahinter fest.
Zusammenführen mit .env.example beim ersten Deploy
Wenn dein Repository eine .env.example hat, baut das erste Deployment die .env auf ihrer Grundlage neu auf. Das Ergebnis folgt den Keys, der Reihenfolge und den Kommentaren des Beispiels, mit den von Vimonto Deploy erzeugten Werten eingesetzt (auch dort, wo der Key im Beispiel auskommentiert ist, wie Laravel es bei DB_HOST macht). Erzeugte Keys, die im Beispiel fehlen, werden am Ende ergänzt.
So stehen die eigenen Keys deiner App, etwa VITE_* oder AWS_*, schon bereit, damit du sie ausfüllst. Bis zum ersten Deployment zeigt die Seite Umgebung Wird beim ersten Deploy ergänzt. Das Zusammenführen passiert nur einmal, bevor das Deploy-Skript läuft, und erscheint im Verlauf als Auf .env.example aufgebaut; danach ist die .env genau so, wie du sie anlegst.
Muss ich nach einer Änderung der .env den Config-Cache leeren?
Laravel-Apps, die ihre Konfiguration cachen (php artisan optimize oder config:cache, wie es das Standard-Deploy-Skript tut), lesen die .env nicht von selbst neu ein. Lass beim Speichern Config-Cache erneuern aktiv, dann führt Vimonto Deploy php artisan config:cache für dich aus. Andernfalls deploye erneut, damit das Deploy-Skript die neuen Werte cacht.
Welche Features ändern die .env?
Manche Site-Features brauchen Einstellungen in der .env, zum Beispiel Horizon (QUEUE_CONNECTION=redis), Reverb (BROADCAST_CONNECTION und die REVERB_*-Keys) und Nightwatch (NIGHTWATCH_TOKEN). Ihr Dialog zeigt genau, welche Keys sie setzen, bevor du sie einschaltest.
Wenn ein Feature eingeschaltet wird, bekommen vorhandene Keys an Ort und Stelle ihren neuen Wert, und fehlende Keys werden am Ende unter einem Kommentar mit dem Namen des Features ergänzt. Alles andere in der Datei bleibt, wie es war, und die Änderung wird im Verlauf festgehalten. Bei Laravel-Sites mit gecachter Konfiguration wird der Cache danach neu aufgebaut. Wenn du ein Feature ausschaltest, bleiben seine Keys in der .env.
Häufig gestellte Fragen
Gehört die .env in mein Repository?
Nein, und das sollte sie auch nicht. Die .env wird von Vimonto Deploy verwaltet und auf dem Server nach shared/.env geschrieben. Lege stattdessen eine .env.example ohne Secrets in deinem Repository ab.
Startet das Speichern der .env meine App neu?
Nur das, was du im Speicherdialog auswählst. PHP liest die Datei bei der nächsten Anfrage, es sei denn, die Konfiguration ist gecacht: Darum kümmert sich Config-Cache erneuern. Queue-Worker und andere Prozesse behalten die Werte, mit denen sie gestartet sind, bis sie neu starten: Worker neu starten erledigt das sofort, und jedes Deployment tut es ebenfalls.
Ich habe einen Fehler gespeichert. Wie mache ich ihn rückgängig?
Öffne Verlauf, suche die Version von vor deiner Änderung und klicke auf Wiederherstellen.
Was passiert mit der .env, wenn ich die Site lösche?
Sie wird zusammen mit dem Verzeichnis, den Releases, Workern und Zertifikaten der Site vom Server entfernt. Kopiere sie vorher, wenn du sie noch brauchst.