I've spent a lot of time lately thinking about why secrets leak. Not because people are careless, but because the secure path usually costs more than the easy one. Someone needs a connection string to get unblocked, so it goes into a Slack DM or an email, and that's the moment the leak actually starts.

Writing about a gap is easy. So I built SettLock, and I want to walk through why it looks the way it does.

The part that's easy to miss

The industry's answer to secrets sprawl is real and it works. Secretless architecture, workload identity, a vault that issues short-lived credentials instead of handing out static ones. If you're running cloud-native infrastructure with a platform team behind it, that's the right call. I'd tell you to build it that way.

But most teams might not have that setup. They're running a handful of environments on a shared drive everyone already trusts, without a dedicated platform function to lean on. Asking them to stand up a vault cluster before they've even hit fifty services isn't a security upgrade. It's a chore they'll quietly skip, and the config file goes right back to being pasted around in chat.

So the question I kept sitting with was: what does security look like for the team that already exists, not the team a vendor wishes existed?

What I actually wanted

A few things had to be true for this to work for a small team:

No server to run. If setting up the tool takes more effort than the leak it prevents, nobody will use it. A vault that's just a folder, sitting on OneDrive or a network share, means the team's existing habits don't have to change.

Encryption that doesn't trust the disk. If a laptop gets lost or a shared drive gets synced somewhere it shouldn't, the config files sitting on it need to be unreadable without the right key. Not obfuscated. Actually encrypted.

Roles that mean something. Not every engineer needs to see every environment's secrets. A developer touching the Dev and UAT config shouldn't be able to read production values just because they have access to the same folder.

A passphrase that never leaves the person who owns it. If the tool stores your password anywhere, even hashed in a shared file, you've just built a new single point of failure.

What I built

SettLock is a desktop app for managing appsettings.json files and secrets. Right now it only works with JSON configs, so if your stack leans on .env files or YAML, this isn't there yet. It's built with Tauri and Rust, so the whole thing is around 5 MB and runs natively on Windows, macOS, and Linux.

Every config is encrypted at rest with AES-256-GCM, and the encryption key is derived from your passphrase using Argon2id, which is memory-hard and expensive to brute-force on a GPU. Your passphrase itself is never stored anywhere. Only a fingerprint of it is kept, just enough to confirm you're using the same one across sessions.

There's no server because there doesn't need to be one. The vault is a folder. Point your team at the same OneDrive, SharePoint, or Google Drive path, and everyone works off the same source, each with their own encrypted copy of whatever they're allowed to see.

Roles are enforced in both the UI and the Rust backend, not just hidden behind a menu:

  • Admin sees and manages everything, including users
  • Editor can update the configs they've been assigned
  • Viewer can read everything but change nothing
  • Developer is scoped to Dev and UAT only

Remove someone from the team, and their encrypted copies go with them. There's nothing left behind to clean up later.

Why this, and not the vault everyone tells you to buy

I'm not arguing that SettLock replaces a proper secrets manager at scale. It doesn't try to. What it replaces is the thing that actually happens today at teams too small for that scale: the Slack paste, the email attachment, the shared doc nobody remembers to lock down.

A stat from GitGuardian's research stuck with me while I was building this. Twenty eight percent of leaks start outside of code entirely, in the tools people reach for when they're moving fast and the secure option is slower. That's not a code problem. That's a friction problem. And friction is something you can actually design against.

Where it goes from here

SettLock is at version 1.0 right now, available for Windows, macOS, and Linux. It's free to use, and I built it because I wanted to prove to myself that "offline-first, zero cloud dependency" wasn't just a paragraph in an article, it was something you could actually ship.

If you're a small team that's been putting off doing anything about your config sprawl because every option on the market assumes you're bigger than you are, take a look. I'd genuinely like to know if it holds up against how you actually work.

You can grab it at labs.iatharva.tech/settlock.html.