If you've worked on a system with more than two or three services, you already know this pain: someone adds an environment variable, and three deploys later a service that depends on it starts throwing 500s in production — because nobody told that service's team the variable existed.
Multiply that across env vars, database schema, API routes, and validation rules, and you get the quiet chaos most teams just learn to live with: config spread across a dozen .env files, tribal knowledge about "who needs to know when X changes," and Slack messages that say "hey did anyone update the shared config?" after something has already broken.
That's the problem OneEnv is built to solve.
What OneEnv does
OneEnv governs the shared surface area between your services — env vars, database structure, API routes, and validation rules — through a Git-style branch-and-review flow.
Instead of a change to shared config landing silently in one repo and rippling out as surprises later, OneEnv makes the ripple explicit:
- One shared change — propose a change to an env var, a schema field, a route, or a validation rule in one place.
- One notification — every service that actually depends on that piece of config gets notified, automatically, without anyone having to remember who to ping.
- Explicit approval from every affected service — the change doesn't just quietly happen. Each affected service reviews and approves it, the same way a pull request gets reviewed before it merges.
In other words: the same discipline you already trust for code review, applied to the environment your code runs in.
Why this matters
Most teams already have great tooling for reviewing code changes. What's usually missing is the same rigor for changes to the environment that code depends on — the env vars, the schema, the contracts between services. Those changes tend to happen out-of-band, get discovered by accident, or get "reviewed" after the fact when something breaks.
OneEnv treats environment changes as first-class, reviewable artifacts — not side effects.
Who this is for
If your team:
- runs more than a handful of services that share config, database structure, or API contracts,
- has been bitten by a "silent" config or schema change before,
- wants approval and visibility on environment changes the same way you get it on code changes,
...OneEnv is built for you.
Try it out
We're just getting started, and we'd love feedback from teams dealing with this exact problem. Take a look and let us know what you think:
Top comments (0)