Deploy
What this screen is for
Deploy is where applications actually run. It covers three environment tiers — Dev, Staging and Production — plus the surfaces that manage what goes into them: releases, frontend apps, Helm chart review, analytics, and direct cluster access.
The three tiers share one screen layout with different rules, so learning one teaches you the other two.
Before you start
Each tier is gated by its own permission. It is completely normal to see Dev and not Production — that is the design, not a fault.
| Tier | Access permission |
|---|---|
| Dev | env-by-branch.dev.access |
| Staging | env-by-branch.staging.access |
| Production | env-by-branch.production.access |
Everything within a tier follows the pattern
env-by-branch.<env>.<resource>.<action> — for example
env-by-branch.staging.application.sync.
Flat permission names do not grant all three tiers
Some routes accept a flat name such as env-by-branch.devops-config.read.
The backend expands it to the per-environment variants and accepts any one
of them. Holding the flat name is not the same as holding all three tiers —
always grant the tier you mean.
A cluster and its environments must be registered and valid before anything appears here.
Opening it
- Click Deploy in the sidebar.
- Pick a tier or surface from the submenu.
/ebb redirects to /ebb/dev.
The interface
All three tier pages use the same layout.
📸 Screenshot Placeholder: The Dev Environments page. Mark: (1) the cluster selector, (2) the system selector, (3) the Deploy button, (4) the Environments / Platform / Events tabs, (5) the environment settings icon, (6) the create button.
| # | Control | What it does | When you’d use it |
|---|---|---|---|
| 1 | Cluster selector | Chooses which registered cluster you are looking at | Always — the list below is per-cluster |
| 2 | System selector | Narrows to one project | Installs with many applications |
| 3 | Deploy | Starts a deployment | Shipping a change |
| 4 | Tabs — Environments · Platform · Events | The application environments, platform services, and the event stream | Events is where you look when something is wrong |
| 5 | Environment settings | Per-tier DevOps configuration | See DevOps Config |
| 6 | Create | Creates a new environment in this tier | Requires the tier’s environment.create permission |
Where each menu item goes
| Menu item | Page |
|---|---|
| Dev | Dev |
| Staging | Staging |
| Production | Production |
| Deployments | Deployments |
| Frontend Apps | Frontend Apps |
| Helm Review | Helm Review |
| Analytics | Analytics |
| Cluster Console | Cluster Console |
Walkthroughs
Selecting a cluster, filtering by system, and reading the three tabs works identically on all three tiers. What differs is covered on each tier’s page: Dev is ephemeral, Staging is shared, and Production is persistent and release-managed.
Scenario
Take a change from dev to production.
- Dev — create an ephemeral environment for the branch and deploy to it. Verify the change in isolation, without competing with anyone.
- Staging — deploy the same change. This is where it meets a shared, realistic environment for the first time. Watch the Events tab rather than assuming a green deployment means a working application.
- Helm Review — if the change touches Helm charts, review what the merge will actually alter in these environments before it lands.
- Deployments › Releases — create the release. Production is release-managed; you do not push to it the way you push to dev.
- Deployments › MEP Runbook — work through the runbook for the release.
- Production — confirm the environment reflects the new version.
- Analytics — check the deployment overview and failure analysis afterwards. This is what turns one deployment into a trend you can act on.
Steps 3 and 5 are the ones under time pressure people skip, and they are the two that exist specifically because production went wrong for someone before.
When it doesn’t work
| Symptom | Cause | How to check | Fix |
|---|---|---|---|
| A tier is missing from the submenu | You lack that tier’s .access permission |
Access Explorer | Ask for a role scoped to that tier |
| A warning says ArgoCD or Workflows is not configured | The CI/CD integration is missing or untested | Settings › Development › CI/CD | Add and test the integration |
| No clusters to select | None registered, or none valid | Settings › Infrastructure › Clusters | Register and validate a cluster |
| You can see the tier but not create anything | You hold .access but not .environment.create |
Access Explorer | Ask for the create permission on that tier |
| A permission was granted but nothing changed | Permission results are cached for the session | — | Reload the page |
Next
- Dev — start here
- Cluster Console — when you need to look at the cluster itself