Why We Built EnvPilot

The moment that made EnvPilot inevitable was small and mortifying. A client's engineer, onboarding a new contractor, pasted their production .env file into a Slack DM — Stripe secret key, database URL, JWT signing secret, all of it — because that was faster than figuring out whatever secrets tool they were supposed to be using but weren't. The new contractor's laptop, at that point, had root-equivalent access to a production fintech system, and there was no record of it anywhere except a Slack message that would sit in that channel's history forever.

We didn't build EnvPilot because that was novel. We built it because it wasn't. Every team we talked to had a version of this story — a .env.production emailed as an attachment, a WhatsApp message with a database password, a Notion page (shared org-wide) with "temporary" API keys that had been live for eight months. The pattern wasn't bad engineers. It was that the tooling gap between "I need my teammate to have this secret" and "the secure way to do that" was wide enough that everyone just stepped over it.

What existed, and why it wasn't enough

The obvious answer is "use a secrets manager." AWS Secrets Manager, HashiCorp Vault, Doppler — they exist, they work, and almost nobody on a five-person startup team actually reaches for them for day-to-day dev environment variables. The reasons were consistent across every team we asked:

• Too much ceremony for local dev. Nobody wants to configure IAM policies to run npm run dev. The tools built for infrastructure-grade secrets management assume an ops team; most startups don't have one.
• No real audit trail for humans, only for machines. Vault logs API calls. It doesn't tell you "Sarah viewed the Stripe key on Tuesday" in a way a founder doing a security review can actually read.
• Nothing for the "who can see what" problem at the team level. A four-person team doesn't want role-based access control from an enterprise IAM system. They want "the new hire can see staging but not production," configured in under a minute.
• The CLI and the IDE were afterthoughts, if they existed at all. Engineers live in a terminal and an editor. If pulling a secret means opening a web console, they'll route around it — usually by copying the value once and never touching the tool again.

Doppler is the closest thing to what we wanted, and it's a good product. But it's built for a different shape of problem than the one we kept seeing, which was less "enterprise secrets infrastructure" and more "a small team needs to stop pasting things into chat apps, and needs it to be fast enough that they'll actually use it instead of the chat app."

What we built

EnvPilot is an environment variable management platform with three surfaces that all read from the same encrypted store: a web dashboard, a CLI, and a VS Code extension. The design principle underneath all three is that the secure path has to be the fast path, or people won't take it.

The vault. Secret values never touch our database in plaintext. We store them in WorkOS Vault, and Convex — our backend — only ever holds a reference ID. If our database were somehow dumped tomorrow, there's nothing in it to leak. This was a non-negotiable architectural decision from day one, not a feature we bolted on after a scare.

Team RBAC that's actually usable. Admin, Team Lead, Member — three roles, per-project and per-environment scoping, and (for cases finer than that) per-variable access grants. A Member can be read-only on a project but explicitly granted access to one specific database URL they need for a task, without touching anything else in that environment. Setting this up takes under a minute in the dashboard, which was the actual design target — not "is this powerful enough," but "will a non-security-focused engineer actually configure it correctly on the first try."

Version history and rollback. Every change to a variable is versioned. If someone pastes the wrong Stripe key into production, you don't file an incident and manually reconstruct what it used to be — you roll it back, and the audit log shows exactly who changed what and when. This feature exists because we needed it ourselves, on our own products, more than once.

CLI and VS Code extension. envpilot pull drops the right .env file into your project, scoped to the environment you're working in, and it's gone from disk the moment you don't need it — no more .env.local sitting in a folder for six months, occasionally getting git add -A'd by accident. The extension does the same inline in the editor, so you never leave VS Code to check what a variable is set to.

Public API, MCP server, and GitHub Action. This came later, once teams started asking "can our CI pull from this instead of GitHub Secrets?" The REST API and the GitHub Action both authenticate through the same authorization core — org-scoped API keys, SHA-256 hashed, scoped to specific projects and environments — so a leaked CI token can only ever see what it was explicitly granted. The MCP server exists because, increasingly, it's not a human pulling the secret, it's an agent, and we wanted that path to go through the exact same authorization logic as everything else, not a special case with looser rules.

The honest part: what we got wrong first

We started EnvPilot as an internal tool, which was the right call and also the source of most of our early mistakes. Things that were fine for a five-person team using their own product turned out to be wrong assumptions the moment we had actual customers.

The biggest one: we assumed teams were small. Our early permission model was basically binary — you're an admin or you're not. The first mid-sized customer we onboarded had a 40-person engineering org with three product teams that explicitly did not want to see each other's secrets, and our flat model couldn't express that at all. We rebuilt the permission layer around project- and environment-scoped roles specifically because of that conversation, and it's the reason RBAC today looks nothing like what it looked like in our first six months.

The second one, more embarrassing: early versions of the CLI cached decrypted secrets to disk for speed, on the theory that re-fetching from the vault on every command was slow enough to annoy people. It was fast, and it was also exactly the pattern we built the whole product to prevent — a plaintext secret sitting on a laptop, unaccounted for. We tore that out before it shipped broadly, but it's a good reminder that "convenience" and "security" pull against each other constantly, and the pull is strongest exactly when you're not paying attention, because you're focused on shipping.

The third: we underbuilt the audit log before we needed it, and then had to retrofit it under pressure. The first time a customer asked "can you show me every time someone accessed the production database URL in the last 90 days," we did not have a good answer. We do now, but it should have been there from the start — audit logging is one of those features that's cheap to build in from day one and expensive to bolt on after the data model has already ossified around not having it.

Where it is now

EnvPilot started as something we built to stop pasting secrets into Slack ourselves. It went to public beta in 2025, and as of this month we're out of alpha with paid Pro plans on Polar — team RBAC, higher limits, secret rotation, and the API/MCP surface are the things that separate free from paid, everything else stays available because the core problem (people pasting secrets into chat) doesn't stop being a problem just because a team is small and unpaid.

It's our flagship product, and it's the one where our own dogfooding is the most literal — every secret this company runs on lives in EnvPilot, including the ones for EnvPilot itself.

If your team is still emailing .env files around, that's not a judgment — it was us too, eighteen months ago. envpilot.dev is where we ended up instead.