Whether you like them or not, using env vars is ubiquitous because it's easy. Anything else ends up tightly coupled within your application code or only within the environment. Often you have a set of config needed both for your application and your surrounding dev tools / scripts. This tries a provide a universal solution.
At the end of the day you could imagine varlock loading your config, and injecting it using a method that is not env vars - a file, sidecar process, etc.
Even if you don't set any values in your env files (although why not set some non-sensitive defaults) you can still benefit from the schema and validation that varlock provides.
Imagine every public docker container had an .env.schema which was validated on startup, instead of scattered info about the available env vars in their readme.
Environment variables are a non-standard, limited form of transferring data. Depending on the platform, they may be case-insensitive, there are reserved words, size limits, naming rules, restricted charsets, etc. And their values are always strings. So having a schema on an environment variable isn't very useful, unless you do things like dynamic typing and type assumptions (which run into bugs). It's not a bad idea to have an opinionated library that defines some restrictions on environment variables, but the applications will always need to add more restrictions that your library has thought of.
Schemas are application-specific. Applications all deal with data types differently. Some data types (defined in schemas) even use transforms and complex custom algorithms before their data is validated. So it's better to let the application handle schemas directly on an as-needed basis.
All of that can be done independent of environment variables. Just make a library that validates data types, and pass your environment variables (or any data, from anywhere) to it. This is better not only because you can validate any kind of data, but you can load your data from places other than environment variables (from disk, from database, etc). This kind of general abstraction is more useful for general purpose computing, rather than a complex solution tailored for only one use case.
Finally: A schema isn't a replacement for documentation. Just because you have a technical document that defines what data is allowed in a variable, doesn't mean that somebody then knows what the hell that thing does - what it affects, when it should or shouldn't be used, etc. Documentation is for humans, schemas are for computers.
We say "made for sharing" because .env.schema replaces .env.example which always drifts from reality - and often requires insecurely sharing secrets manually.
Even if not setting values within your files, you can rely entirely on env vars in the platform where the code runs and still benefit from validation provided by varlock.
Right now we give 1Password as an example, but you can use any provider that has a CLI. We are also working on a plugin system that should make it easier to integrate with any provider.
As for redaction - that note is about how we redact your secrets from _our_ CLI output. However we also provide tools to redact within your application. Right now this works only in JavaScript, by patching global console methods. We will also hook into stdout for varlock run, similar to what the 1Password cli does.
The leak detection is much more interesting - especially in hybrid client/server frameworks, where you can easily shoot yourself in the foot.
By removing plaintext secrets from env files, we totally remove the risk of them leaking via AI code assistants, which I guarantee is happening millions of times a day right now. Also the schema itself and autogenerated types give AI much more context about your env.
Right now, you can use any provider that has a CLI to fetch a single secret. In the near future, we'll be adding native plugins to make these integrations even easier.
Vault can be a huge lift and doesn't make sense for many projects - we wanted to build a tool that makes sense from day one, even when there is no backing provider, but can grow with your team and change providers seamlessly.
Tons of folks have plaintext secrets in their env files which are leaked via AI assistants every day. By getting those out of plaintext, the risk is totally removed.
The schema itself (and the automatic types it can generate) also gives AI more context about what configuration is available, and what each item is for.
> plaintext secrets in their env files which are leaked via AI assistants
So…we're not just talking about secrets then. Any text in any file could be leaked. The solution isn't simply moving secrets out of env files, the solution is, um,
*not leaking the contents of local files*
My god. Have we forgotten all semblance of how security & privacy in computing should work?
Hey all! Co-creator of varlock here. Varlock is the next evolution of what we learned building https://dmno.dev. We wanted to make things simpler (no more proprietary TypeScript schemas) and meet folks where they already are: .env files.
The hope is to remove the papercuts of dealing with env vars (and configuration more generally) by introducing an easy to understand system for validation, and type-safety, with the flexibility to use any third party provider to persist your secrets. We found ourselves reimplementing this stuff on every project, wiring together many tools and custom code, only to end up with a mediocre outcome.
The very common pattern of using `.env.example` leads to constant syncing problems, with many folks resorting to sharing .env files and individual secrets over slack, even when they know they shouldn’t. By turning that example into a schema and involving it in the loading process, it can never get out of sync. With validations built in, if something is wrong, you’ll know right away with a helpful error instead of an obscure runtime crash.
Because the system is aware whether things are sensitive or not it means we can do things like log redaction and leak prevention on the application side of things. Many tools try to do scanning but use regexes, while varlock knows the actual values to look for. We felt these were problems especially worth solving in a world where more frameworks are running the same code on both the server and client.
We intended to share this ourselves on here next week but you beat us to the punch. We’re in the midst of shipping the drop-in next.js integration (hopefully just merged today).
I also see a few comments about the “AI friendly” part. Right now tons of folks have sensitive keys in their .env files that are being leaked to AI assistants left and right. By removing plaintext secrets from env files, it entirely removes this problem. We also want to highlight the fact that with this DSL on top of .env we’re making it much easier for LLMs to write safer code. Part of creating devtools is trying to understand how they will be used in the wild so we’ve been trying to work with common tools (Cursor, Windsurf, Claude, Gemini, etc) to make sure they can coherently write @env-spec for varlock.
We’re literally just getting started so all of your feedback is super valuable.
We’ll continue to expand support for non-js languages (which already work via `varlock run`) as well as add more integrations, and eventually some CI/CD features for teams to help track and manage config.
You might like https://dmno.dev (full disclosure, I am one of the creators)
It lets you manage all your config and pull from various backends (like 1Password or an encrypted file within your repo). I have not built a GCP Secret Manager plugin yet, but it would be very easy and is on the roadmap!
Since a lot of your config is not actually sensitive (the NEXT_PUBLIC items), this would let you manage it within your repo, and toggle according to env or compose things together however you like.
It also provides validation, coercion, type-safety, leak prevention, and a lot more. Happy to help if you want to try it out.
It has this kind of functionality (via plugins) but also does a lot more. Validation, coercion, type-safety, composability, sharing config across monorepos, leak detection…
We don’t have all of these providers as plugins yet, but they are super easy to write.
Would love to have you collaborate with us - it’s open source.
First off, congrats on getting this published! It's a big jump from "this kind of works for just me" to "tested, documented, flexible, and ready for others to use", so good on you for seeing it through! Seems like it has some nice DX improvements from sops, dotenvx, and other encrypt-your-secrets-within-your-repo type of tools. While that strategy may not work for every project, it is certainly valid and makes sense in some cases.
If you are looking for a tool that solves some of these problems, but also provides a more complete toolkit for dealing with config, check out https://dmno.dev
It has a plugin system and while we have an encrypted file plugin that works like places-env, we also support syncing secrets from places like 1Password, Bitwarden, Infisical, with more plugins in the works (aws, gcp, azure).
Additionally it handles:
- validation and coercion
- full type-safety (currently only for TypeScript, but generated types for other languages are coming soon!)
- built in documentation for your config
- sharing config across projects in a monorepo
- composing config any way you want, not just limited to an
env switch and string templates
- manage all config, not just sensitive values
- better conrol of static/dynamic config (which values can be replaced at build time)
- security features (log redaction, leak prevention) for JS/TS
- drop in integrations for many frameworks and tools
- additional tools for dealing with various platforms (vercel/netlify/cloudflare/etc) that provide pre-built schemas defining env vars they inject, and additional tooling
- flexible type system to reuse existing config type definitions that come with built-in validations, docs, etc
It's built in TypeScript, and you define your config schema in a TS file, but it is designed to be used in projects in any language, providing a unified config system for your whole stack.
Would love to hear what you think. Pop into our discord and say hi :) https://chat.dmno.dev
At the end of the day you could imagine varlock loading your config, and injecting it using a method that is not env vars - a file, sidecar process, etc.