11–20 of 77 posts
Also mise: https://mise.jdx.dev/environments/
Over at varlock ( https://varlock.dev -- also free, open source), we agree that .env as we know it is full of problems. But instead of abandoning it, we evolved it. We replace your .env.example with a .env.schema - using decorator style comments to add schema info, and functions to load and compose values. A big difference between our tool and many other similar tools is that we combine the schema and value setting i…
Varlock is clever. Sub string types for .envs pretty cool, why not
Claude, find a key underpinning of most development workflows, then make a product to disrupt (and eventually SaaSify/enshitify) it. Finally, write a convincing ad disguised blog post, and purchase a fancy domain. Here's my credit card.
While there are absolutely a million of these env tools popping up which are total vibe-coded slop, secretspec is not one of them. It's from the creator of https://devenv.sh and has been around for a while.
Claude, find a key underpinning of most development workflows, then make a product to disrupt (and eventually SaaSify/enshitify) it. Finally, write a convincing ad disguised blog post, and purchase a fancy domain. Here's my credit card.
Also mise: https://mise.jdx.dev/environments/
Seconded. I've also had great luck with the same author's fnox secret manager, especially because you can tell it to fetch some secrets from the user's laptop's OS keychain, and some out of 1Password, and some out of AWS KMS, and some out of [probably your own favorite provider ( https://fnox.jdx.dev/providers/overview )].
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!
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.
Earlier quoted context omitted.
Seconded. I've also had great luck with the same author's fnox secret manager, especially because you can tell it to fetch some secrets from the user's laptop's OS keychain, and some out of 1Password, and some out of AWS KMS, and some out of [probably your own favorite provider ( https://fnox.jdx.dev/providers/overview )].
fnox is mostly a copy of secretspec (and it's good to have one!), so you'll find the same kind of support in both. I wish instead we'd collaborate with Jeff, but oh well. 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.
I use Pydantic Settings for this, would be nice to see a comparison to that. I do like the idea of keeping this in a configuration file.
Two things: - 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/
I use Pydantic Settings for this, would be nice to see a comparison to that. I do like the idea of keeping this in a configuration file.
Two things: - 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/