Docs

Production

What this screen is for

Production Environments are persistent and managed by the Release Manager. That is the important difference from the other tiers: you do not push to production the way you push to dev. Changes arrive through a release.

Before you start

To do this You need
Open the page env-by-branch.production.access
Create an environment env-by-branch.production.environment.create
See the event stream env-by-branch.production.event.read
Sync an application env-by-branch.production.application.sync
Restart a deployment env-by-branch.production.deployment.restart

Grant these deliberately and narrowly. A policy that forgets its environment condition grants production alongside dev, and the two look identical in the policy list.

Opening it

  1. Deploy › Production in the sidebar.

Direct URL: /ebb/production

The interface

Same layout as the other tiers — see Deploy. Production-specific:

📸 Screenshot Placeholder: The Production Environments page. Mark: (1) the cluster selector limited to production clusters, (2) an environment row, (3) the Events tab.

Control Production-specific behaviour
Cluster selector Offers clusters registered as production clusters only
Environments Persistent, and driven by the Release Manager rather than ad-hoc deploys
Events Your record of what actually happened, and when

Walkthroughs

Confirm a release reached production

  1. Deploy › Production, select the cluster.
  2. Find the application and check the running version against the release.
  3. Open the Events tab to see the deployment land, and to catch anything that failed after a green deployment.

Act directly on a production environment

Sometimes you must — an urgent restart, an urgent sync. When you do:

  1. Confirm you actually hold the production permission for that action.
  2. Do it.
  3. Go back to Deployments and record what you did. A direct action leaves the release record describing something that is no longer true, and the next person will trust the record.

Scenario

A release is live, and one service is serving errors.

  1. Deploy › Production, select the cluster, find the service.
  2. Events tab. Establish when it started, and whether it lines up with the release landing. That single fact decides everything that follows.
  3. If it began with the release, this is a release problem — go to Deployments › Releases and follow your rollback path there, so the record stays true.
  4. If it began later and independently, it is an operational problem. Use Cluster Console to inspect the workload directly.
  5. Either way, once stable, check Analytics — failure analysis turns this incident into something you can compare against the last one.

The distinction in step 2 is the whole scenario. Rolling back a release that was not the cause replaces one outage with two.

When it doesn’t work

Symptom Cause How to check Fix
Production is not in the submenu You lack env-by-branch.production.access Access Explorer Ask for a role scoped to production — deliberately
A user reaches production who should not A policy statement with no environment condition The policy statements Add the environment condition; see Policies
No clusters listed No cluster registered as production, or none valid Clusters Register and validate one
Environment does not match the release Someone acted directly on the environment The Events tab Reconcile through Deployments
You can act in staging but not production Separate permission families per tier Access Explorer Expected — request explicitly if genuinely needed

Next