Treat a release update as a small, verifiable rollout. Preserve a recovery point, choose the intended channel, and confirm the running version after restart—not only the downloaded version.
Development builds (dev, unversioned builds, and versions marked dev or snapshot) disable release checks and self-update installation. About shows Development build instead of offering a published release. Rebuild from source to update a development checkout. Published alpha, beta, and release-candidate builds use the normal update workflow.
Read the target release notes, export a sealed backup, and make sure you can restore it. Record the running version and important listener settings. Keep console or SSH access independent of the DNS service you are changing.
Database, backup-format, and cross-version cluster compatibility are not yet a published long-term contract. A successful binary downgrade is not proof that newer persistent data is safe for the older build. Use a known-good pre-upgrade backup when recovery requires the older state.
sudo sable update --check
sudo sable updateSable selects the platform archive, checks its published SHA-256, runs the downloaded executable's version command, replaces the executable, and restarts the installed service. Use --version TAG for an exact published build, --pre-release to consider candidates, and --no-restart when you deliberately want to restart later.
After replacement, the previous executable is not a permanent rollback archive. Keep the backup and know where to obtain the previous release.
The console checks for releases after sign-in by default on both primary and replica nodes. A dismissible notice offers Release notes and Install update without leaving the current page. Results, including failed checks, are cached for six hours per node; manual checks remain available. Nothing is installed automatically.
While that setting is on, the primary, or a server on its own, also checks in
the background, every hour unless you choose otherwise. A newer release then
sends an updates alert to the destinations under Settings → Alerts, so you
hear about it without signing in. The alert lasts until the server runs that
release, so it goes out once per release.
Under Settings → General → Software Updates, the schedule under Check for updates picks Hourly, Daily at a time, or Weekly on a day at a time. Times are the server's local time. In a cluster, the primary's schedule is the one that runs.
Turn off Check for updates to disable automatic
checks on this node, including the scheduled ones, and click Save Settings, or set updates.check_on_login = false in sable.toml.
The choice persists across restarts and is not replicated. Update readers can
see notifications; changing the preference requires settings.write.
Include pre-releases is available in the same Software Updates section.
Both Settings controls wait for Save Settings. The About page retains its
release-channel control and updates the same saved preference when changed.
The choice is node-local; editing the release channel in Settings also requires
updates.apply permission.
The About page displays release notes and links the installed version to its
GitHub release. Release notes from a successful check or installation survive
restarts and remain readable while offline. It can check on both primary and replica nodes. Installing requires updates.apply and a deployment that opted into writable service binaries:
sudo sable install --enable-web-updatesFor Docker, opt in with SABLE_WEB_UPDATES=true and retain a restart policy.
For rolling restarts, also set updates.restart_managed = true in each node’s
configuration after verifying its supervisor restarts Sable when it exits.
Installed systemd services are detected automatically. Changes to this supervisor
setting take effect when Sable next starts. Otherwise update by pulling and recreating the immutable container image with the same volume.
The console installs first and then offers a controlled restart. The old process keeps serving until that restart. The Include pre-releases preference is saved per node, including on replicas; changing one node's channel does not change the whole cluster.
Since 1.2.0, clustered nodes keep the Rolling Updates section visible even when updates are unavailable. A warning names the blocking condition, and update actions are hidden until supported. An active rollout can still offer Stop rollout to an authorized operator.
From the primary, open Cluster → Rolling Updates, review Release notes,
and choose Update all. The update notification also offers Entire cluster
in its scope dropdown when every node supports rolling updates. The dropdown
remembers the last selection per user in this browser; its main button becomes
Update cluster or Install update accordingly. This requires both updates.apply and
cluster.write. The rollout pins that exact release across every node, even if
a newer release is published during the operation.
All nodes must be online, fully synchronized, running a published build with rolling update support, and configured for writable binaries and automatic restart. An older node without this protocol continues synchronizing normally, but must be upgraded manually before it can join an automated rollout. Downgrades are rejected; nodes already at the target version are skipped.
The primary reserves the update mechanism on every node, updates each replica in order, and waits until it reports the target running version and current configuration generation. It restarts only when every other node is online and synchronized. The primary updates last, briefly interrupting its console, then verifies the cluster after its restart. The Cluster page keeps progress visible through restarts and marks the version badge with a green check when finished.
Progress is saved to the node's cluster data directory. A failure or timeout stops further restarts; Stop rollout also prevents further nodes from restarting. An installation or restart already authorized may finish. If the coordinator restarts unexpectedly, the rollout stops for operator review. Review partially updated nodes before starting another rollout; an installed binary may need a manual restart first. When a primary disappears or changes, a replica never restarts from stale instructions; abandoned reservations expire after 20 minutes without commands.
Configure clients or your load balancer with multiple DNS servers. Rolling updates keep other nodes serving, but a client pinned to one restarting node can still experience an interruption. Keep mixed-version windows short and avoid changing cluster membership during a rollout. See rolling updates.
Check sable version, process health, a public lookup, an authoritative record, and the cluster generation when applicable. Open About again to confirm the running build.
For opted-in containers, a staged executable runs only when it is newer than the image's build. A newer image takes precedence; removing the opt-in setting makes the image authoritative again. Understand that rule before trying to pin an older image for recovery.
If startup fails, preserve the logs and use the restore procedure. Do not repeatedly switch binaries against a database whose compatibility you have not established.