Every dev team eventually hits this problem.
A new developer joins the project.
They clone the repo.
Then the first question is:
“Where do I get the
.envfile?”
And the usual answers are not great:
- “Check Slack”
- “Ask someone from the team”
- “It’s in Notion”
- “Use the staging one, but change these two values”
- “Wait, I think that one is outdated”
That is not really a secrets problem.
It is a workflow problem.
Most teams already have some way to store secrets:
- 1Password
- Bitwarden
- AWS Secrets Manager
- Infisical
- dotenvx
- local
.envfiles
But the daily developer workflow can still get messy.
.env files drift.
Staging and production values get mixed up.
New dev onboarding requires manual handoff.
Someone still ends up copy-pasting secrets somewhere.
So we started building MeowPass.
MeowPass is an open-source, CLI-first tool focused on keeping team .env files in sync.
The goal is simple:
git clone repo
mp login
mp pull
That’s it.
No vault ID passed around.
No Slack DM.
No guessing which .env is current.
The key idea: .meowpass.yaml
One of the main design decisions we made was adding a project-level config file:
version: 1
vault: <vault_id>
default_env: development
This file is safe to commit to Git.
It contains no secrets.
It only tells the CLI:
- which vault belongs to this repo
- which environment should be used by default
So after a project is initialized, any teammate can clone the repo and run:
mp login
mp pull
The CLI reads .meowpass.yaml, resolves the correct vault, and pulls the right secrets.
Basic setup
For the first developer setting up a project:
brew install meowrithm/tap/meowpass
mp login
mp init
mp pull
mp init detects existing .env files, creates the vault, imports secrets, and writes .meowpass.yaml.
Then you commit the config:
git add .meowpass.yaml
git commit -m "Add MeowPass project config"
Now the next developer only needs:
mp login
mp pull
Why not just use dotenvx?
Honestly, if you are working solo, dotenvx is probably enough.
It is simple, local-first, and great for encrypted .env workflows.
MeowPass is more focused on the team workflow:
- multiple developers
- multiple environments
- onboarding new teammates
- reducing
.envdrift - avoiding secret handoff over chat
The difference is roughly:
- dotenvx secures
.envfiles - MeowPass helps teams stop manually passing
.envfiles around
Why not just use 1Password or Bitwarden?
Password managers are great for storing secrets.
But in many dev teams, the workflow still becomes:
- open password manager
- find the secret
- copy value
- paste into
.env - hope everyone else has the same value
MeowPass focuses on the usage layer:
mp pull
or:
mp run -- npm start
The terminal becomes the workflow.
Why not Infisical or AWS Secrets Manager?
Those are solid tools, especially for larger teams and infra-heavy setups.
But for small teams, they can feel heavier than needed when the immediate pain is:
“Can everyone get the correct
.envquickly?”
MeowPass is intentionally CLI-first and lightweight.
It is not trying to replace every secret manager.
The first wedge is much smaller:
Stop copy-pasting .env files.
What we are still validating
This is still early.
The main things we are testing:
- Is
.meowpass.yamlthe right mental model? - Does
git clone -> mp login -> mp pullfeel obvious? - Is this simpler than manually syncing
.env? - Would teams trust a zero-knowledge secret workflow?
- Where does this break compared to dotenvx, Infisical, or AWS Secrets Manager?
Open source
The project is open source here:
Website:
We are actively dogfooding it and looking for feedback from devs who have dealt with .env drift, onboarding friction, or team secret sharing.
Would you use a committed metadata file like .meowpass.yaml, or would you rather keep encrypted .env files directly in Git?
Top comments (0)