Docs

Dev

What this screen is for

Dev Environments are temporary and cluster-specific. You create one for a branch, use it, and let it go. Because they are ephemeral, dev is the tier where experimenting is cheap and nobody else is affected by what you break.

Before you start

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

A registered, valid development cluster must exist — see Settings › Infrastructure › Clusters.

Opening it

  1. Deploy › Dev in the sidebar.

Direct URL: /ebb/dev. /ebb on its own redirects here.

The interface

The layout is shared across all three tiers and is described in Deploy. What is specific to dev:

📸 Screenshot Placeholder: The Dev Environments page with two ephemeral environments listed. Mark: (1) the cluster selector set to a development cluster, (2) the create button, (3) an environment row showing its TTL.

Control Dev-specific behaviour
Cluster selector Offers clusters registered as development clusters only
Create Creates an ephemeral environment, which carries a time-to-live
Environment row Shows the TTL — dev environments expire on purpose

Walkthroughs

Create a dev environment for a branch

Requires env-by-branch.dev.environment.create.

  1. Deploy › Dev.
  2. Select the development cluster.
  3. Click create and fill in the environment, picking the branch.
  4. Wait for it to become ready, then open it to get its URL — see Environment Detail.

Extend or shorten a TTL

Open the environment and use TTL management — see Environment Detail. An expired dev environment is removed; that is the point of the tier, not a failure.

Diagnose a deployment that will not come up

  1. Switch to the Events tab. Read it before touching anything else — it almost always names the cause.
  2. If events point at the application rather than the platform, open the environment and drill into the failing resource.

Scenario

Two developers need the same service at different versions, at the same time.

On a shared environment this is a fight. On dev it is not.

  1. Deploy › Dev, select the development cluster.
  2. Each developer creates their own environment from their own branch. Name them after the branch, not after the person — the branch is what someone else will recognise a week later.
  3. Both deploy independently. Neither can disturb the other, because the environments are separate.
  4. Each verifies their change and reads the Events tab for their own environment.
  5. When a branch merges, its environment is no longer needed. Let the TTL expire rather than extending it out of habit — an ephemeral environment nobody deletes is just an expensive staging environment.

When it doesn’t work

Symptom Cause How to check Fix
No clusters in the selector No cluster registered as a development cluster, or none valid Clusters Register and validate one
Create button absent Missing env-by-branch.dev.environment.create Access Explorer Ask for the permission on the dev tier
Warning about ArgoCD or Workflows The CI/CD integration is missing or untested Settings › Development › CI/CD Add and test it
An environment vanished Its TTL expired — dev environments are ephemeral by design The environment’s TTL before it expires Recreate it; extend the TTL if it is genuinely needed longer
Deployment shows green but the app does not work A successful sync is not a working application The Events tab, then the resource detail Diagnose the application, not the platform

Next