Secret Manager Integration: One Source of Truth for Humans and Agents.
Production secrets should live in one place and stay there, whether your next deployment is triggered by a developer or an AI agent. The Secret Manager integration connects AWS Secrets Manager, AWS SSM, or GCP Secret Manager to Qovery so secrets are referenced, never copied, and enterprise governance holds regardless of who deploys.
Most teams running on Qovery have been managing environment variables and secrets directly in the Qovery control plane, which works well for many cases. The problem starts when a security review, an enterprise customer questionnaire, or a SOC 2, HIPAA, or PCI audit asks where production secrets actually live. If the answer is "in AWS Secrets Manager and also copied into our deployment platform," the next question is harder to answer: who has access to the copies, who rotates them, and what happens when the source of truth changes?
Today, teams in this situation pick between two bad options: accept duplication and the rotation drift that comes with it, or build a custom sync layer that the platform team then has to own forever. Both create work for DevOps and visibility gaps for security.
And the problem compounds as AI agents take on more of the deployment workflow. An agent can't safely copy a credential from one system to another. The manual workaround humans use has no equivalent in an automated pipeline, and the compliance exposure that was already inconvenient becomes a hard blocker.
Bringing Your Secret Manager Into the Deployment Loop
Instead of storing secret values inside the Qovery control plane, environment variables can now reference a secret stored in the customer's own secret manager. The value is fetched at deploy time and injected into the running application. The secret never leaves the customer's cloud boundary, and every binding is recorded in the Qovery audit trail.
The integration is set up once at the cluster level. From there, developers bind secrets in the same Qovery interface they already use for environment variables, with no CRDs, no kubectl commands, and no operator for the platform team to maintain. The source of truth, the rotation policy, and the access controls stay in the secret manager where they were always meant to live.
This is also where the integration fits into the broader direction of Qovery as the agentic infrastructure layer for builders. Qovery is built so that applications can be deployed with enterprise-grade governance whether the deployment is triggered by a developer, a CI pipeline, or an AI agent acting autonomously. That last case is where the old secrets model breaks down: the human workflow, copy a value from AWS Secrets Manager, paste it into the deployment platform, has no equivalent when an agent is doing the deploying. An agent can't safely handle a raw credential. If it could access the value to inject it, the secret would travel through the agent's context and be exposed to whatever system is orchestrating it.
The Secret Manager integration removes that problem by design. The binding is a reference, not a value. An agent deploying an application specifies which secret path to use; Qovery resolves the value at deploy time directly from the customer's secret manager. The credential never enters the agent's context. And the governance properties hold regardless of who triggered the deployment, same source of truth, same rotation policy, same audit trail. Enterprise controls don't degrade when you introduce agents into your deployment workflow; they extend to cover it.
Outcomes for Your Team
Reduced compliance risk: Production secrets stay in the customer's source of truth, with no duplication into Qovery or any third-party system, and every binding is logged for audit purposes.
Less waiting on DevOps: Developers bind a secret to an environment variable in the same Qovery interface they already use, without filing a ticket to provision a Kubernetes secret or write an ExternalSecret resource.
Scale engineering without scaling DevOps: The operator running on the cluster is managed by Qovery, so the platform team does not own another piece of infrastructure to install, monitor, or upgrade.
Consistent deployments: Secret bindings follow the same per-application, per-environment, and per-project scoping model as the rest of Qovery, with no new mental model to learn.
One source of truth for your secrets.
Connect AWS Secrets Manager, AWS SSM, or GCP Secret Manager to Qovery and bind secrets to your applications without copying values into a third-party system.
From Security Questionnaire to Single Source of Truth
A Series B fintech with around 80 engineers has been running on Qovery for two years using Qovery's built-in secret management. They are now closing their first enterprise deal, and the prospect's security questionnaire requires proof that production secrets, including Stripe live keys and Postgres credentials for the database holding PII, are stored exclusively in the customer's own AWS account, with access logging and a documented rotation policy. The current setup, where those secrets live as values inside the Qovery control plane, does not satisfy the requirement.
The platform team connects AWS Secrets Manager to Qovery at the cluster level once. Developers then rebind the relevant environment variables in the Qovery interface, pointing them to AWS Secrets Manager entries instead of holding the values directly, with no change to the deployment workflow, no new CLI, and no CRDs to learn. Once the migration is complete, production secrets exist only in AWS Secrets Manager. The Qovery audit trail records which engineer bound which secret to which application, satisfying the access traceability part of the questionnaire. The rotation policy and access controls are owned in AWS, where they were always going to live.
What Else Changed in the UI
Alongside the Secret Manager integration, two parts of the Qovery interface have been updated.
Cluster Add-ons section. The cluster settings now include a dedicated Add-ons section where you can manage optional cluster-level capabilities directly, without opening a support ticket. The Secret Manager operator is the first add-on available there. Expect more to follow, observability activation and other cluster-level features are coming to the same section.
Reorganized environment variables panel. The environment variables view is now split into three sections to make it easier to understand what you own, what is externally managed, and what Qovery provides:
Custom, variables and secrets you define directly in Qovery.
External secrets, variables bound to a secret in your external secret manager via the operator.
Built-in, variables managed by Qovery that give quick access to useful runtime values like service hostname, namespace, and other platform-provided metadata.
How to Use
On the Qovery cluster, add a secret manager as a source (AWS Secrets Manager, AWS SSM Parameter Store, or GCP Secret Manager) using the "Automatic" credential setup. For more control, you can still use static credentials or an assumed role depending on the cloud provider.
In the application or environment variable section, go to the "External secret" tab, create an environment variable and find the secret via autocomplete.
Deploy the application. The secret is fetched from the secret manager and injected at runtime.
Get Started
The Secret Manager integration is rolling out in Beta. If you are already a Qovery customer, contact your CSM to enable it on your cluster and walk through the migration path for your existing secrets. If you are evaluating Qovery, book a demo to see how the integration fits into the rest of the platform.
Alessandro leads product at Qovery. He drives the changelog, roadmap, and product strategy - turning customer feedback into platform capabilities.
Next step
One source of truth for your secrets.
Connect AWS Secrets Manager, AWS SSM, or GCP Secret Manager to Qovery and bind secrets to your applications without copying values into a third-party system.
