Environments

A single architecture usually runs in several places — dev, staging, prod — that differ only in scale and a handful of values. Flowright models this as one graph with per-environment overrides, not as copies you keep in sync by hand.

One graph, per-environment values

The topology is shared. What changes per environment is values: instance sizes, desired counts, domain names, feature flags. You set those overrides per environment, and the shared parts stay defined exactly once.

Note

Because the differences are values rather than structure, adding staging later doesn’t mean re-drawing anything — it inherits the topology and only needs its own numbers.

What gets generated

Flowright lifts the differing values into variables and emits a directory per environment, each wired to the same shared module:

• Directorymodules/

  • Directoryapp/

    • main.tf the shared topology
    • variables.tf
• Directoryenvironments/

  • Directorydev/

    • main.tf calls ../../modules/app
    • terraform.tfvars dev values
  • Directorystaging/

    • main.tf
    • terraform.tfvars
  • Directoryprod/

    • main.tf
    • terraform.tfvars

Each environment is an ordinary Terraform root you can plan/apply independently, with its own state. The shared module means a topology change lands in every environment at once; the per-env tfvars keep their sizing and names separate.

Secrets stay per-environment too

Secret variables (see Secrets & variables) remain unset in the generated code and are supplied per environment at apply — dev and prod never share a value through Flowright.

Why it matters

You design once and the drift between environments lives in a few lines of tfvars instead of in divergent copies of your infrastructure — which is exactly where production surprises come from.