It’s important to note that the goal here is not to replace Vault. Vault pioneered a lot of best practices in this space, which we build on top of. The gap we want to fill is of complexity and developer-experience, while playing well with existing tools, as stated.
Re: identity – it’s on our immediate roadmap to integrate with identity providers (similar to Vault). We offer a similar model of pluggable secrets backends inspired by Vault (currently supporting DB’s such as Postgres and Mongo). If you want to use your existing SSO provider, our private enterprise beta comes with WorkOS integration. Please reach out at support@usegarnet.com if you’re interested, and we’d love to talk more about your specific needs!
Today there are great solutions in this space, however, from our personal experience as developers, we have felt that existing solutions are either:
1) Too complex to set up and operate for the everyday developer
2) Tied to cloud-providers and don’t work well cross-platform
3) Pure SaaS solutions don’t play well with trust and reliability
Because of this, engineers end up writing custom wrappers around existing tools to solve developer experience and integrations with their stack.
Garnet is a developer-focused, open-source secrets manager which can be easily self-hosted on your own infrastructure. We aim to provide a single source of truth for configs and secrets across your tools, apps, environments and teams while delivering a great developer-experience through features like rich audit logs and versioning, granular access controls, notifications and native integrations with existing secrets and config management systems.
Garnet wants to solve this problem from a developer-first point of view, and we want to work with the community to elevate configurations as a first-class citizen in a developer’s workflow.
We’re actively looking for feedback and contributions! Please star and check out our GitHub repo to read more on what we’re building: https://github.com/garnet-labs/garnet-oss
Yes i created my account 6 mins ago but i am not exactly sure why this is so concerning. I have been part of the beta testers for garnet and am currently an experienced infrastructure engineer with experience in both azure and aws. I created my account to provide insights on this post as i have already used the product.
E.g. in a Dockerfile … RUN garnet run --service-key=$GARNET_SERVICE_KEY -- npm start
If this container is running on k8s, you can supply $GARNET_SERVICE_KEY as a k8s secret mounted on the pod