Demo and Staging Setup designed
Demo and staging should not be special laptop states. They should be repeatable environment profiles that reuse the same release, UAT, and readback model as kind and dev.
Environment Roles
| Environment | Purpose | Must prove |
|---|---|---|
| kind | fast integration and feature validation | contracts, web flows, API behavior, smoke tests |
| dev | shared continuous delivery target | deploy, migration, UAT, provider wiring |
| demo | curated stakeholder path | supported apps, clean data, user guide, product story |
| staging | production-like two-node profile | release mechanics, HA assumptions, rollback, ops evidence |
| prod | controlled production profile | environment hardening, rings, observability, support |
Desired Setup Flow
Demo Environment
Demo is for product and stakeholder walkthroughs. It should be clean, stable, and explainable.
| Area | Demo requirement |
|---|---|
| Identity | named demo users for user, tenant admin, platform admin, and ops personas |
| Apps | supported app matrix seeded and launchable |
| Data | small, readable project/resource names |
| Billing | deterministic balances and visible usage changes |
| MFA | user setup, manage, recovery, and admin recovery paths demonstrable |
| Docs | user guide links and screenshots match the deployed build |
| Reset | reset script returns demo to known-good state |
Staging Environment
Staging is the production-model rehearsal. It should be stricter than demo and less curated.
Minimum staging proof:
- two-node cluster profile is rendered from config;
- service images and source SHA match CI output;
- DNS/TLS/edge routing is read back;
- database, Redis, NATS, Temporal, Keycloak, API, web, workers, and terminal gateway have version/readback status;
- UAT covers user, tenant admin, app developer, platform admin, and ops flows;
- rollback and restore procedures are tested or explicitly blocked.
Supported-App Matrix
The demo/staging app matrix should include at least:
| App/runtime | Why it matters | Proof |
|---|---|---|
| Jupyter or notebook runtime | common GPU user workflow | launch, connect, stop, usage evidence |
| Slurm reference controller | non-trivial scheduler/runtime integration | provision, reconcile, state transitions |
| RKE2 self-managed controller | cluster-style app proof | deploy, connect, cleanup |
| Simple OCI app | baseline app SDK path | manifest, launch, status, logs |
Version And Evidence Readback
Every setup should produce:
- source SHA;
- image digests or binary versions;
- environment profile name;
- Cloudflare/DNS hostnames;
- migration/readiness status;
- UAT package link;
- portal publication build id;
- residual blocked items.
Use Service Version Readback as the target UI/API model.
Exit Criteria
A demo or staging environment is ready when a new operator can:
- render the profile from config;
- deploy from a known SHA;
- run UAT without private tribal knowledge;
- reset or roll back within the documented scope;
- show product, security, and ops evidence from the portal/readback surfaces.
Canonical sources