Multi-Environment Setup

This example deploys the same application and PostgreSQL database to three environments of one project. A locals map holds what differs between the environments, and for_each creates one copy of each resource per entry. Production uses a managed database from a blueprint, which needs an AWS cluster.

Configuration

variables.tf

variable "organization_id" {
  description = "ID of the Qovery organization"
  type        = string
}

variable "cluster_id" {
  description = "ID of the cluster that runs the environments"
  type        = string
}

main.tf

terraform {
  required_providers {
    qovery = {
      source  = "qovery/qovery"
      version = "~> 1.0"
    }
  }
}

provider "qovery" {}

locals {
  environments = {
    development = {
      mode             = "DEVELOPMENT"
      branch           = "develop"
      instances        = 1
      managed_database = false
    }
    staging = {
      mode             = "STAGING"
      branch           = "staging"
      instances        = 1
      managed_database = false
    }
    production = {
      mode             = "PRODUCTION"
      branch           = "main"
      instances        = 3
      managed_database = true
    }
  }

  container_databases = { for name, env in local.environments : name => env if !env.managed_database }
  managed_databases   = { for name, env in local.environments : name => env if env.managed_database }
}

resource "qovery_project" "shop" {
  organization_id = var.organization_id
  name            = "shop"
}

resource "qovery_environment" "env" {
  for_each = local.environments

  project_id = qovery_project.shop.id
  cluster_id = var.cluster_id
  name       = each.key
  mode       = each.value.mode
}

# PostgreSQL in a container on the cluster, for development and staging
resource "qovery_database" "postgres" {
  for_each = local.container_databases

  environment_id = qovery_environment.env[each.key].id
  name           = "postgres"
  type           = "POSTGRESQL"
  version        = "16"
  mode           = "CONTAINER"
  accessibility  = "PRIVATE"
  storage        = 10
}

# Amazon RDS for PostgreSQL from the service catalog, for production. Requires an AWS cluster.
resource "qovery_blueprint" "postgres" {
  for_each = local.managed_databases

  environment_id = qovery_environment.env[each.key].id
  name           = "postgres"
  blueprint      = "AWS/postgres/17"

  variables = {
    # Also names the RDS instance: it must be unique in the AWS account and region.
    db_name           = "shop_${each.key}"
    instance_class    = "db.t3.medium"
    allocated_storage = "50"
  }
}

locals {
  # DATABASE_URL of the container databases: an alias of their built-in secret
  database_url_aliases = {
    for name, db in qovery_database.postgres : name => "QOVERY_POSTGRESQL_Z${upper(split("-", db.id)[0])}_DATABASE_URL_INTERNAL"
  }

  # Prefix of the output variables of each blueprint, for example QOVERY_OUTPUT_TERRAFORM_ZA1B2C3D4
  blueprint_outputs = {
    for name, bp in qovery_blueprint.postgres : name => "QOVERY_OUTPUT_TERRAFORM_Z${upper(split("-", bp.service_id)[0])}"
  }

  # DATABASE_URL of the managed databases: Qovery replaces each {{...}} with an output of the blueprint
  database_url_secrets = {
    for name, p in local.blueprint_outputs : name => "postgresql://{{${p}_DB_USERNAME}}:{{${p}_DB_PASSWORD}}@{{${p}_DB_ADDRESS}}:{{${p}_DB_PORT}}/{{${p}_DB_NAME}}"
  }
}

resource "qovery_application" "api" {
  for_each = local.environments

  environment_id = qovery_environment.env[each.key].id
  name           = "api"

  git_repository = {
    url    = "https://github.com/your-org/api.git"
    branch = each.value.branch
  }
  build_mode      = "DOCKER"
  dockerfile_path = "Dockerfile"

  cpu                   = 500
  memory                = 512
  min_running_instances = each.value.instances
  max_running_instances = each.value.instances

  # New commits redeploy development and staging, not production.
  auto_deploy = each.key != "production"

  ports = [
    {
      internal_port       = 8080
      external_port       = 443
      protocol            = "HTTP"
      publicly_accessible = true
    }
  ]

  healthchecks = {
    readiness_probe = {
      type = {
        http = {
          port   = 8080
          path   = "/health"
          scheme = "HTTP"
        }
      }
      initial_delay_seconds = 30
      period_seconds        = 10
      timeout_seconds       = 5
      success_threshold     = 1
      failure_threshold     = 3
    }
  }

  # Each environment gets DATABASE_URL from one of the two maps above.
  secret_aliases = [
    for name, target in local.database_url_aliases : { key = "DATABASE_URL", value = target } if name == each.key
  ]
  secrets = [
    for name, url in local.database_url_secrets : { key = "DATABASE_URL", value = url } if name == each.key
  ]
}

resource "qovery_deployment" "env" {
  for_each = local.environments

  environment_id = qovery_environment.env[each.key].id
  desired_state  = "RUNNING"

  depends_on = [
    qovery_database.postgres,
    qovery_blueprint.postgres,
    qovery_application.api,
  ]
}

output "api_urls" {
  value = { for name, app in qovery_application.api : name => "https://${app.external_host}" }
}

What differs between the environments:

Git branch: each environment builds its own branch.
Instances: production runs three instances of the application.
Database: development and staging run PostgreSQL in a container on the cluster. Production runs Amazon RDS for PostgreSQL, created from a blueprint of the service catalog with qovery_blueprint. This blueprint needs an AWS cluster. instance_class and allocated_storage are variables of the blueprint.
Auto-deploy: new commits redeploy development and staging. Production is deployed by qovery_deployment or from the Console: to deploy it again after a change, set version on its qovery_deployment to a new UUID.

The application reads the database connection string from DATABASE_URL. For a container database, it is an alias of a built-in secret. For the managed database, it is a secret that Qovery builds from the outputs of the blueprint when it deploys the application. Application with Database explains both.

Deploy

export TF_VAR_organization_id="<organization_id>"
export TF_VAR_cluster_id="<cluster_id>"

terraform init
terraform apply
terraform output api_urls

To add an environment, add an entry to local.environments. To keep a separate state per environment, move the resources into a module and call it from one root configuration per environment, or use workspaces: see Advanced Patterns.

Next steps

Application with Database

Connect services with built-in variables

Advanced Patterns

Modules, workspaces and remote state

Terraform Exporter

Generate the configuration of an existing environment

Terraform Registry

Reference of every resource and data source

Getting Started

Examples

Multi-Environment Setup

Configuration

Deploy

Next steps

Application with Database

Advanced Patterns

Terraform Exporter

Terraform Registry

​Configuration

​Deploy

​Next steps

Application with Database

Advanced Patterns

Terraform Exporter

Terraform Registry

Configuration

Deploy

Next steps