Use Environments to separate blast radius and configuration between stages

These habits align with the Application → Environment → Service model in How dFlow is structured under Core Concepts in the sidebar.

Name and structure

• Prefer clear stage names (production, staging, development) or Custom names that your team can grep and audit (client-demo, perf-test).

• One role per Environment where possible: mixing unrelated workloads in one stage makes rollback, access, and monitoring harder.

• Set the Default environment under Applications in the sidebar to the stage people should land on daily (often staging for teams, production for small apps). Match your policy.

Compute isolation

• Attach compute per Environment intentionally: production and staging should not silently share a Worker Node unless you explicitly want that cost and blast-radius trade-off.

• Add capacity in Worker Nodes and Compute under Worker Nodes and Compute in the sidebar first, then Attach compute to an environment. On dFlow Cloud, reconcile with Choose compute / managed infrastructure under dFlow Cloud in the sidebar.

• Re-run connection checks after firewall, SSH, or provider changes (see Compute and worker node issues under Troubleshooting in the sidebar).

Lifecycle and safety

• Finish Activation so draft Environments do not linger unnoticed. See Draft vs active environments.

• Before Delete Environment in Environment settings, confirm there are no Services you still need; deletion is irreversible.

Configuration and Services

• Keep environment-scoped concerns (compute, stage identity) in the Environment layer; use Service settings for workload-specific variables. See Service settings under Services in the sidebar.

• For legacy Projects, plan migration using Legacy Projects vs Applications under Core Concepts in the sidebar so Environments map cleanly after cutover.

Related

• Create an environment

• Environments overview

• Operational best practices (Deployments section, as expanded)