The origin
MeVault grew out of building Kanotion. At the time, I kept hearing about agentic development and wanted to explore it, but I did not want that experimentation to compromise the safety of my projects or expose sensitive development credentials.
My first solution was to use PowerShell SecretStore. It worked for my own workflow for a while, but it also revealed a broader problem: developers need a straightforward way to protect and use project secrets without adding unnecessary friction.
That led to a new question: instead of solving this only for myself, why not build something that I could use across my own projects and that other developers could use for theirs? MeVault began as my attempt to answer that question.
The question
Can developers manage secrets with less friction while retaining ownership and control of their sensitive data?
The experiment
MeVault is a local-first secrets management tool for development. It is designed to keep credentials close to the developer, make their purpose understandable, and reduce the unsafe workarounds that appear when existing tools interrupt the development flow.
What local-first means here
The primary copy of a developer’s secrets stays on their device. Core workflows should not depend on a remote service being available, and control should remain with the person using the tool.
What I am testing
- A simple way to organise secrets by project and environment.
- Safe access without repeatedly copying sensitive values.
- Clear mental models for storage, encryption, and recovery.
- Useful defaults that do not hide important security decisions.
Design principles
- Local ownership by default.
- Security that is understandable, not mysterious.
- Minimal interruption to existing development workflows.
- No unnecessary collection or transmission of secrets.
Next procedure
Validate the local storage and encryption model, then test the core workflow against real development projects before expanding the feature set.