I Built a CLI Tool That Fixes the "Bro Send the .env File" Problem

Saran Hiruthik — Fri, 29 May 2026 06:16:07 +0000

What I Built

Every dev team has this conversation. Someone joins a project, opens their terminal, and the first message they send is "bro can you send the .env file" — and someone else pastes it raw on WhatsApp or Slack like it's nothing. API keys, database passwords, Stripe secrets, all of it flying around in plaintext on chat apps.

I built envman
a CLI tool that syncs .env files across dev teams securely. Two commands is all it takes:

envman push   # encrypts your .env and uploads it
envman get    # pulls, shows a diff, asks before overwriting

The entire .env is encrypted with AES-256-GCM on your machine before it ever leaves it. The server stores only ciphertext. Even if the database gets compromised, secrets are unreadable without the user's token. Built entirely in Go — a CLI binary and a REST API backend with JWT auth, role-based access control (owner, coordinator, member), and a full audit trail of every push.

Demo

GitHub: https://github.com/SaranHiruthikM/envman

$ envman register
Name: Saran
Email: saran@example.com
Password:
Registered and logged in successfully

$ cd myproject
$ envman init
Project name: my-app
Project 'my-app' created and linked
.envman.json created — commit this to git

$ envman push
Secrets pushed successfully

# teammate on another machine
$ envman get
Changes:
  + STRIPE_KEY=*** (new)
  ~ DATABASE_URL=*** (changed)

Apply changes? [y/n]: y
.env updated

The Comeback Story

This project lived in my head for weeks. I knew the problem was real — I had sent .env files over WhatsApp myself more times than I want to admit. But every time I sat down to build it I got stuck on questions I hadn't answered: where do secrets actually live, how do roles work, what happens when two people have conflicting values, how does encryption work without a shared key.

The project had a rough main.go and nothing else.

What changed: I forced myself to design everything before touching code. The database schema, the API endpoints, the role system, the encryption approach — all of it locked down first. Once the design was solid, the code almost wrote itself. In three weeks I went from a blank file to a working CLI with a full backend, migrations, middleware, client-side encryption, and a diff engine.

The hardest part wasn't the code. It was resisting the urge to skip the design phase and just start typing. Every hour I spent thinking before coding saved me three hours of rewriting later.

The moment it clicked was when I ran:

rm .env
envman get
cat .env

And my secrets came back perfectly decrypted. That felt real.

My Experience with GitHub Copilot

I used Copilot mostly as a thinking partner rather than a code generator. The parts where it genuinely helped were the repetitive but error-prone ones — writing SQL scan statements where column order matters, getting the AES-GCM nonce handling right, and wiring up cobra command flags.

What surprised me was how useful it was for catching things I would have missed on a first pass — like forgetting a return after an error response, or using || instead of && in a role check that would have let anyone through. Small things that would have cost me 30 minutes of debugging each.

Where I deliberately didn't use it was in the design decisions — the schema, the role model, the encryption architecture. Those needed to be mine. Copilot is good at "how do I write this" but the "what should I build and why" has to come from you. That line matters more than people admit.

envman is live, open source, and something I'll actually use on my own projects. That's the bar I set for myself — build something real enough that you reach for it yourself.

DEV Community: Saran Hiruthik

I Built a CLI Tool That Fixes the "Bro Send the .env File" Problem - envman