Dashboard: Deployments

Status: target state, fully unimplemented. No rollout orchestrator, no deployment profile records, no rollout dashboard. This page documents what should exist.

Target view

A list of deployment profiles, each carrying:

• Profile name, version, scope (Device set), authority root.
• Active rollout (if any) with phase, progress, gating health.
• Recent rollout history, success/failure outcomes.
• Buttons: edit profile, start rollout, abort current rollout, rollback.

Drill-in to one profile:

• Manifest content (what runtimes, which versions).
• Devices currently on this profile, broken down by phase.
• Per-Device transition status during a live rollout.

Drill-in to a rollout:

• Phase timeline.
• Health gate decisions per phase.
• Audit of advance/rollback events.

What exists today

Nothing of the above.

What exists is the per-Device record set (<host-home>/runtimes/*.json) — see Deployments / Deployment profiles. Operators today manage versions by (manually) shipping a new wrapper version to each Device.

What the target needs

Per WORKSTREAMS/docker-npm-parity/:

1. Profile records. Versioned manifests. Stored as a new actor or as files in a known location.
2. Reconciler. Computes per-Device diffs between profile and live state, emits host.control ops to converge.
3. Rollout orchestrator. Phase machine: canary → bulk → full, with health gates between phases.
4. Health gate evaluator. Runtime-health probes, error rate signal, configurable thresholds.
5. Rollback path. Apply previous profile revision to already-advanced Devices.
6. Audit pipeline. Structured events per phase transition.
7. UI in matrix-web.

This is a multi-month effort. It is not on the launch path.

Manual workflow today (the admin's job)

1. Build the new wrapper version.
2. Decide a rollout order (canary device first).
3. SSH or remote-deploy to each Device in order.
4. Verify each Device after upgrade (system.devices.devices.list, app cards).
5. If something goes wrong, downgrade the wrapper on already-upgraded Devices.

Per Rollouts and Rollback, this is the present procedure. It does not scale beyond a small fleet.

Why a dashboard is essential

Without the dashboard, every rollout is a custom script. With it:

• Rollouts are reproducible.
• Audit trail is automatic.
• Rollback is one click, not a manual ssh-loop.
• Failed rollouts surface visibly.

This is why the platform-admin dashboard is the single largest target-state line item.

See also

• Deployments / Deployment profiles — design.
• Deployments / Rollouts — design.
• Deployments / Rollback — design.
• Operations: Deploy package update — admin user flow (target).
• Operations: Roll back package update — admin user flow (target).

Source: WORKSTREAMS/docker-npm-parity/. No code today.