DevOps Service
The operations API behind the console — the one service that owns no data and reads everything from somewhere else.
devops-service answers every request the console makes. It has no database of its own, no
migrations, and no events: each endpoint reads from Postgres, Kubernetes, Helm, Service Bus,
Datadog, or FeatureHub and hands the answer to a browser.
- Domain
- Operations
- Kind
- Go HTTP service
- Lifecycle
- Active
- flowctl project
- None
- Stacks
- Runs on its own
- Source
- services/devops
Architecture
Scope resolution, the registry, roles, and how the streaming endpoints differ.
Operations
How a scope finds its environment variables, Kubernetes login, and the secrets it needs.
The console
What an operator sees on top of this API.
Why it reads other services' data
Every other service on the platform reads only its own Postgres: Each service owns one Postgres database as the source of truth for its bounded context; services never read each other's databases. database. This one
reads everybody's, which is a deliberate exception to docs/architecture.md rather than an
oversight.
The alternative is worse: every service grows an operations endpoint exposing its own pods, outbox depth, and release history, which spreads the same privileges across a dozen deployments instead of concentrating them in one that can be reviewed. Concentrating them also means one place holds the read-only credentials, one place verifies the operator's identity, and one place logs a rollback.
The canonical service notes live in services/devops/README.md.
The views
What each page in the console shows, where the numbers come from, and which pages can change something.
Architecture
How a scope is resolved, where the registry comes from, what the three roles may do, why logs and terminals sit outside the OpenAPI document, and why log search is not scoped at all.