Environment best practices

Naming, isolation, compute attachment, and operational habits for Environments in dFlow.

Written By Zoro

Last updated 3 days ago

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.

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.

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).

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.

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.