DEV Community

Cover image for Stop Copy-Pasting .env Files Across Your Team
John Anthony Pecson
John Anthony Pecson

Posted on

Stop Copy-Pasting .env Files Across Your Team

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Now the next developer only needs:

mp login
mp pull
Enter fullscreen mode Exit fullscreen mode

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:

  1. open password manager
  2. find the secret
  3. copy value
  4. paste into .env
  5. hope everyone else has the same value

MeowPass focuses on the usage layer:

mp pull
Enter fullscreen mode Exit fullscreen mode

or:

mp run -- npm start
Enter fullscreen mode Exit fullscreen mode

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?

Top comments (0)