This article reads like more of an ad than anything else.
> Environment variables only deliver values
Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default.
> A string is not a schema
Yes, input validation is an application concern. The application should know what these values represent / how to parse them and error if they're invalid.
I could go on, but the article is all about trying to use a hammer as a screwdriver and complaining that the hammer doesnt work.
Hm, I haven't seen these issues personally. We only have one `.env` file and it's just for local secrets. Configuration emphatically does not go in `.env` and ideally is in docker compose and defined in code (we use Pydantic Settings).
This is why I love direnv (the tool) and just a simple .envrc (not .env). It has none of the problems posited in the OP's article. It assumes nothing, only that direnv manges loading up the .envrc into your shell.
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 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 :)
That's what we are using as well in our small team. `mise` for our non-sensitive values/ environment variables and then `fnox` (from the same author) to encrypt and manage the secrets.
`mise` has a plugin for `fnox` that allows to automatically load the secrets in the context when running a mise task/command.
This way, our secrets are never exposed, even during local development.
Setting this up was effortless. Pretty happy about these tools.
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!
You keep saying that but I disagree strongly. Having looked at both fnox and secretspec, there are some obvious similarities because they're both in the same space, interacting with many of the same tools, and there are only so many ways to declaratively state "set the FOO variable with the 'my_secret_key' value out of the Bar provider".
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'm sure there are many better alternatives to .env, but its ubiquity and support across various tools makes it super convenient.
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.
But secrets are a kind of configuration, right? I agree they should be kept separate from non-secret config; ideally non-secret configuration can be committed to your codebase somewhere depending on the environment it's running in.
pydantic-settings is not limited to loading from config files. It is easy to populate a settings model from environment variables, for example. With a little bit of glue code it could load from the secretspec sdk.
I hate that it's hidden too. There's no reason for it to be hidden and arguably some reason for it not to be hidden.
I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.
It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.
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.
> Environment variables only deliver values
Yes, the problem .env files try to solve is having "environment variables" be injectable from a file so that different applications can have different environment variables by default.
> A string is not a schema
Yes, input validation is an application concern. The application should know what these values represent / how to parse them and error if they're invalid.
I could go on, but the article is all about trying to use a hammer as a screwdriver and complaining that the hammer doesnt work.
https://x.com/0xPrajwal_/status/2084163731534311627
https://x.com/nilbuild/status/2084339074639200488
The issue is that agents need structure and context.
It may be time for Hackernews to integrate a Pangram detector into the UI, similar to what substack is doing :)
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.
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
- 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/
start with making it a dot file. Why would you want to hide the fact your app was using loaded environment variables?
I did discover one reason for it not to be just "env" though, which surprised me, which is that "source env" will yield "bash: source: /usr/bin/env: cannot execute binary file". I did not expect the source command to use the $PATH to resolve the filename. Probably some minor security issues that can result from that out there in the world. Arguably anyone loading it should use "source ./.env" or equivalent, with full path.
It's documented in the bash manual, of course. But it is rather complicated as to when it will and will not use $PATH.
(Am I getting thrown out the window now? :)