HN user
Check out varlock - it’s a free and open source toolkit to help with this. It has built in validation, extra protection for your secrets, and uses plugins to pull sensitive data from most common sources. Also has built in local encryption with biometric unlock.
Get everything out of plaintext!
Varlock is a great and flexible way to do this.
You might like varlock - it helps keep secrets out of plaintext by using plugins to pull from various backends (aws ssm, gcp, vault, 1pass, etc). Also has built in local encryption with shared team vaults coming soon.
Additionally provides pre commit scanning, log redaction, and much more.
We piggyback on .env files with a new DSL rather than introducing a new file.
Using plugins that register new functions, you can fetch from many different backends (15 and growing). The main difference if I understand correctly is that the wiring of vars to where those things live does live in committed code, but is totally declarative and safe. It's also incredibly flexible since functions can be written to make things idiomatic for that backend. Keeping that within git makes sense to us, as you ideally want deployments to be immutable.
The other benefit is this gives you a way to manage both sensitive and non-sensitive config - with a single source of truth for validation, types, docs.
Check out https://varlock.dev - it uses functions and a plugin system to pull from different backends. But also allows composing values together in whatever way you like, has built in validation, extra protection for secrets, and a ton more.
check out https://bumpy.varlock.dev - still a bit of work to do to make other languages even easier, but it fixes a few things with changesets around custom publishing.
Totally - the only completely safe way is to inject keys in a proxy and keep them out of the process. But getting them totally out of plaintext is a great first step, both to keep it from AI and malicious scripts that are looking for keys.
You will probably like varlock - it helps get your keys out of plaintext, while giving your agents a schema and additional tools so it can interact with env vars safely. The next step is injecting your keys via proxy, but just varlock is a huge improvement as a first step. Generally provides a ton of quality of live improvements as well, whether working solo or on a team.
Another tool that helps here is https://varlock.dev (free + open source!)
There are plugins for many different secret storage solutions, including infisical - as well as native local encryption (ie secure enclave on mac) that will be released very soon.
Plus it adds validation, imports, log redaction, leak prevention, and a ton more.
Check out https://varlock.dev - it makes .env files useful and safer!
You might like https://varlock.dev (free and open source) - it has a plugin system so you can follow this pattern but pull from many different backends. Plus it provides a lot more... like being able to import shared config/schema from other files, validation, log redaction, composing values together with functions.
Keepass plugin is in an open PR, should be merged soon!
You'll probably like https://varlock.dev (free and open source) Im just about to roll out similar built in secure-enclave encryption with fingerprint unlocking. But integrated into a larger tool that does validation, type generation, secrets protection, and a bunch more cool stuff!
Check out https://varlock.dev for a modern take on .env that gets your secrets out of plaintext. Free and open source - works with tons of tools. Adds validation, type safety, lots of nice features.
Reading from 1Password definitely does add some overhead, but at least our integration fetches in bulk so should be ~2s total and not scale with number of secrets. For team members, they don't need any service accounts, so its just making sure they are granted vault access, which can be managed through team settings you likely already have set up anyway. Add new team member to "devs" and you're done. Anyway certainly not perfect, but sure beats a lot of the other options.
Should be easy enough to set up a keyenv plugin - varlock adds a lot of additional last mile tooling to get secrets/config integrated into projects, regardless of where they ultimately live.
While the 1Password model is not perfect, you can organize your vaults however makes sense for your project. You can do prod/staging/dev, or by projects, etc. Or you can use the new environments feature and create a separate "environment" for each. Service accounts and users can be granted access to specific vaults only.
The huge benefit is that if you are already using it for other stuff, there is no additional "secret zero" to set up - plus you get biometric unlock for your secrets.
Easiest way to use it for dev purposes is varlock (although I'm biased since I created it).
You will probably really like https://varlock.dev
It’s a whole toolkit for this - with built in validation, type safety, and extra protection for sensitive secrets.
You might like https://varlock.dev - it lets you use a .env.schema file with jsdoc style comments and new function call syntax to give you validation, declarative loading, and additional guardrails. This means a unified way of managing both sensitive and non-sensitive values - and a way of keeping the sensitive ones out of plaintext.
Additionally it redacts secrets from logs (one of the other main concerns mentioned in these comments) and in JS codebases, it also stops leaks in outgoing server responses.
There are plugins to pull from a variety of backends, and you can mix and match - ie use 1Pass for local dev, use your cloud provider's native solution in prod.
Currently it still injects the secrets via env vars - which in many cases is absolutely safe - but there's nothing stopping us from injecting them in other ways.
Thanks for the kind words. It's actually decoupled and up to the user if they want to use it for pure validation as part of CI/deployment, just to inject values, or to integrate more deeply. But you can get the most benefit by integrating it fully. This lets you set values, compose values using functions, take advantage of coercion, and helps protect your secrets.
You can just use `varlock run -- ...your command` and it will load, validate, and reinject as env vars. This is what enables it to be used with any language or any tool. We have a standalone binary. You could also just use `varlock load` to do validation and rely on values all being set externally. However we do provide javascript helpers to just load everything automatically - although this just calls out to the CLI, keeping your app isolated from the code that loads and validates the vars. For JS we actually go a bit further and patch http and console to protect any sensitive data - because we know exactly which config items are sensitive.
It's really meant to just be a complete complete toolkit and then let users integrate as deep as they want to.
You might like varlock (https://varlock.dev)
You can use it to declaratively fetch from various backends, but it’s optional. At its core it lets you create a .env.schema and you get validation, type safety, guardrails for sensitive values, and a flexible toolkit to deal with all config related headaches.
The big difference from your tool (and many others) is that instead of trying to provide tooling to keep an example and other files in sync, the schema file is part of the loading process, so it can never be out of sync. This also helps create a single source of truth, and helps create a unified system to deal with all config - both sensitive and not.
yeah for our DNS we use a little provider called... Cloudflare.
But hey some tokenized crypto dns provider is probably much more reliable! lol
Better than masking them in a file, get them out of the file entirely! Pull them declaratively instead - https://varlock.dev
This tool also redacts from your logs if working in js.
A proxy is a good solution although a bit more involved. A great first step is just getting any secrets - both the ones the AI actually needs access to and your application secrets - out of plaintext .env files.
A great way to do that is either encrypting them or pulling them declaratively from a secure backend (1Pass, AWS Secrets Manager, etc). Additional protection is making sure that those secrets don't leak, either in outgoing server responses, or in logs.
https://varlock.dev (open source!) can help with the secure injection, log redaction, and provide a ton more tooling to simplify how you deal with config and secrets.
The fundamental idea of CUE (quoting them) "enable[s] data, schema, and policy constraints to coexist seamlessly" is really amazing for some use cases. But from a practical / DX perspective, the language seems pretty awkward and hard to understand. Dump someone who hasn't seen cue before into some complex cue files and they are definitely reading the docs to try to understand what is happening...
We built a similar kind of system with a much more limited scope - for handling environment variables, that is much more ergonomic IMO. It uses .env files with decorator style comments and new function call syntax to mix schema, default values, declarative instructions on how to fetch data, internal references, merging multiple definitions.
Check it out at https://varlock.dev
One really nice thing in varlock for monorepos is the import syntax. This lets you have shared config at the root, or just to break things up however you need. No need for diffing or copy pasting, as the schema validates everything - if something is required, it will yell at you.
I like all the extra scanning features this provides :)
I've seen a few tools like this that try to keep things in sync. While it is better than the alternative of doing it manually, it is still a losing battle and not the greatest DX. Often you still have validation (if it exists) and types that also need to be kept in sync, and documentation is scattered throughout the codebase.
Another approach is to turn the example into a schema - and have it be included in the env loading process. This way non-sensitive values can be included directly, and it can never be out of sync. Only values that differ need to be defined in your git-ignored files or injected by the environment. This is precisely how https://varlock.dev solves this problem. The schema becomes the single source of truth, and is used to generate types as well. It also provides validation, leak prevention, and a bunch of other nice tools.
--
Other env-syncing libraries - https://github.com/luqmanoop/sync-dotenv - https://www.npmjs.com/package/dotenv-safe - https://www.npmjs.com/package/generate-env-example
Getting secrets out of plaintext env files is a fantastic idea, and I hope more people realize how important it is.
Check out https://varlock.dev to add validation, type-safety, and additional security guardrails.
In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of your codebase.
For a more modern approach to .env files that includes built-in validation and type-safety, check out https://varlock.dev
Instead of a .env.example (which quickly gets out of date), it uses a .env.schema - which contains extra metadata as decorator comments. It also introduces a new function call syntax, to securely load values from external sources.
Next.js env var tooling could definitely use some improvement, and pulling from a secure external vault makes sense, but I think there's more to it.
Have you seen http://varlock.dev/integrations/nextjs
This is interesting. Amazing how something so fundamental is still such a pain, and we all build our own half-baked solutions for it on every new project. We've been thinking about this problem for a while now as well, and just launched another tool (https://varlock.dev) that might be interesting for you to check out. Would be very happy to collaborate or just talk about the problem space.
Our tool has similar goals, although a slightly different approach. Varlock uses decorator style comments within a .env file (usually a committed .env.schema file) to add additional metadata used for validation, type generation, docs etc. It also introduces a new "function call" syntax for values - which can hold declarative instructions about how to fetch values, and/or can hold encrypted data. We call this new DSL "env-spec" -- similar name :)
Certainly some trade-offs, but we felt meeting people where they already are (.env files) is worthwhile, and will hopefully mean the tool is applicable in more cases. Our system is also explicitly designed to handle all config, rather than just secrets, as we feel a unified system is best. Our plugin system is still in development, but we will allow you to pull specific items from different backends, or apply a set of values, like what you have done. We also have some deeper integrations with end-user code, that provide additional security features - like log redaction and leak prevention.
Anyway, would love to chat!