Who we are
We're a small team of backend and platform engineers who kept running into the same problem at every company we worked at: environment variables sprawled across dozens of repositories, with no single place to see who consumes what, and no reliable way to know what breaks when one value changes.
OneEnv is the tool we wished existed — built for the engineers who actually get paged when a misconfigured DATABASE_URL takes down production, not just another dashboard nobody opens.
Why we created this
On one team, we maintained 22 repositories across PHP, Node.js, Python, Scala, React, and Angular, sharing close to 50 environment variables. Every time a shared variable changed — a rotated key, a new database host, a config flag — someone had to manually grep through every repo to figure out which ones actually consumed it and needed updating. It was slow, it was error-prone, and when something broke in production, there was no audit trail explaining why.
We built OneEnv around one idea: one change should produce one notification, with a clear checklist of every repo that's actually affected, and an explicit approve/reject decision per service — instead of tribal knowledge and manual repo hunting.
Where it's grown since
Environment variables were never the only shared thing that breaks a service silently. We kept applying the same idea — one change, one notification, explicit approval — one layer at a time: first to database structure (tables and columns services depend on), then to API contracts a service exposes to others, then to the validation rules behind the data itself. Four domains now, one shared governance engine underneath all of them.
Then we noticed the four domains didn't actually agree on how a change reached that notification — env edits went live immediately, API and validation edits sat as a hidden draft swept up by a Publish button, and database proposals used a third mechanism entirely. So we unified all of it: now every governed edit stages on a Branch, gets reviewed once like a pull request — readiness score, impact preview, and a comment thread included — and is merged deliberately, with each individually affected service still getting its own approve/reject on the value itself, exactly as before. One consistent way in, four domains benefiting from it at once.
The newest layer is visibility. Once every change flowed through one spine, we could finally measure it: every notification now carries a computed impact score and risk level (reach, breaking-change detection, secret sensitivity, governance gaps), every approval and rejection lands in a searchable audit History, any merged branch can be reverted, and a Workspace Report rolls the whole thing up into a health score you can act on. Governance you can't see isn't governance — it's paperwork.
Two smaller but practical additions since then: workspaces that already live on GitHub can connect once and import repos as real Services with their env keys pre-populated, instead of typing every one in by hand — and once a workspace has grown past a handful of services, a single Ctrl+K search reaches every governed domain at once instead of hunting page by page.