Environments
The version matrix, and the single answer to "is this production?".
An environment is a first-class object (org_environments), not a string on
a page.
The one rule
ResolveEnvironment is the only answer to "is this production?" anywhere
in AccelerUp. Every feature that needs to know asks the environment model.
Do not add a per-page environment filter or a hardcoded list of environment names. Extend the model.
The reason is that the question is asked in many places — alert routing, deploy gating, retention, freeze windows, SLO scope — and a second implementation means two places that can disagree about whether something is production. That disagreement is always discovered at the worst moment.
Defining one
Settings → Project → Environments.
| Field | Purpose |
|---|---|
| Name | production, preprod, staging |
| Is production | Drives gating, routing and retention |
| Order | Promotion order |
| Colour | Visual distinction across the UI |
The version matrix
Delivery → Deployments → Version matrix is a grid: services down the side, environments across the top, current version in each cell.
It answers two questions instantly:
- What is in production right now?
- What is in staging that has not been promoted?
A cell that is behind by several versions is a service that has been quietly not shipping, which is worth knowing before somebody needs to ship it urgently.
Environment is not a UI mode
There is no global environment switcher, deliberately. Environment is a property of the object being displayed, not a state the whole interface is in.
Pages that need to filter by it do so themselves, using the model.
Related
- Deployment history
- Freezes — usually scoped to production
- Data retention — often differs per environment
Where this behaviour lives: backend/internal/domain/environment.go, frontend/src/app/deployments/environments/. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.