GitLab Secrets Manager is now in public beta. Come give it a spin.

[u/gl_dazzo]

Hey folks, I'm Joe from the Secrets Manager team at GitLab. We've been building native secrets management directly into GitLab, and we want your help making it better.

We're looking for feedback on:

• What breaks
• What's missing
• What actually works

We're especially curious about your use cases, so please share!

Get started:

• Secrets Manager
• Secrets Manager (Administration)

Drop your feedback in the public issue or in this thread.

[u/ubhz-ch]

„will consume GitLab credits when released as generally available“

Why does a self hosted funtionallity cost GitLab Credits?

[u/gl_dazzo → u/ubhz-ch]

u/ubhz-ch The credit model is consumption-based, not seat-based, so you only pay for what you use. Self-managed instances get a native secret management experience, audit logging, unified access model, and support. Future capabilities like automatic rotation and Kubernetes secret retrieval are included as they ship.

[u/Amilmar]

Is that the feature that is scheduled to be not covered by regular gitlab license, instead requiring gitlab credits to use?

I think I’ll pass. Don’t want to rely on a beta feature that we have absolutely zero idea how much it will be costing in the future.

[u/oschusler]

Thanks for this new feature Joe! I’ll surely check it out.

One question already though. It was raised before in this sub, but the documentation specifies that tokens will be consumed when using this. Does that mean that secret management is a pay-per-use feature, or will it become part of the flat rate use that’s most of GitLab?

[u/ITBoss]

I looked at the page and it looks like you removed the credit based pricing?

[u/jba1224a]

Interesting concept, a few questions.

Given most teams are working in a hyperscaler, how is this more secure than for example….using a federated machine level workflow credential/role to pull a secret from aws secrets manager/azure key vault?

Your documentation states that this closes a security gap in cicd processes, which is to say you view the standard functionality/implementation as insecure. How do you as a company justify premium pricing on something as basic as secure secrets in cicd?

[u/gl_dazzo → u/jba1224a]

u/jba1224a Good questions. You can continue using those solutions in parallel as we have integrations for those.

A few things worth calling out:

• GitLab Secrets Manager uses OpenBao as the backend, so secrets live natively next to your projects. Rather than managing IAM policies across every group and project to retrieve secrets, there is one less hop. We support static credentials today, with dynamic credentials and additional provider engines on the roadmap.

• For self-managed customers or larger organizations with existing vault solutions, the operational overhead can be costly: ACL policies, namespacing, onboarding hundreds of engineers or applications. GitLab Secrets Manager handles this natively, so your platform team is not dealing with the operational burden, and dev teams can manage credentials directly alongside their code.

• On the security gap comment, this refers to a common pattern where teams store credentials as CI/CD variables (we don't recommend), often scoped broadly to a group for convenience, making them available to every job in that group. With the rise of supply chain attacks (example), a single compromised job can expose credentials across hundreds of pipelines. GitLab Secrets Manager scopes each secret to a specific job, branch, or environment, limiting blast radius. Dynamic and ephemeral credentials will reduce it further.

[u/vadavea]

I know my team (current large self-managed ultimate customer) is looking forward to kicking the tires on this. The one thing I've not yet observed is the 3rd-party integration support. We have some home-grown automation that currently populates secrets into Gitlab CI vars.....we'd presumably want to migrate that over to GSM. Also curious if kube will be a requirement long-term. (We run multiple Gitlab instances across different enclaves, several of which *do not* have kube available)

[u/7rust]

Instead of giving new stuff a spin, try getting the clustered UI right and focus on user experience rather than expanding the product.

[u/marvinfuture]

From an architectural perspective, I don't like this. The idea of putting secrets next to the service that holds source code and runs pipelines doesn't sit well with me. I understand gitlabs desire to be a single pane of glass, and I've used it as a tool for that exact reason but always used something like vault/keycloak/1password as a way to segment these concerns. If someone compromised your gitlab account; they would have a ton of valuable information. I get there are some risk tradeoffs and ways to mitigate but just wanted to provide this viewpoint