Deployment Models
Purpose: which of CMDash's deployment shapes your workspace runs as, and where to find the operational runbooks for it.
The full design rationale lives in
docs/cmdash/03-deployment-models.md
— that document carries a "superseded / shipped" banner because it was
written as a decision proposal before any of it existed; the decision it
argued for has since shipped. Read it for the "why," not as a live
how-to — the summary below and the runbooks it links to are the current
operational reference.
The three shapes, in admin terms
CMDash standardized on one packaging approach — a single Docker Compose package, run identically across topologies — rather than three separate codebases:
| Shape | What it means for you as an admin |
|---|---|
| Hosted (SaaS) | CMDash operates your instance; you never touch infrastructure. Updates are applied by us. |
| Self-hosted, updater enabled | You run the compose package on your own infrastructure (e.g. AWS Lightsail); you apply updates yourself from Settings → Updates. |
| Self-hosted, updater disabled / on-prem | You (or your ops team) run and update the stack directly on the host, outside the in-app updater. |
This is the same three-way split Self-Update and Updating CMDash describe from the update-mechanics side — this page is the deployment-topology side of the same fact.
Where the operational detail lives
docs/runbooks/production-deploy.md— the deploy procedure.docs/runbooks/production-secrets.md— secrets/config for a production instance.docs/runbooks/control-plane-deploy.md— the control-plane app (multi-tenant hosted fleet management), relevant if you operate more than one instance.
These runbooks are written for the person running the infrastructure, not the day-to-day workspace Admin — most readers of this admin guide will only need the table above and a link to Settings → Updates.