Skip to main content
This feature is available on:
  • AWS Managed Cluster
  • GCP Managed Cluster
Supported Secrets Providers:
  • AWS Secrets Manager
  • AWS Parameter Store
  • GCP Secret Manager

​
Secret Manager Access benefits

Compared to Qovery built-in secrets, integrating a dedicated Secret Manager offers several key advantages:
  • Security and data sovereignty: Your secrets stay entirely within your own infrastructure and are never transmitted through Qovery’s systems. Secret values are fetched directly by External Secret Operator from your provider into your cluster, minimizing the number of systems that ever handle raw secret values. With built-in secrets, the value passes through Qovery’s API and storage layer.
  • Centralized secret management: Use your existing secrets provider as a single source of truth across all your infrastructure — Qovery services, Lambda functions, CI pipelines, and other tools all reference the same secrets without duplication. A secret defined once can also be consumed by multiple clusters (e.g., staging and production) without recreating it in each environment.
  • Simplified and automatic secret rotation: When a shared secret needs updating, change it once in your secrets manager, then redeploy the affected services via Qovery to pick up the new value. You can also leverage native automatic rotation from your provider (e.g., database credentials rotated via a Lambda function) — Qovery services will benefit from it in the next deployment without any additional secret management step.
  • Audit trails and compliance: Cloud-native secret managers provide built-in versioning, access logs, and fine-grained IAM policies — seamlessly extending your existing compliance posture to secrets consumed by Qovery services.

​
How it works

Qovery integrates with external secrets by deploying ESO (External Secrets Operator) in your cluster.

​
Configure a Secret Manager Access

You can configure a Secret Manager Access in the Add-ons section of your cluster.
Overview add Secret Manager Access
Creating or Editing a Secret Manager Access requires the cluster to be redeployed
Select the guide for your secrets provider:

AWS Secrets Manager

Connect to AWS Secrets Manager from an AWS or GCP cluster

AWS Parameter Store

Connect to AWS Parameter Store from an AWS or GCP cluster

GCP Secret Manager

Connect to GCP Secret Manager from a GCP or AWS cluster

​
Reference the external secrets in your services

Setting external secrets at the environment level multiplies cloud costs.You can set external secrets at the environment level to inject them to all services, but be careful:
  • The secret value will be fetched individually for each service running in the environment.
  • With many services, this multiplies the number of secret fetches and can significantly increase your cloud costs.
Prefer service-level secrets when only a subset of services need access to the value.

​
Using the Qovery Console

Once your cluster is deployed, you can link external secrets to any service:
  • Open your service
  • Navigate to the Variables tab
  • Select the External secrets tab
  • Click Add external secret
External Secrets path
Qovery automatically lists the secrets available in your Secrets Provider to simplify setup:
External Secrets list secrets available
You can filter results by prefix to narrow the list:
External Secrets list secrets available by prefix
To create an external secret, you need to:
  • Select the Secret Manager Access
  • Select the secret from your Secret Manager
  • Provide the environment variable key to inject
External Secrets details
Similarly to a basic environment variable, you can create an external secret that can be mounted to a file:
External Secret file details
External secrets are fetched only at deployment. A running service won’t automatically pick up changes to its external secrets — it requires a redeploy.

​
Using the Qovery CLI

  • Create an external secret:
To create an external secret as a file, just add the --mount-path="path" parameter
  • Update an external secret:
You can’t update the mount path of an external secret (same behavior as basic environment variable)
  • Delete an external secret:

​
Using external secrets with Terraform services

To pass an external secret to Terraform, first create the external secret (in the External secrets tab of the service, or at the environment, project, or organization level), then reference its key from a Terraform variable with the {{ SECRET_KEY }} syntax.
Terraform service external secret
You can use the reference:
  • In the Terraform variables section, as the value of a variable, for example db_password = {{ DB_PASSWORD }}
  • In a .tfvars file from your repository, for example db_password = "{{ DB_PASSWORD }}"
  • Inside a longer value, for example database_url = "postgres://app:{{ DB_PASSWORD }}@db.internal:5432/app"
Qovery never reads the secret value. The reference is resolved inside your cluster when the Terraform job starts, from the secret synced by the External Secrets Operator, and Terraform receives the value as a -var argument.
  • External secrets mounted as a file can’t be referenced from a Terraform variable.
  • References are not resolved in the Terraform arguments section.
  • Terraform prints variable values in its plan and apply output unless the variable is declared with sensitive = true in your module. Mark the variables that receive secrets as sensitive.
  • sensitive = true only redacts Terraform’s output: resource attributes derived from the secret can still be stored in the Terraform state. Protect your state backend accordingly.
An external secret whose key follows the pattern TF_VAR_${your_variable} is still read by Terraform as your_variable, as long as no Terraform variable or .tfvars entry sets your_variable: those take precedence over TF_VAR_* environment variables. Prefer the {{ SECRET_KEY }} reference, which works with any key name and is not overridden.