Docs

Staging

What this screen is for

Staging Environments are shared and persistent. This is the first tier where a change meets something realistic — and the first where breaking it affects other people.

Before you start

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

Holding the equivalent dev permission grants nothing here. The tiers are separate permission families on purpose.

Opening it

  1. Deploy › Staging in the sidebar.

Direct URL: /ebb/staging

The interface

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

📸 Screenshot Placeholder: The Staging Environments page. Mark: (1) the cluster selector limited to staging clusters, (2) the system selector, (3) the Events tab.

Control Staging-specific behaviour
Cluster selector Offers clusters registered as staging clusters only
Environments Shared and persistent — no TTL, and no automatic cleanup
Events The tab that matters most here, because other people are affected

Walkthroughs

Deploy a change to staging

Requires env-by-branch.staging.application.sync.

  1. Deploy › Staging, select the cluster and the system.
  2. Deploy the change.
  3. Watch the Events tab through to completion. A green deployment means the platform did its job; it says nothing about whether the application works.

Restart a deployment

Requires env-by-branch.staging.deployment.restart.

Use this when the application needs to pick up changed configuration. Remember this is shared — announce it rather than surprising whoever is mid-test.

Scenario

“Staging is broken” and three teams are blocked.

Shared environments turn one problem into everyone’s problem, so the priority is to find out what changed before changing anything else.

  1. Deploy › Staging, select the cluster.
  2. Open the Events tab and read from the most recent backwards. You are looking for the first failure, not the loudest one.
  3. Identify which application is failing, and drill into it via Environment Detail.
  4. Check whether a deployment landed just before the failure. If so, the fastest safe move is usually to revert that change rather than to debug it live while three teams wait.
  5. If the change came through a release, coordinate through Deployments rather than acting directly on the environment — otherwise the release record and reality diverge.
  6. Once recovered, reproduce the problem on a dev environment where you can take your time.

Step 6 is the part that stops it happening again. Fixing staging under pressure teaches nobody anything.

When it doesn’t work

Symptom Cause How to check Fix
You can see Dev but not Staging The tiers are separate permissions Access Explorer Ask for env-by-branch.staging.access
No clusters listed No cluster registered as staging, or none valid Clusters Register and validate one
Deployment succeeds, application is wrong Sync success is not application health The Events tab, then the resource Diagnose the application
Someone else’s change appeared unexpectedly Staging is shared The Events tab Coordinate through Deployments
Cannot restart a deployment Missing env-by-branch.staging.deployment.restart Access Explorer Ask for it on the staging tier

Next