RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
82% Positive
Analyzed from 479 words in the discussion.
Trending Topics
#https#env#dev#secretspec#secrets#tools#fnox#support#varlock#same

Discussion (16 Comments)Read Original on HackerNews
I'm using 1Password's .env integration[1] and although the UX is a bit clunky, I really like it. My API keys are secure, tools that ordinarily support .env just work and there's a team-sharing feature too (although I'm yet to use it). It's pretty neat.
[1] https://www.1password.dev/environments
A big difference between our tool and many other similar tools is that we combine the schema and value setting into one surface, with a way of merging many definitions together, much like cuelang - but in a way that feels more intuitive. It's extremely flexible, and can even do credential brokering for untrusted workloads.
I've been enjoying the secretspec content lately, and watching it evolve :)
Varlock is clever. Sub string types for .envs pretty cool, why not
The difference is that we're providing an interface for applications to build with, with 8 SDKs available so you can have first-class support for secrets whatever you're bulding. I do hope fnox copies that too!
Those inherent similarities aside, I don't see it. They don't seem to have a lot in common as far as design or implementation or configuration.
- Secrets don't belong in config https://secretspec.dev/blog/secrets-dont-belong-in-config/
- You want to have flexibility of choosing between any secrets provider: https://secretspec.dev/blog/but-i-use-sops/
(Am I getting thrown out the window now? :)