Environments

An environment belongs to a project and provides the deployment context for one or more instances. Use separate environments when credentials, approvals, drift policy, or operational ownership differ. Names such as development, staging, and production are useful only when they represent those real boundaries.

Environment, instance, and run

Resource	Role
Environment	Stores deployment defaults and policy context for a project scope.
Instance	Binds one published template lineage to one environment.
Run	Records one execution request against an instance, including its resolved inputs, approval state, logs, and result.

Create the environment before the instance. The instance selects the published template version; the run snapshots the effective execution context when it is created.

Saving changes

Environment create/edit forms save fields, variables, and submitted gates in one transaction. A confirmed rejection does not partially apply the submission. Recoverable form feedback keeps your inputs. If a response is lost, check the current Environment state before submitting again; a missing response does not prove rollback. See saving and retrying workload forms.

Shared variables

Environment variables provide defaults that are merged into the resolved execution context. More specific instance or run inputs take precedence.

Environment: { "region": "eu-central-1", "environment": "production" }
Run input:   { "region": "eu-west-1", "replicas": 3 }
Resolved:    { "region": "eu-west-1", "environment": "production", "replicas": 3 }

The coordinator snapshots the resolved inputs against the selected published template version when it creates the run. Editing an environment later does not rewrite a historical execution record.

Example boundary

A project might use:

development for shared test credentials, fast feedback, and no apply approval;
staging for production-like inputs, an explicit approval gate, and drift monitoring; and
production for restricted credentials, separate worker placement, approval before apply, and an explicit operational owner.

These are separate environments because the delivery controls differ, not because the names are conventional. Keep secret values in the secret catalog and bind them at project or environment scope through Secret management; do not treat environment variables as a plaintext secret store.

Policy resolution

Feature-gate definitions can have environment, project, run, or worker overrides, depending on the gate. Resolution is explicit and auditable; an environment does not own an undocumented blanket policy object.

Use the Feature gates reference for current gate keys, supported scopes, defaults, and precedence. Review Approval workflows when an environment requires a plan-to-apply review gate.

An instance binds a registry template to the environment.
A Terraform/OpenTofu instance can have an environment-governed drift monitor.
Permissions and roles controls which identities can read or change the environment and its related resources.
Run operations explains how the environment context enters a run.