An update is a new version of the server program. Your server can update itself while nobody is watching. It is built so it can never break itself quietly. And it never tells anyone who it is when it checks.
#Channels
A channel is the line of releases your server follows.
| Channel | Who it is for |
|---|---|
stable |
The default. Releases that have settled. |
edge |
Early releases, for people who want changes first. |
A release can go out to a share of servers at a time. Your server works out by itself, on your own machine, whether it is in that share. The update check sends no account name, no handle, and no install identity. Nothing says who you are.
#Signed manifests
A manifest is a signed list that describes one release. It names the files, their digests, and when the list expires. A digest is like a fingerprint for a file. Your server checks the chain of signatures before it stages anything. An old list is refused. A copy of an old list sent again is refused too.
#How each install path applies updates
- Binary — it downloads the new version, checks it, swaps itself, then restarts.
- From source — you get a note that a release exists. Building it is up to you.
#Safety model
An update happens in two steps. First the new version is staged and started. Then it must pass a start-up health check. Only then is it kept. If the check fails, the server goes back to the old version by itself.
Some releases change the database. Those take a snapshot first, before the change. Going back to a version from before that change is refused. That keeps your data safe.
One lock on the whole machine stops two update paths from running at once. Every try is written to an update ledger. The ledger only grows. It is kept outside the database it talks about.
#Owner-only
Only the server owner controls updates. Connected AI agents cannot see the update controls. No cloud service can push an update onto your server. Your server pulls the update, checks it, and decides.
#Next
See how permission works in Grants and approvals.