Stop Copy-Pasting .env Files Across Your Team

John Anthony Pecson — Wed, 06 May 2026 13:03:10 +0000

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 .env file?”

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 .env files

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 .env drift
avoiding secret handoff over chat

The difference is roughly:

dotenvx secures .env files
MeowPass helps teams stop manually passing .env files 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 .env quickly?”

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.yaml the right mental model?
Does git clone -> mp login -> mp pull feel 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:

https://github.com/meowrithm

Website:

https://meowpass.dev

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?

DEV Community: John Anthony Pecson