Varlock Wants to Kill Your .env Files. Should You Let It?

Every few months, someone announces they've solved environment variables. Usually it's a SaaS product that costs $49/month per developer and requires you to trust another third party with your secrets. This time it's an open-source tool called Varlock, and the pitch is actually interesting: what if your .env files never contained secrets at all?

The Better Stack team demos Varlock as the solution to a problem every developer knows—you clone a repo, try to run it, and nothing works because you're missing the .env file some other developer has squirreled away in encrypted storage. Or you onboard someone new and have to manually send them credentials through Slack because nobody can remember the team's secret-sharing protocol.

Varlock's approach is different from password vaults or secret management services. Instead of storing your secrets, it creates a schema file that defines what environment variables your application needs and where to fetch them from at runtime. The schema itself contains no secrets—just instructions. "This will be the source of truth for all of our environment variables and should be able to be committed to GitHub in a public repo," the demo explains.

The mechanics are straightforward. You define variables in an .env.schema file using a domain-specific language called @env-spec (which the Varlock team wrote). Then you run varlock run before your normal startup command, and it fetches the actual values from wherever you've stored them—1Password, Bitwarden, AWS Secrets Manager, your local shell—and injects them into your application's environment at runtime.

What This Actually Solves

The schema approach addresses a real architectural problem: the disconnect between what your application needs and where those values live. Right now, if you want to add a new API key, you have to update your code, update your .env file, update your .env.example file, update your deployment scripts, tell your teammates, and hope everyone remembers the change when they pull. With Varlock, you update the schema once, commit it, and everyone pulling the code knows exactly what's required.

The type-safety angle is less revolutionary but still useful. You can declare that PORT should be a number, that DATABASE_URL should be a URL, that API_KEY is required. The tool validates these at startup rather than letting you discover type mismatches when your app crashes in production. As the video demonstrates: "If I were to change it to number, then we can see we get an error because it's expecting a string."

The 1Password integration is where this gets interesting for teams. Instead of each developer maintaining their own .env file with copied credentials, they authenticate to 1Password once, and Varlock pulls the secrets directly. Change an API key in 1Password and everyone automatically gets the new value on their next run. No Slack messages, no ticket to DevOps, no accidentally pushing the old key to production.

The Hidden Complexity

But here's where my skepticism kicks in: Varlock isn't eliminating complexity, it's relocating it. You're trading the simplicity of a plain-text file for a plugin system, a custom DSL, and a runtime resolution layer. That's not necessarily bad—plenty of worthwhile tools add complexity to solve harder problems—but you need to understand what you're getting into.

The demo glosses over some operational questions. What happens when 1Password is down and you need to deploy a hotfix? The presenter acknowledges you can't use Varlock offline: "If you're coding at an airport, you'll have to use your hard-coded environment variables. But honestly, who's really coding without the internet?" That's cute until you're on a plane debugging a production incident.

There's also network latency. "There is a bit of delay when it's fetching passwords from a different provider. So, it will take a tiny bit longer to start up your scripts." For local development that's annoying. For CI/CD where you're spinning up containers constantly, those seconds add up.

And then there's the odd bug the presenter encountered: "If I used the same name in my schema file as the name of an environment variable for my local shell, it used that environment variable locally instead of the one from one password." That's the kind of behavior that makes sense to someone who understands variable resolution order but seems like black magic to everyone else on your team.

The AI Safety Theater

The marketing copy mentions making .env files "safe for AI" and protecting against "prompt injected AI agents fetching secrets." This is addressing a real concern—you probably shouldn't let Claude or GitHub Copilot see your production database credentials. But Varlock's solution is just not storing the credentials in the file, which you could already accomplish by... not storing credentials in the file.

The actual innovation here is making it easier to not store credentials in the file while still maintaining a clear contract about what credentials your application needs. That's valuable, but it's not AI-specific magic.

Where This Goes

Varlock is actively developed and honestly pretty clever in its approach. The schema-as-source-of-truth model is sound. The plugin system for different secret providers makes sense. The TypeScript type generation and log redaction features show thoughtful design.

What I'm watching for is adoption patterns. Does this become standard in new projects, or does it stay in the "interesting tool some teams use" category? The answer probably depends on pain points. If you're a solo developer or small team with simple secrets management, Varlock is probably overkill. If you're a larger team struggling with onboarding friction and secret sprawl, this could be worth the complexity budget.

The real test isn't whether Varlock works—the demo shows it clearly does. The test is whether it works well enough, reliably enough, with few enough surprises, to justify adding another dependency to your stack.

I've seen enough "this changes everything" secret management tools to know that most teams will keep using whatever currently works until the pain of the status quo exceeds the pain of migration. Varlock might be good enough to clear that bar. Or it might join the pile of technically-correct-but-never-adopted solutions that litter the developer tools landscape.

Either way, it's an interesting answer to a real problem, which is more than you can say for most new tools.

—Mike Sullivan