I built a thing to solve a problem. It has helped me, maybe it will help you?

It all starts with a question.

Why isn’t there a good local secrets manager that encrypts your secrets at rest? I imagine a lot of people, like me, have a number of local applications. I don’t want to pay per-seat pricing just to keep my sensitive data from sitting in plaintext on my machine.

I built an app called LSM Local Secrets Manager to solve that problem. The core idea is simple. Encrypt your .env files locally and only decrypt when you need them (sometimes at runtime).

The Problem

If you’ve got a bunch of projects on your machine, each with their own .env or .env.local file full of API keys you’re definitely not rotating every 90 days. Those files just sit there in plaintext. Any process on your system can read them. And with AI agents becoming part of our dev workflows, the attack surface for leaking secrets is only getting easier.

ThE CLAW EnteRed ChaT

I started looking at Doppler specifically for OpenCLAW. Their main selling feature is injecting secrets into your runtime so they never touch the filesystem. I was like, cool. Also I like that Doppler stores everything remotely. The only thing was the cost did not make sense for me right now. I don’t want to pay $10-20 a month for this set of features.

So what else is there?

Well GCP Secret Manager has its own set of issues.

You can’t have duplicate names per project, so something as common as NODE_ENV across multiple apps becomes a more work than you want to deal with. Some wrapper script that injects prefixes? No thanks. I imagine there are a thousand and one homegrown solutions to solve this problem. Again, no thanks.

So what else is there?

You Find A Solution

AWS Secret Manager

A Problem for Solution Problem

AWS IAM

🫣

I have a lot more to say here on this subject but will save this for another post. Subscribe if you want to see the next post.

The Solution

The workflow is straightforward:

1. lsm init — Run this once from anywhere. It generates your encryption key file.
2. lsm link <app-name> — Run this inside your project directory. It creates a config entry in ~/.lsm/config.yaml for that application.
3. lsm import — Takes your existing .env or .env.local and creates an encrypted version.
4. lsm clean — Removes the plaintext .env files so they’re not just sitting around.
5. lsm dump — Recreates the .env files if you need them back.

But wait there’s more.

Runtime Injection with lsm exec

Remember that cool thing I just told you about? Instead of dumping secrets back to disk, you run:

lsm exec -- pnpm dev

I feel like a family man from Jersey, who don’t mess around. Aye, you got, runtime injection. I got that.

Well that’s lsm anyways. It can decrypt your secrets and inject them directly into the runtime environment of whatever command follows the --. Your secrets exist in memory for the duration of that process and nowhere else. No plaintext files hanging around for other processes to sniff.

Credit to Doppler for the idea. The difference to what we are doing is your encrypted files stay local.

What’s Next

I’ve got some possible ideas of improvements to try building.

• Separate encrypt/decrypt keys — You create secrets with one key, deploy the encrypted file to a server, and use a read-only key to decrypt at runtime. The server never has write access to your secrets.
• Time-based derivative keys — Imagine keys that expire or rotate automatically.
• Secure sharing — Right now you’d have to decrypt and drop the file into a password manager to share it. There’s room to make that smoother.

I’m not sure how to do all of that yet, but we’re making progress.

Why Not Just Use Doppler?

There are genuinely compelling reasons to use Doppler or similar services. I mean bsides the remote storage, access controls and auditable logs. There’s a lot to love.

For local development across a bunch of personal projects? I don’t think you should need a SaaS subscription to keep your secrets encrypted.

LSM is still early, but the core workflow is there and it works.

Give it a try if you’re tired of plaintext .env files scattered across your machine.