Why I Created It
Two months ago, someone replied to my tweet asking for ideas for new software.
The reply briefly mentioned the need for a local-based secret manager, which piqued my interest and led me to start researching.
There, I read a surprising article.
It was about how AI agents, under the guise of helping users during development or due to manipulated web search results, could leak .env files.
Security companies like PromptArmor and Mindgard have documented how AI agents can be exploited to extract information from accessible files.
So I decided to create a secret manager that prevents AI agents from viewing .env files and bypassing commands.
The Unspoken Problem with .env Files
Honestly, most people store secrets in plaintext .env files.
It's convenient, it works, and that's how it's always been done.
But because it's plaintext, any process with access to the file can send it somewhere, accidentally commit it to Git, or, as mentioned earlier, an AI could unintentionally leak it.
Additionally, since .env is located in the project directory, it's hard to manage centrally.
Why Not Use Doppler or AWS Secrets Manager?
Doppler is great when working in a team and needing collaboration features.
AWS Secrets Manager is perfect if you're already deep into the AWS ecosystem.
But I'm not part of a team, I don't use AWS, and I prefer offline solutions.
SaaS-based tools like Doppler even require monthly payments.
And there's one key difference between my tool and others: it requires user approval to use secrets.
I built a per-request approval system, not just per-user or per-process (similar to how 1Password's SSH feature works).
Development Principles
Encryption
All secrets are encrypted with AES-256-GCM before touching disk.
The encryption key is derived from the master password using PBKDF2 with 100,000 iterations.
Easy Migration
I designed it to be easy from the start and created guides so you don't have to spend much time learning a new tool.
Lessons Learned While Building
Unexpected Age Barrier
Something I didn't expect: to properly distribute a macOS app, you need to pay $99 annually and join Apple's Developer Program.
I think this is an important security measure for macOS, even if it's inconvenient.
But what might be a bigger issue—and perhaps unique to me—is that you must be at least 19 years old to join.
I'm under 19. So LocalKeys only worked on my Mac.
Others couldn't run it on their Macs without security warnings.
It was frustrating, but it was a good lesson in understanding platform requirements upfront.
Since I couldn't find a proper solution, I'm temporarily showing users how to remove the quarantine attribute after download.
It's not ideal, but it's the only option until I become an adult and join the developer program.
Real User Feedback
After launch, I posted about LocalKeys on Reddit. Someone pointed out, "How do you use the same secrets across multiple devices? Most people use different computers at work and home."
A valid point. I was so focused on "local-first" that I overlooked the multi-device workflow many developers need.
I've now added optional encrypted synchronization to the roadmap, maintaining the local-first philosophy while adding convenience when needed.
The Result: LocalKeys
After two months of development and real-world testing, I launched LocalKeys.
LocalKeys is open source, anyone can build it, it's a one-time purchase, and it's simple.
You can check it out at localkeys.privatestater.com
Is This for You?
Good cases for using LocalKeys:
- Working on personal/indie projects with sensitive credentials
- Want full control over your data
- Need offline access or run behind restrictive firewalls
- Prefer a simpler, more focused tool over enterprise solutions
When LocalKeys isn't a good fit:
- You need team collaboration features right now
- Want ready-to-use cloud synchronization
- Require enterprise audit logs
- Are already satisfied with Doppler/1Password CLI, etc.
Planned Features
- Linux support
- Optional encrypted synchronization between devices
- More language integrations based on feedback
I'd Love Your Feedback
This is my first desktop software, and I'm sure there are things I haven't considered.
- What other secret management issues are you facing?
- Do you prefer an offline-first approach, or do you favor cloud-based solutions?
- For those working across multiple devices, how do you currently handle credential synchronization?
- Does the concern about "unauthorized access even when encrypted" resonate with you?
As an indie developer, building publicly is both scary and exciting.
If you've faced similar security concerns or have thoughts on the approach, I'd really appreciate it.
And if you try LocalKeys, please let me know what breaks!
Note: This isn't to say cloud solutions are bad. They're great for team or enterprise use cases. This is just a different approach for different needs.
Top comments (0)