theozero

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!

Personally I don't want to write custom code from scratch or glue together 5 tools to do this on every project. I've done it - many many many times... If your project is very simple with a few env vars, it may not be a big deal, but on large projects it quickly becomes a burden. Maybe not one you deal with every day, but regularly - when new teammates join, when new external services are added, when new deployment environments are being used.

Also a big goal here is to have a single tool that will work for all frameworks _and languages_. In monorepo projects, it's very common to have a different custom env var loading and validation setup in each child project, and sharing config across the project is very awkward.

Doing this stuff well is hard, which often means people take shortcuts. So many times dev teams gets stopped in their tracks because someone added a new env var and forgot to distribute it to everyone, or they only added the new key to staging and forgot production. We just want to make doing the right thing the easiest thing.

Imagine if this was just a standard, and when you look at a public docker container, there is a schema of the env vars it takes, rather than digging through the readme. When it boots up, if the env vars are invalid it will give you a clear error message. Imagine when you clone some template project, you get this all this validation and documentation for free, without having to trace through some custom code.

Yes - it is something new, but our hope is that it is intuitive enough to grasp even if it's new to you.

On most projects you end up wiring up a bunch of custom logic to handle your config, which is often injected as environment variables - think loading from a secure source, validation logic, type safety, pre-commit git scanning, etc.

It's annoying to do it right, so people often take shortcuts - skip adding validation, send files over slack, don't add docs, etc...

The common pattern of using a .env.example file leads to constant syncing problems, and we often have many sources of truth about our config (.env.example, hand-written types, validation code, comments scattered throughout the codebase)

This tool lets you express additional schema info about the config your application needs via decorators in a .env file, and optionally set values, either directly if they are not sensitive, or via calls to an external service. This shouldn't be something we need to recreate when scaffolding out every new project. There should be a single source of truth - and it should work with any framework/language.

Exactly. We will do that to stdout - and can patch JS itself too.

The goal here is to just make it dead simple to do the right thing with minimal effort. Get secrets out of plaintext, avoid the need to send them around insecurely, and help make sure you don't shoot yourself in the foot, which is surprisingly easy to do in hybrid server/client frameworks like Next.js.

Can you set up validations, syncing with various backends, and these protections all of this yourself by wiring together a bunch of tools with custom code? Of course... But here's one that will do it all with minimal effort.

This is exactly the kind of thing we are trying to replace. No more hacky custom solutions needed. With varlock you get type safety, validation, and the ability to compose together your config however you need to, without having to reinvent the wheel.

We're still working on the copy. Any specific feedback is appreciated.

Note that you can load env vars into anything via varlock run, not just javascript. The JS integration is a bit deeper, providing automatic type generation, log redaction, and leak prevention.

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.

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.

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.

We think the decorator comments (it’s an open spec we call @env-spec - RFC is here https://github.com/dmno-dev/varlock/discussions/17) are an intuitive addition to .env files that are ubiquitous.

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.

Not every service supports this, and there is still always a ton of config to manage, even if it’s not all sensitive.

I think you might like https://dmno.dev

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

Neat. You might be interested in https://dmno.dev

It let's you define a full schema for your config - including both sensitive and non-sensitive items - and then use plugins to pull sensitive values from a variety of backends, including 1password.

It's a bit more focused on application config rather than injecting a bunch of stuff into your shell, but no reason why you couldn't use it for that too.