Service Version And Runtime Readback designed
Platform admins and operators need one place to answer:
What version of each service is running in this environment?
This page defines the target readback surface. It is not a substitute for live cluster evidence; it is the product and ops contract for the page or CLI output that should expose that evidence.
Required Readback Fields
| Field | Why it matters |
|---|---|
| environment | distinguishes kind, dev, demo, staging, production |
| service/component id | stable service name such as api, web, billing-worker, node-agent |
| source commit | ties runtime back to reviewed code |
| image digest or binary version | proves the deployed artifact, not only the intended commit |
| config profile | shows which environment/profile contract was applied |
| rollout status | ready, degraded, unavailable, unknown |
| started at / observed at | separates stale readback from current state |
| health endpoint result | quick runtime health signal |
| evidence link | deployment, UAT, or release evidence packet |
Component Families
| Family | Examples |
|---|---|
| Control plane | api, web, terminal-gateway |
| Workers | billing-worker, provisioning-worker, webhook-worker, notification-relay, outbox-relay |
| Runtime/fleet | node-agent, provider adapters, terminal/runtime helpers |
| Data dependencies | Postgres, Redis, NATS, Temporal, object storage |
| Edge/auth | Cloudflare/Pomerium profile, Keycloak realm/profile |
| Docs and evidence | docs portal build, Fairway dashboard/runtime |
Desired Operator UX
The first implementation can be read-only. Mutating actions such as restart, rollback, promote, or drain should stay behind separately reviewed operator flows.
API / CLI Shape
The page should be backed by an explicit read model rather than direct SQL:
GET /api/.../platform/status/components
gpuaas-cli platform status components --environment kind
The exact route path still needs to follow the route modularization model. The important requirement is that it is API-first and stable enough for UAT, support, and release evidence.
Acceptance Criteria
- A platform admin can identify stale or mismatched services without reading CI logs.
- A release operator can prove the deployed commit/image pair after rollout.
- Security can link a running environment to reviewed release evidence.
- Product and support can quickly distinguish product bugs from stale deploys.