News for hackers. Stuff that matters.

theozero

Re:TIL: Loading .env files into my terminal on Thursday October 01, 2026 @12:46PM (#49924037)
check out varlock.dev (free and open source) Adds validation and has plugins to pull from anywhere (1pass, aws, keepass, etc)
Re:Claude Code Stores OAuth Tokens in Plaintext on Wednesday September 02, 2026 @11:29PM (#49545608)
Related for secret handling tools like secretspec and varlock (https://varlock.dev), there's no way to securely hand claude code sensitive env vars for use with MCP. While it will do env var replacement in your MCP config, there's not really an easy way to set those vars. If using the cli you can wrap the `claude` command (bit awkward), but when running the desktop app, there is nothing.

I opened an issue here - https://github.com/anthropics/claude-code/issues/88757 - please chime in!

Re:The Twelve-Factor App on Friday August 28, 2026 @01:01PM (#49481449)
I won't disagree that it comes with security tradeoffs and depending on the situation it can definitely be a problem. But in many cases with how people deploy lots of software - most PaaS and things like lambdas / cloudflare workers, etc - it's absolutely fine. With varlock, we can even swap out the secret delivery mechanism at the end - but you still get a schema and familiar interface for how it all works.
Re:The Twelve-Factor App on Friday August 28, 2026 @12:20PM (#49480756)
.env as we know is full of problems... BUT! check out varlock (https://varlock.dev) - it's free and open source, and we have really modernized and adapted the familiar syntax (a small DSL on top) to make it much better.

Has built-in validation, type-safety, composition via functions, loading with plugins, leak prevention, and much more.

Try adding varlock on top. It fixes some of the rough edges of using 1pass for dev purposes. Lots of neat features. We are 1pass users ourselves so our 1P plugin is quite good.
Varlock solves many of these problems, and a lot more. Including having a built in credential broker - and works everywhere. Missing some easier DX around things that are typically detected from global files, but working on it.
https://varlock.dev (free, open source) can pull secrets from many places, and has a credential broker (proxy) to inject placeholders, then replace with real secrets at the network boundary. There are a few other tools like this, but ours seems to be the most flexible so far.
Re:Where .env Went Wrong on Tuesday August 04, 2026 @03:19PM (#49173591)
Varlock sounds like what you might be looking for. Free, open source, and very flexible toolkit to use however you like.
Re:Where .env Went Wrong on Tuesday August 04, 2026 @03:17PM (#49173556)
Varlock has bw plugin too - and similarly you can either wire up individual items or pull a whole env style blob from a single item if you prefer.
Re:Where .env Went Wrong on Tuesday August 04, 2026 @02:27PM (#49172809)
FYI - You can pull a whole .env style blob from a single item using varlock. Never written to disk and supports caching behind Secure Enclave.
Re:Tailscale didn't stop the Hugging Face intrusion on Saturday August 01, 2026 @12:02AM (#49130915)
Of course there's no single solution and a multi-layered defense is needed... But as the article mentions, a huge step is first getting credentials out of plaintext, and then out of the process entirely using a "credential broker" (proxy) pattern - that means injecting placeholders, and replacing them in a MITM proxy. It's important of course to isolate the agent from the broker via sandboxing.

Varlock (https://varlock.dev -- free, open source) is a complete config+secrets toolkit that helps manage secrets, pull them from various secure places, provides such a credential broker. There are a few others out there, but most require a specific vault tied to the broker, while ours is open source and uses plugins to pull secrets from wherever you want.

Many sandbox and other AI services are now building this as a feature into their platforms, but Varlock is meant to be a universal toolkit that you can apply anywhere, without being coupled to the platform's proprietary vault and solution.

Re:Where .env Went Wrong on Friday July 31, 2026 @12:40PM (#49125461)
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.
Re:Where .env Went Wrong on Friday July 31, 2026 @12:37PM (#49125411)
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 :)

Looks great. The "credential broker" pattern (inject placeholders, replace in proxy) is something we just added to https://varlock.dev (totally free and open source).

Rather than using a dashboard, ours is configured within a .env.schema file, and rather than our own vault, we can pull secrets using our plugins (16 and counting) including Infisical, 1Password, Bitwarden, AWS, GCP, Azure, more. Also very useful for coding tasks in general, as we have integrations for most frameworks, and add built in validation, type safety, leak detection, etc.

Will definitely be keeping an eye on OneCLI to compare notes.

Re:Ask HN: How do small teams securely share env files? on Saturday May 23, 2026 @10:32AM (#48248069)
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.
Re:CISA Admin Leaked AWS GovCloud Keys on GitHub on Tuesday May 19, 2026 @12:20PM (#48195402)
Get everything out of plaintext!

Varlock is a great and flexible way to do this.

Re:CISA Admin Leaked AWS GovCloud Keys on GitHub on Tuesday May 19, 2026 @12:13PM (#48195303)
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.
Re:Using Changesets in a polyglot monorepo on Monday May 04, 2026 @05:24PM (#48015205)
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.

Show HN: Bumpy – versioning/changelog tool, fixed 120 open changesets issues

https://github.com/dmno-dev/bumpy

Meet bumpy - your new favourite open-source versioning, release, and changelog tool. Especially useful in monorepos with many related packages, but also great to use in simpler setups.This is a modern successor to the popular changesets tool, used by many open source projects.While changesets is great, and I love the file-based bump+changelog workflow, the project has hundreds of open issues,...

( Read More... | no comments | 3 points | on HN )
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 step up.
Re:Coding Agents Are Reading Your .env on Thursday April 09, 2026 @02:38PM (#47707784)
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.

Re:The .env File Nobody Needs on Wednesday April 01, 2026 @10:52AM (#47601748)
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.
Re:Stop Putting Secrets in .env Files on Wednesday March 04, 2026 @05:38PM (#47254971)
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.

Re:Stop Putting Secrets in .env Files on Tuesday March 03, 2026 @01:24PM (#47236534)
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).

https://github.com/dmno-dev/varlock

Older »