# Die .env-Datei deiner Site bearbeiten
> .env einer Site in Vimonto Deploy bearbeiten: verschlüsselt gespeichert, nach shared/.env geschrieben, mit .env.example kombiniert und mit Verlauf.
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](https://ops.vimonto.com/docs/de/sites/create-a-site#ein-monorepo-deployen) wird der Link im Root-Verzeichnis der App innerhalb des Release angelegt. Jedes Release liest also dieselbe Datei, und ein [Rollback](https://ops.vimonto.com/docs/de/sites/deployments#auf-ein-früheres-release-zurücksetzen) ä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
1. Öffne die Site und geh zu **Umgebung**.
2. Die Keys sind sichtbar, die Werte aber maskiert und unscharf. Klicke auf **Anzeigen**, um den echten Inhalt in den Editor zu laden.
3. 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.
> [!NOTE]
> Die `.env` enthält Passwörter und Keys, daher sehen sie nur Personen, die Sites verwalten dürfen. Andere Mitglieder der Organisation sehen **Nur für alle, die die Site ändern dürfen**. Siehe [Mitglieder und Rollen](https://ops.vimonto.com/docs/de/organization/members-and-roles). Jedes **Anzeigen** wird im [Audit-Log](https://ops.vimonto.com/docs/de/organization/audit-log) festgehalten.
### 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](https://ops.vimonto.com/docs/de/sites/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](https://ops.vimonto.com/docs/de/sites/site-features), 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.
> [!TIP]
> Werte, die dein Frontend-Build nutzt, etwa `VITE_APP_NAME`, werden beim Build fest eingebaut. Deploye erneut, nachdem du sie geändert hast.
## Welche Features ändern die .env?
Manche [Site-Features](https://ops.vimonto.com/docs/de/sites/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.