Release channels
Consortium has three release channels. Production is the only channel exposed to users today; staging and dev exist for internal validation and can be opened up later without a rewrite.
| Channel | API host | Audience |
|---|---|---|
production | api.consortium.dev | Everyone |
staging | api-staging.consortium.dev | Internal QA |
dev | api-dev.consortium.dev | Engineering |
Each channel is fully separate: its own API host, its own desktop app identity, and its own update feed — a staging build can never accidentally update itself into production, or vice versa.
How each surface updates
Section titled “How each surface updates”CLI. Distributed via npm. The installer at
https://api.consortium.dev/install always resolves the channel-correct
package, and the CLI prints an update banner on launch when a newer
version exists (npm install -g consortium@latest to apply; set
CONSORTIUM_NO_UPDATE_CHECK=1 to silence the check).
Desktop app. Self-updates through a signed (minisign) updater feed, checked per channel and OS-version-aware — an update that requires a newer OS than yours is skipped rather than offered. The app’s UI bundle can also ship independently of the shell through a signed module-update mechanism with server-side promote/rollback, so most fixes arrive without a reinstall.
Web app. Deployed server-side; always current on reload.
Daemon. Versioned with the CLI but long-running: the app warns when a machine’s daemon is too old, and the desktop app manages its bundled daemon itself.
Mobile. iOS and Android are coming soon; update mechanics will follow the stores.
Emergency blocks
Section titled “Emergency blocks”A specific client version can be centrally blocked (e.g. a build with a serious defect). Blocked clients are told to update immediately and refuse to proceed — this is the break-glass path, separate from normal update advisories.