# Mit Umgebungsvariablen arbeiten

Die Plattform schreibt die generierten Env-Dateien, eigene Werte gehören in die Custom-Dateien, und das Deployment auf Dev und Prod konfigurierst du im Repository gitops-configuration.

> Source: https://www.application-platform.com/de/docs/environment-setup/

## Die Dateien im Verzeichnis env/

Das Verzeichnis `env/` in App- und Backend-Repositories enthält Dateien nach dem Muster `<umgebung>.<art>.env` mit den Umgebungen `local`, `dev`, `prod` und `shared` (alle Umgebungen) und der Art `generated` oder `custom`.

| Datei | Wer sie pflegt | Inhalt |
|-------|----------------|--------|
| `local.generated.env` | Plattform | URLs und Werte für die lokale Entwicklung |
| `local.custom.env` | du | eigene Werte für die lokale Entwicklung |
| `dev.generated.env`, `prod.generated.env` | Plattform | Werte je Umgebung, etwa die Backend-URL auf Dev oder Prod |
| `dev.custom.env`, `prod.custom.env` | du | eigene Werte je Umgebung |
| `shared.generated.env` | Plattform | Werte für alle Umgebungen, etwa Sentry-DSN und Bundle-IDs |
| `shared.custom.env` | du | eigene Werte für alle Umgebungen |

Die generierten Dateien überschreibt die Plattform bei jeder Konfigurationsänderung, deshalb bearbeitest du sie nicht; in den Custom-Dateien ergänzt oder überschreibst du Werte. `ap run-local` lädt beide Arten der passenden Umgebung, bei Flutter-Apps über `--dart-define-from-file`; eine neue lokale Variable kommt in `env/local.custom.env` mit anschließendem Neustart, ein Wert für alle Umgebungen in `shared.custom.env`. Neue generierte Werte erfordern eine Anpassung der Plattform-Konfiguration; frag beim [Support]({{< relref "/support" >}}) nach.

## Deployment-Konfiguration für Dev und Prod

Was auf den Servern läuft, konfigurierst du im Repository `gitops-configuration` deines Projekts mit einem Ordner pro Umgebung:

```
gitops-configuration/
└── configurations/
    ├── dev/
    │   ├── generated.yaml   # Plattform: Hostnamen, Registry, Secrets (SOPS)
    │   ├── custom.yaml      # du: eigene Umgebungsvariablen
    │   └── versions.yaml    # Pipeline: ausgerollte Image-Versionen
    └── prod/                # gleiche Struktur
```

`generated.yaml` schreibt die Plattform, `versions.yaml` pflegt die Pipeline, und `custom.yaml` gehört dir und nimmt eigene Umgebungsvariablen unter `additional_env_variables` auf. Ein Commit auf `main` rollt die Änderung auf die jeweilige Umgebung aus, wie [Git-Workflow und Deployment]({{< relref "git-workflow" >}}) beschreibt; das Gesamtbild zeigt die [Architektur]({{< relref "architecture" >}}).

## Secrets

Passwörter, Tokens und Schlüssel wie Datenbank-Zugänge, JWT-Secrets und Registry-Zugangsdaten erzeugt und verwaltet die Plattform; in `generated.yaml` liegen sie mit SOPS verschlüsselt und werden mit `ap secrets edit <datei>` bearbeitet.

{{< docnote type="warning" >}}
Die Custom-Dateien in `env/` und `custom.yaml` sind unverschlüsselte Textdateien im Repository. Schützenswerte Passwörter oder API-Keys gehören dort nicht hinein, sondern in die von der Plattform verwalteten Secrets.
{{< /docnote >}}

Gib Env-Dateien nicht vollständig aus, auch nicht im Chat mit einem KI-Agenten, und committe keine Secrets; die `AGENTS.md` im Projekt enthält diese Regel bereits.