Secrets Manager - Self Hosted

GitLab Secrets Manager, Self-Hosted, lets teams store and consume CI/CD credentials natively inside a self-managed GitLab instance, including fully air-gapped deployments with no connection to the public internet.

Built for public sector, defense, financial services, and other regulated teams that require on-premises or air-gapped operation and full data sovereignty.

Secrets such as access tokens, database credentials, and private keys live in the same platform that runs your code and pipelines. There is no standalone secrets system to install alongside GitLab, no second access model to reconcile, and no external service dependency. The solution is built on OpenBao, the open-source secrets engine, and runs entirely within your own infrastructure and governance boundary.

Access control reuses the GitLab group and project structure you already maintain. You set read, create, update, and delete permissions per user, group, or role using the same controls that govern your code. Secrets defined at the group level are inherited by the projects beneath it, so shared credentials are defined once.

Every secret is scoped to the jobs that need it, based on the target environment, the branch, and whether that branch is protected. A compromised credential is contained to one job rather than every pipeline that could reference it. Create, update, and delete events are written to your existing GitLab audit trail, and pipeline secret reads stream as audit events that include the originating pipeline and job IDs, so responders can trace where a secret was used without correlating logs across systems.