Operations
Operating model
Cluster upgrades, key inventory, disaster recovery inputs, and pilot engineering objectives.
v1 design baseline. This page specifies intended behavior. Delivery and validation are tracked in the implementation plan; it is not a claim that the platform is already implemented.
Runtime upgrades
Use:
- Versioned cluster-agent releases
- Canary pilot nonproduction cluster
- Compatibility contract
- Rolling node updates
- Artifact rollback
- Database backup before service upgrades
- Signed images
- Dependency inventories
Key rotation
Document rotation for:
- Artifact signing
- Cluster mTLS CA
- OIDC credentials
- GitHub App key
- Object-storage credentials
- Organization secret wrapping keys
- SCIM bearer tokens
- Break-glass authenticators
Disaster recovery
The runtime cluster should be reconstructible from:
control-plane desired state
signed artifacts
routing/policy metadata
database snapshots
KV recovery policy
secrets/KMS
Only stateful application data and secrets require protected recovery; runtime workloads themselves are disposable.
Internal pilot objectives
Initial engineering objectives, not contractual SLAs:
Control plane/gateway availability: 99.9%
App database RPO: ≤ 15 minutes
App database RTO: ≤ 4 hours
Artifact rollback: minutes, not hours
Preview for template app: single-digit minutes
Audit/event delivery: at-least-once with idempotent processing
These targets must be validated during the pilot before becoming contractual commitments.