Shared configuration governance
for teams running many services.
OneEnv is a shared configuration governance platform. Teams manage the environment variables, database structure, API contracts, and validation rules their services share — governed like code: staged on a branch, reviewed once, and approved by every affected service, so changing one shared value doesn't mean silently breaking the twenty services that read it.
PAYMENT_API_VERSION is read by 12 services. The platform team needs to move it from v1 to v2.
Edit it in three repos, hope you found every consumer, deploy, and find out which services broke from their error logs instead of from a checklist.
One diff, reviewed once. All 12 consumers are notified with the exact change. Nine approve and move to v2 immediately; one isn't ready yet and stays on v1 — on purpose, not by accident.
The problem isn't where a value is stored
A .env file, a Git repo, or a secrets manager all answer "where do I put this." None of them answer "who depends on this, and did they agree to the new value" — which is the question that actually causes outages.
| Without governance | With OneEnv |
|---|---|
| A shared value is copy-pasted into every repo that needs it, and drifts the moment one copy is edited and the rest aren't. | One shared value, inherited by every service as a linked copy — never pasted. |
| Finding every consumer means grepping repos and asking around. | Every consumer is already known — inheritance is explicit, not discovered after the fact. |
| A change ships the moment someone merges the PR that touches it, whether or not every consumer is ready. | A change is reviewed once, then each consumer approves or rejects it independently before it's live for them. |
| When something breaks, there's no record of who changed what, or who signed off. | Every change, approval, and rejection is in a searchable, append-only audit trail. |
What's actually governed
Four kinds of shared value, one workspace, one engine underneath all of them.
Pull requests, but for shared configuration
Stage it on a branch
Edit a shared value from anywhere in the app — it stages as a change on your active branch instead of applying. Conflicts with concurrent edits are caught, not clobbered.
One review, one merge
Submit the branch and an Owner/Admin reviews the whole diff once — readiness score, impact preview, and comment thread included — then merges it deliberately.
Every service signs off
The merge fans out one notification per affected service, with a risk level and required action. Each service approves or rejects on its own — approval is what goes live.
The core governance loop
Reviewed like a PR
Every governed edit stages on a Branch instead of writing the shared value directly. One Owner/Admin reviews the whole diff and merges it deliberately.
Per-service acceptance
Merging notifies, it doesn't force. Each affected service sees the exact old → new diff and approves or rejects on its own — its export keeps serving the last value it approved.
Impact & risk, computed
Every change is scored 0–100 from how many services it reaches, whether it's breaking, whether it touches a secret, and whether anyone can even act on it.
A history you can search
Every approval, rejection, resync, and override lands in an append-only audit trail — filterable, searchable, and any merged branch can be reverted.
Also included
A weighted health score across services, env, DB, APIs, and validations.
An IDE-style editor for a service's own routes — mapping, validation, drafts.
Shell, dotenv, HOCON, or a custom template — resolved per service.
Owner/Admin/Member, plus per-service permission down to one column.
Connect once; each repo becomes a Service with its env keys pre-populated.
Ctrl+K searches every governed domain, permission-filtered.
What OneEnv is not
- Not a runtime vault or config server — it governs and exports; your deploy pipeline consumes the export.
- Not a database or API gateway — DB structure and validation rules are governed metadata your services honor; no live data flows through OneEnv.
- Not auto-sync — the whole point is that propagation is explicit, per service. Nothing updates itself behind your back.
Common questions
What is OneEnv?
OneEnv is a shared configuration governance platform for teams running multiple services. Environment variables, database structure, API routes and validation rules are staged on a branch, reviewed once, and then each affected service approves or rejects the change before it goes live for that service.
How is OneEnv different from a secrets manager like Doppler or Infisical?
Secrets managers focus on storing and delivering secrets at runtime. OneEnv focuses on the change process for configuration that many services share: who depends on a value, what a change affects, and which service owners approved it. It is not a runtime vault; your deploy pipeline consumes OneEnv's export.
Does OneEnv sync changes to services automatically?
No. Propagation is explicit. After a branch is merged, each inheriting service gets a notification with the exact old and new value and approves or rejects it. A service's export keeps serving the last value it approved.
What does OneEnv govern?
Four kinds of shared configuration: environment variables, database structure (databases, tables, columns), API routes, and validation rules. They all use the same branch, review and per-service approval flow.
Is OneEnv free?
Every workspace gets the full governance engine for free, with no cap on services or members. For complex architectures there is a Custom option, which starts as a consultation. See the pricing page.
Built for teams of 2–50 services
Platform and DevOps leads who need change control without freezing everyone, and service owners who want a veto over what lands in their config.
