Updates

Updates are designed so an unattended server stays current without ever being able to break itself silently — and without telling anyone who it is.

#Channels

Releases can roll out gradually. The rollout percentage is evaluated locally, so your server decides for itself whether it is in the wave, and the update check is identifier-free — it sends no account, handle, or install identity.

#Signed manifests

One signed release manifest describes each release: artifacts, digests, and expiry. The server verifies the signature chain before staging anything, and stale or replayed manifests are rejected. Container images referenced by a manifest are digest-anchored, never floating tags.

#How each install path applies updates

• Binary — downloads, verifies, and swaps itself, then restarts.
• Managed container — the launcher image never changes itself; it applies verified server binaries onto the data volume.
• Pinned container — never self-updates. You pull the new digest when you choose.
• From source — you are notified that a release exists; building it is up to you.

#Safety model

Applying is two-phase: the new version is staged, started, and must pass a boot health check before it is kept — a failed check reverts to the previous version automatically. A release that migrates the database takes a pre-migration snapshot first, and a rollback that would cross a migration boundary is refused rather than risking your data. A host-wide lock prevents two update paths from racing, and every attempt lands in an append-only update ledger kept outside the database it describes.

#Owner-only

Update controls belong to the server owner. They are not exposed to connected AI agents, and no cloud component can push an update onto your server — the server pulls, verifies, and decides.

#Next

Understand the enforcement model in Grants and approvals.