Environments

An environment is a way to organize related deployments by stage. Ship a web app and its worker to Development, promote the same image to Staging, and keep Production on a separate, stable config. All from one dashboard.

Manage them from Settings.

How environments work

Every organization starts with two defaults: Development and Production. You can create as many more as you need (e.g. staging, qa).
A deployment belongs to one environment. Deployments in the same environment share a logical boundary. Names must be unique within the environment, so you can have api in both Development and Production without collision.
Environments get color-coded badges so dev vs prod is visually obvious throughout the dashboard.

Logical grouping

Organize applications by stage, team, or purpose. However you structure your workflow.

Scoped configuration

Each deployment keeps its own env vars, scale, and image tag. Staging and production stay independent.

Visual isolation

Color-coded badges in deployment lists and the top nav.

Shared infrastructure

Run as many environments as you need side by side. No need to pay for separate infrastructure per stage.

Creating an environment

Open Settings

Go to Settings.
Click New environment

Pick a name (e.g. staging, qa) and a color. The color shows up wherever this environment is referenced.
Start deploying to it

The new environment appears in the Environment dropdown when you create a deployment from your dashboard.

Viewing an environment

Each environment and its deployments are visible under Settings. For each environment you can see:

All deployments tagged to this environment
Health rollup: healthy / syncing / degraded counts at a glance
Shortcuts: jump into any deployment’s detail page in one click

Using environments in a deployment

When you create a deployment from your dashboard:

Environment is a required field. Pick an existing environment or create a new one inline.
The selected environment becomes part of the deployment’s identity. Changing it later requires a separate flow.

Limits and constraints

Environment + name is the uniqueness rule. The same deployment name can exist in different environments.
Deleting an environment requires no deployments to be tagged to it first.

On the roadmap

Environment-level variable overrides: set a variable once at the environment level and have it inherit to every deployment.

Deployments The four resource types that live inside an environment.

Clusters Advanced own-cloud path: how environments map onto clusters in your AWS account.