GitLab Secrets Manager

Higher agent accuracy, lower token cost
Learn how to harden your software factory and let AI agents earn autonomy, without trading away security.
Stay updated with our latest features and improvements.
End secret sprawl with GitLab Secrets Manager, built on OpenBao. Pipeline and runtime secrets read from one store, governed by the permissions and audit trail that already cover your code.
Manage secrets where developers already work
With GitLab Secrets Manager, secrets live in the same groups and projects as the code that uses them, so requesting one fits the normal workflow with no plugin, agent, or second tool to learn.
Access follows your existing group and project hierarchy and fine-grained permissions offer extra control, so there isn't a second access model to keep in sync. Define a credential once at the project level or shared across the group. Anyone who leaves a project loses access automatically.
A developer declares the secret a job needs with the secrets: keyword in the pipeline configuration file. GitLab already knows the job's project, branch, and environment, so there is no identity to wire up between CI and a separate vault.
When a secret reference breaks, the fix ships in the same merge request as the code, with no second repo or approver. With secure credentials one line away, fewer secrets end up in CI variables, local config files, or the repo.
Limit the blast radius of exposed credentials
When a compromised dependency runs inside a job, cleanup with GitLab Secrets Manager means rotating and auditing the secrets that job could reach, not freezing every pipeline.
Unlike CI variables, which reach every job in the pipeline, a secret reaches only the jobs that declare it and fall within its scope: branch, environment, and protection status.
Secrets Manager writes the value to a temporary file and exposes only its path, limiting exposure in subprocesses, crash dumps, and telemetry. The value is masked in job logs and discarded when the job ends, so nothing persists on the runner.
Create, read, update, and delete events land in the same audit trail as the rest of GitLab. Pipeline reads carry pipeline and job IDs, so responders and auditors trace a credential from access to deployment without correlating logs across systems by hand.
One store for pipelines, clusters, and infrastructure
Pipelines read secrets directly. Kubernetes workloads, Terraform and OpenTofu runs, Vault-compatible CLI tools, and other automation connect through standard integration points, under the same permissions and audit trail as pipelines.
External Secrets Operator keeps Kubernetes secrets in sync with GitLab, so rotated values propagate without a redeploy. Terraform and OpenTofu read secrets as a data source when they run, keeping credentials out of files and CI/CD variables.
Built on OpenBao, Secrets Manager exposes a Vault-compatible API, so teams already scripting against the OpenBao or Vault CLI keep the commands they have. Any other automation fetches secrets through the Secrets Manager API instead of hardcoding credentials or maintaining separate variable files.
Credentials follow multi-cloud, hybrid, and on-premises workloads without per-platform identity federation. Moving a workload to another cloud doesn't mean standing up a second store, and secrets otherwise scattered across per-account and per-region stores live in one place.
GitLab goes beyond managing credentials. Secret push protection blocks credentials from reaching the repository, client-side detection catches secrets in issue and merge request text, and pipeline secret detection finds secrets already in code. Duo Agent Platform triages the findings and flags likely false positives.
GitLab Secrets Manager is a paid add-on for Premium and Ultimate, billed through GitLab Credits: 1 credit per secret stored per month, and 1 credit per 2,500 secret read operations. If you prefer a flat fee, an enterprise license agreement ELA is available.
Already a Premium or Ultimate customer? You can trial GitLab Secrets Manager at no cost for 30 days or 500 evaluation credits, whichever ends first.
GitLab built this maturity framework from its work with industry-leading customers. Answer a few questions about how your team handles security and compliance to get your maturity score and recommendations for the next stage.
Quiz takes 5 minutes or less
They keep working, and nothing is migrated automatically. CI/CD variables remain a fine fit for non-sensitive configuration. To find candidates for migration, use the secret audit tool for CI/CD variables to identify which variables hold credentials, then move those values into Secrets Manager on your own schedule.
Yes, unchanged. The existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager run alongside GitLab Secrets Manager.
GitLab Secrets Manager is available to Premium and Ultimate customers. It is generally available on GitLab.com and GitLab Self-Managed. Support for GitLab Dedicated is coming soon.
GitLab Secrets Manager is a paid add-on billed through GitLab Credits. One secret stored for a month consumes 1 credit, and 2,500 secret read operations consume 1 credit. Usage is metered at the namespace level, so per-user credit allocations and spend caps don't apply. Customers with a committed credit pool draw Secrets Manager usage from that pool, and the credits dashboard shows it separately from Duo Agent Platform usage. See the Secrets Manager billing documentation for details.
A Premium or Ultimate subscription and the Owner role for a top-level group. The trial runs for 30 days or 500 evaluation credits, whichever ends first. On GitLab Self-Managed (GitLab 19.5 and later), an administrator must first install Secrets Manager on the instance. See how to start a trial for the steps.
Yes. Kubernetes workloads sync secrets through External Secrets Operator using its Vault provider. Terraform and OpenTofu read a secret as a data source at plan