Why I Built pushenv
Environment variables are everywhere in modern applications.
APIs, databases, feature flags, third-party services — everything depends on them.
Yet most teams still manage envs the same way they did years ago: plain .env files passed around manually.
It works — until it doesn’t.
The problem with .env files
.env files are simple, but they don’t scale well.
As soon as more than one person is involved, things start to break down:
- env files are shared over Slack, email, or WhatsApp
- new developers need manual setup every time
- different machines have slightly different values
- staging, prod, and local drift apart
- nobody knows which variables are required or optional
The file exists — but there’s no structure, no validation, and no visibility.
Sharing envs is the real pain
The hardest part isn’t creating envs. It’s sharing them safely and consistently.
Typical questions every team asks:
- “Do you have the latest
.env?” - “Which variables are required now?”
- “Why does it work on your machine but not mine?”
- “Did prod change or is this local?”
Plain .env files don’t answer these questions.
What I wanted instead
I didn’t want a heavy secrets manager or a complex dashboard.
I wanted something that:
- feels as simple as
.env - works locally by default
- makes required variables explicit
- helps teams stay in sync
- reduces onboarding friction
- doesn’t hide what’s happening
That idea became pushenv.
What pushenv actually does
pushenv focuses on developer experience first.
At its core, it helps teams:
- define environment variables clearly
- validate them at runtime
- share them securely
- keep environments consistent
- avoid silent misconfiguration
Instead of guessing, developers know exactly what’s expected.
A simple workflow
Instead of this:
# README.md
Create a .env file and ask someone for values
You get this:
pushenv pull
npm run dev
If a required variable is missing, the app doesn’t start.
No surprises. No guessing.
Environment visibility & consistency
pushenv makes environments easier to reason about:
- what variables exist
- which ones are required
- which environment you’re running against
- what changed between versions
This reduces:
- “works on my machine” issues
- accidental misconfigurations
- onboarding time for new developers
Designed to be transparent
One thing I was careful about while building pushenv:
- no hidden behavior
- no silent overrides
- no magic env injection
- always opt-in
- always inspectable
If a developer runs something locally, they should understand exactly where values come from.
Who pushenv is for
pushenv is built for:
- small to mid-size teams
- startups moving fast
- backend-heavy projects
- OSS projects with contributors
- anyone tired of env confusion
It’s not meant to replace enterprise secrets managers.
It’s meant to replace fragile .env workflows.
Why it’s open source
pushenv started as a tool I wanted for my own projects.
Open-sourcing it:
- keeps the design honest
- encourages better defaults
- helps other teams solve the same problem
- and improves the tool through real usage
Final thought
Environment variables shouldn’t be mysterious.
They should be:
- predictable
- visible
- easy to share
- and hard to misuse
pushenv exists to make that the default.