Overview
This guide covers Terraform patterns for managing Qovery resources at scale: modules, workspaces, remote state, variable files, lists built from variables and conditional resources.Reusable Modules
Organize your Terraform code with reusable modules for consistent deployments.Module Structure
Application Module
This module declares its inputs, the application and its outputs in one file for brevity. A module that uses the Qovery provider declares it in its ownrequired_providers block; otherwise Terraform looks for a hashicorp/qovery provider.
modules/application/main.tf
Using the Module
The root configuration takes the IDs of an existing project and cluster as input variables. See Find resource IDs. main.tfTerraform Workspaces
Use workspaces to manage multiple environments with a single configuration: each workspace has its own state. The configuration reads the workspace name fromterraform.workspace and looks up the settings of that environment.
The multi-environment example uses the same kind of settings map with for_each and shows the complete application. With workspaces, you index the map with the workspace name instead.
Workspace Configuration
MANAGED database requires instance_type. db.t3.medium is an AWS RDS instance type: use one that your cloud provider offers.
Using Workspaces
The configuration only knows thedev, staging and production workspaces: create them before you apply, and do not apply in the default workspace.
Remote State Management
Store Terraform state remotely for team collaboration.S3 Backend
use_lockfile = true locks the state with a lock file in the bucket, so you do not need a DynamoDB table. Enable versioning on the bucket to recover an earlier version of the state.
Terraform Cloud
Initialize Backend
Variable Files
Organize variables per environment using.tfvars files.
Directory Structure
variables.tf
environments/production.tfvars
environments/dev.tfvars
TF_VAR_qovery_api_token environment variable.
Deploy with Variable Files
Lists from Variables
ports, environment_variables and the other list attributes of the Qovery resources are nested attributes, not blocks, so dynamic blocks do not apply to them. Assign a list directly, or build one with a for expression.
Conditional Resources
Create resources conditionally based on variables.MANAGED databases require instance_type. db.t3.micro and cache.t3.micro are AWS instance types: use ones that your cloud provider offers.
Best Practices
Use Version Constraints
Use Version Constraints
Pin the provider major version, so that a new major release cannot introduce breaking changes without an explicit upgrade. The provider is tested against Terraform 1.15; earlier versions are expected to work but are not tested.
Separate State Per Environment
Separate State Per Environment
Use different state files for each environment to prevent accidental changes:
- Different S3 keys:
env/dev/terraform.tfstate,env/prod/terraform.tfstate - Different Terraform Cloud workspaces
- Different backend configurations
Use Data Sources
Use Data Sources
Read an existing resource by its ID instead of copying its attributes into the configuration. Data sources look up resources by
id, not by name:Protect Production
Protect Production
Add lifecycle rules to prevent accidental deletion:
Next Steps
Basic Application
Start with a simple application
Multi-Environment
Deploy to multiple environments
Provider Documentation
Complete provider reference
Terraform Documentation
Official Terraform documentation