An environment is an isolated instance of a software system with independently managed infrastructure, configuration, and state. A feature environment lets a developer run terraform apply against a local backend, test changes safely, then run terraform destroy before opening a pull request. section 8.2.2
Environments can represent development, staging, production, geographic regions, or customer-specific installations. Their number and structure follow business needs: staging commonly supports manual testing, while regional separation can address legal requirements or reduce latency. section 8.2.2
Terraform supports two complementary ways to distinguish environments:
- Use root-level module input variables to change the generated resource graph, such as an environment’s base domain or enabled features. section 5.4
- Create one thin root module per environment and point each to an application module. This permits independent application-module versions and environment-specific parameters. section 8.4.2
- Keep sensitive values as inputs rather than saving them in source control; a shared repository usually simplifies management when one team owns the environments. section 8.4.2
A thin staging environment
A staging/main.tf root module can call an application module at version 1.1.1, set network_name, db_size, and num_tasks directly, pass a sensitive logging_api_key variable, and expose module.application.url as application_url. Separate production and future directories can use the same pattern while selecting their own module versions and settings. section 8.4.2
Figure 8.7 Staging and production flow
Use the staging-and-production flow to compare how isolated environments support testing before customer-facing deployment. section 8.2.2
