Environment variables run everything.
But the way we manage them?Still messy. Still risky. Still outdated.
So I built PushEnv — a new way to handle secrets.
Here’s the story, in Q&A form.
Who am I and what is PushEnv?
I work across backend, DevOps, and AI infra.Every project I touched had the same problem:
Secrets were everywhere — and nowhere.
PushEnv is my attempt to fix that.
It’s a local-first, encrypted, Git-style workflow for .env files with:
Zero server trust
No SaaS
No lock-in
No dashboards.No logins.No plaintext.
What’s actually wrong with .env files?
On paper, .env files are simple.
In real life, they cause chaos:
Secrets get committed to Git
Keys are pasted into Slack
.env.example is outdated
Teammates have different versions
CI logs leak secrets
Docker images ship .env
No history
No rollback
No audit trail
Most teams rely on:
“Just don’t commit your .env.”
That’s not a strategy.That’s a hope.
Don’t existing tools already solve this?
They help — but they still require server trust.
Even “zero-knowledge” tools route secrets through:
APIs
Telemetry
Server infrastructure
That means:
Risk
Lock-in
Less transparency
What I wanted instead:
“Git for .env files — but encrypted and local-first.”
So I built it.
What makes PushEnv different?
PushEnv encrypts secrets before they leave your machine.
Only ciphertext is ever uploaded.
Key points
AES-256-GCM encryption
Passphrase never stored
Zero-knowledge encrypted secrets stored securely in PushEnv’s managed infrastructure
No central server
No accounts
Full version history
Open-source
The workflow
pushenv init,
pushenv push,
pushenv pull,
pushenv diff,
pushenv history,
pushenv rollback
If you know Git + dotenv,you already know PushEnv.
Why did I build this?
Every project had the same issues:
Different .env everywhere
Secrets in Git history
“Send me the .env?”
No rollback
No diff
CI needing secrets without files
Docker images containing secrets
I wanted something that:
Works offline
Encrypts locally
Needs no login
Works in CI
Supports versioning
Is open-source
Nothing like that existed.
So I built PushEnv.
How does it work (quick version)?
1. Initialize
pushenv init
Choose environments + a passphrase.
Creates:
.pushenv/config.json (safe to commit) ~/.pushenv/keys.json (local keyring)
2. Push encrypted secrets
pushenv push -m "Initial setup"
Your .env is:
Encrypted locally
Uploaded as ciphertext
Versioned
Never stored in plaintext
3. Pull anywhere
pushenv pull
Secrets are decrypted locally and injected safely.
What about CI/CD and Docker?
That’s where PushEnv really shines.
Run apps without writing secrets to disk:
pushenv run "npm start"
Perfect for:
CI pipelines
Docker builds
Secure workflows
Ephemeral environments
Secrets vanish when the process exits.
What stacks does it support?
Anything that uses .env:
Node / Next / Nest
Python / Go
Docker / Kubernetes
GitHub Actions
AWS / Cloudflare / Vercel
S3 / R2 / MinIO
If your app uses env vars — PushEnv works.
Why does this approach matter?
Zero-trust servers
Storage only sees encrypted blobs.
No lock-in
Use your own infrastructure.
Easy to learn
No new mental model.
Full visibility
Diff, history, rollback — for secrets.
How can you try it?
npm install -g pushenv pushenv init pushenv push -m "First secrets"
More commands:
pushenv pull,`
pushenv diff,
pushenv history,
pushenv rollback --version N
Where can you find it?
GitHub:https://github.com/shahnoorgit/pushEnv
NPM:https://npmjs.com/package/pushenv
MIT licensed.Open-source.Transparent.
Final thoughts
Secrets are too important to be:
Shared in Slack
Stored in plaintext
Locked behind SaaS
Lost without history
PushEnv gives developers:
A safer, simpler, and more transparent wayto manage environment variables.
Not an alternative.A new way.
Top comments (0)