Every generated repository ships with its configuration. Environment variables live in two places: the env/ directory in the code repository (for local development and app builds) and the gitops-configuration repository (for the dev and prod deployments).
The env/ directory
App and backend repositories contain an env/ directory with files following the pattern <stage>.<kind>.env:
| File | Maintained by | Contents |
|---|---|---|
local.generated.env |
Platform | URLs and values for local development |
local.custom.env |
You | Your own local settings |
dev.generated.env / prod.generated.env |
Platform | Stage-specific URLs (e.g. backend URL on dev/prod) |
dev.custom.env / prod.custom.env |
You | Your own stage-specific values |
shared.generated.env |
Platform | Cross-stage values (e.g. Sentry DSN, bundle IDs) |
shared.custom.env |
You | Your own cross-stage values |
The rule is simple:
*.generated.envis written by the platform and overwritten on changes – do not edit.*.custom.envis yours. Add your own variables here or override generated values.
When starting via ap run-local, the right files are loaded automatically – for Flutter apps via --dart-define-from-file, for example.
env/local.custom.env and restart ap run-local.Deployment configuration: dev and prod
What runs on the servers is configured in your project’s gitops-configuration repository – one folder per environment:
gitops-configuration/
└── configurations/
├── dev/
│ ├── generated.yaml # Platform: hostnames, registry, secrets (SOPS)
│ ├── custom.yaml # You: custom environment variables
│ └── versions.yaml # Pipeline: deployed image versions
└── prod/ # same structure
Add your own deployment environment variables in custom.yaml under additional_env_variables. After a commit to main, the GitOps repository automatically rolls the change out to the respective environment – just like the regular deployment workflow.
Secrets
Passwords, tokens, and keys are generated by the platform and stored encrypted or managed automatically – including database credentials, JWT secrets, and registry credentials.
*.custom.env or custom.yaml. Use the platform-managed secrets for sensitive values, or ask support which approach fits your case.See also
- Starting applications with the ap CLI – how the env files are loaded on startup.
- Git workflow & deployment – how changes reach dev and prod.
- Architecture – the role of the GitOps repository in the big picture.