OneEnv
Log in
Use case

Microservices configuration management

Once a system is split into many services, the configuration they share — URLs, feature flags, database shapes, API contracts, validation rules — stops living in one place. This page describes the problems that creates and where OneEnv helps (and where it doesn't).

The shared-configuration problem

Each service usually owns its own repository and its own deploy pipeline, but a surprising amount of configuration is shared in practice: the base URL of the payments API, a feature flag three services read, the name of a column two services both query. Without a deliberate mechanism, that shared state is copy-pasted into every consumer.

  • Drift. One copy is updated, the others aren't, and staging stops resembling production in ways nobody notices until an incident.
  • Unknown consumers. "Who reads PAYMENT_API_VERSION?" is answered by grepping repositories and asking around.
  • Unreviewed change. A config edit often ships with less scrutiny than a code change, even though it can break more services at once.
  • No record of consent. When something breaks, there is no record of which owners knew about the change or agreed to it.

What changes with a governance layer

OneEnv keeps one shared definition per value in a workspace, and each service inherits it as a linked copy rather than a pasted one. That makes the dependency explicit: the list of consumers of a value is data, not tribal knowledge.

Shared master
one definition per workspace
→
Services inherit
linked, not pasted
→
Change staged on a branch
reviewed once
→
Each service approves
or rejects

What OneEnv governs

  • Environment variables (including secrets, masked on every read path other than export).
  • Database structure: databases, tables and columns that services inherit as a whole, per table, or per column.
  • API routes owned by a service, including url, method and request fields, which other services can inherit or depend on.
  • Validation rules that can be assigned to columns and request fields.

Service ownership is modelled with per-service permission levels (none, view, edit, service_admin). Members only see services they have been granted; workspace Owners and Admins see everything. The service-level permission is what lets a service owner approve or reject a change to their own configuration.

Seeing the web of dependencies

Because inheritance, API dependencies, route sources and table relations are recorded, OneEnv can render a workspace dependency graph and, for any branch, show how far its changes reach. A Workspace Report adds a health score and configuration checks such as unused variables, duplicate keys and circular API source chains.

Where OneEnv is not the right tool
OneEnv is not a runtime secrets vault or config server, and it does not push values into running processes. It governs and exports; your deploy pipeline consumes the export (shell, dotenv, HOCON or a custom template, optionally pulled in CI with a scoped export token). If you need secret rotation, dynamic credentials or a runtime agent, pair it with a secrets manager — see the Doppler and Infisical comparisons.

Next

See how a change is approved across services, read the tool-agnostic governance guide, or follow the getting-started walkthrough.