Yes, its a one step integration into your workflow file, typically before the steps you want to monitor eg. build, test if you don't want to see everything happening in your runner host. It has worked pretty well with ubuntu-latest and stock Linux runners from GH out of the box.
I believe the goal here isn't to replace Vault, but offer a developer focused solution for environment variable management. While Vault can be used to store env variables, its more geared towards managing infra secrets for the ops/sre persona.
Very valid point - the main problem to solve here isn't storage and encryption. We think the clouds do a great job for that, hence our self-hosted approach.
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 [email protected] if you’re interested, and we’d love to talk more about your specific needs!
I don't think its a good idea on take on Vault's complexity. One of the value props i see here is the simplicity of using 'garnet run <scope> -- <executable>' which is something you don't get in Vault unless you write a wrapper (although envconsul provides a similar abstraction: https://github.com/hashicorp/envconsul).
Managing secrets is critical in this day and age for individuals and organizations of all kinds and sizes. Many developers currently find it painful to manage their app configurations and secrets, and this pain grows with stack complexity and team size. This makes building and deploying manual, time-consuming and insecure.
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
Hello can you please stop creating fake accounts with the purpose of boosting your post here. This is otherwise something interesting but im immediately turned off from ever even looking at it if this is how you try and promote your product.
It is plausible that some of these new accounts were made in response to this post, but I don't think its fair to blame the project's developers for it as it isn't necessarily in their control. It seems like they are seeking feedback from the community and there doesn't seem to be a commercial plug here.
These are not fake accounts, but actual developers in our community who have been using Garnet. While a couple of these accounts could be newly created (as not everyone has a HN account, and we announced the launch in our community forum), all comments are actual, and anyone is free to share their opinion on the project (negative or positive). We’d really appreciate if you don’t sabotage the post by responding on every comment, but would love to hear your actual feedback.
> These are not fake accounts, but actual developers in our community who have been using Garnet. While a couple of these accounts could be newly created ...
This is heavily discouraged here, and most of the times it will make users old angry and flag your post. I'd recommend that only 2 or 3 of the main developers are active in the thread. (Or perhaps a power user that is good replying instead or a developer.) There are not hard rules about this, but too many new users is a bad idea.
> all comments are actual
But some of the comments are too optimistic and look like shills, that make old users unhappy and flag the post. I'd recommend to write only one top level comment explaining that you are the developers, and some backstory, and then only reply to questions from old users.
It's very important to reply to technical questions, with clear and technical answers. It buys a lot of good will of old users. (Avoid adjectives like "awesome" , no one used "awesome" yet, but some comments are too optimistic for the dry style of HN).
> and anyone is free to share their opinion on the project
And everyone is free to complain and flag. It's not a good idea to break the explicit or implicit rules of the site. I think bogota first made a few technical questions. It's a good sign that some old user cares enough about your post to ask a technical question.
The questions are unanswered yet. It's not mandatory to reply to every single question (some questions are bad, sometimes they are repetitive, but not in this case). Anyway, I'd recommend to answer most of them.
Try to send an email to the mods and ask how to post again and any additional recommendation.
I did post comments to actually ask what people like about it and why they use this over vault. No one has actually posted anything of substance so please don’t pretend like i am sabotaging you by asking valid questions.
The end result is ~similar, but their configuration is a little more involved and isn't as simple as "give us the commands in your dev environment".
That being said, it seems like they're focused on speed, as they support in memory caching, and have double down on restarting previous commits quickly.
In my opinion the syntax of layerci is relatively simple as someone coming from docker, and does basically boil down to "give us the commands you use to deploy"
However they also have the advantage that they can run deployments on arbitrary runtimes. It looks like reploy only works if my app fits in the runtimes that were preconfigured by you. Because of that, I can run not just my dev deployment, but something very close to my prod deployment as well (we've had multiple bugs that only show up in prod due to our build process).
And finally, their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well. The speedups are typically in the triple digits compared to a reasonably well-optimized build.
I think the differences are major enough that I wouldn't exactly characterize the end results as similar.
> their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well
Makes sense; Reploy actually won't run your tests (or any other CI-esque things to that note). We're very much focused on only spinning up environments!
Overall, there is definitely overlap here. I'd argue that if someone wants to spin up a frontend, backend, db, etc., it makes a lot more sense to enumerate your `services` rather than try and serve them all in a single runtime (I think this is called a Layerfile?). I'm not sure how a use case like this would work with Layer, but that would be my hesitance in trying to set things up.
Layer seems like a great option for running long jobs to really take care of that speed up.
