Env Box

EnvBox exists because sending .env files through chat is a bad habit that everyone still has.

Omid was moving between machines at home, pulling the same repos, and re-pasting database URLs for every environment. Existing tools were either paid, heavy, or built for companies with a platform team. He wanted two commands, encryption he could explain, and the ability to revoke someone who left.

What shipped:

• A Next.js dashboard to create projects and variables.
• Better Auth for accounts, with email verification.
• Invite tokens that expire (1h / 6h / 24h), used once, scoped to environments.
• A CLI published as envbox-cli: npx envbox-cli join <token>, then npx envbox-cli pull dev.
• AES-256-GCM at rest (key not stored in the database), API keys hashed like passwords, instant revoke.

This is an MVP. That is stated on the repo on purpose. The interesting part for clients is not “we built a unicorn.” It is: we can take a painful internal workflow, turn it into a small product with auth, a database, and a CLI, and not hide the seams.

Live and source: envbox.omidbagheri.com · github.com/omid-baghery/envbox

The longer narrative — why the security model looks like this, what we would not do again — is in the EnvBox case study.