Updates

Built and lab-tested

• One path for every installation: the panel notices a signed release, the root agent checks it again, and the new release's own installer does the work.
• Signed releases on a channel (stable, beta or lts). The key is built into the program, so a release program cannot be pointed at another key. A release is never older than the one installed, and downgrades are never automatic.
• Nightly by default: every day from 03:00 for two hours in the server's time zone. You can instead be told and press Update now, take only patch releases by yourself, pause, or turn it off for air-gapped servers.
• Before it installs, the panel keeps the running release and a copy of its own database. Exactly one previous release is kept.
• If the new release does not come up healthy, it goes back by itself: the old files and the database copy are put back, and a notice says why. A release that failed is not tried again by itself.
• Go back on purpose from the Updates page. The plan says that changes made in the panel since the update are undone. Sites, mail, DNS and files are not touched.
• Only the panel and its agent stop, for about a minute or two. Websites, mail, DNS, databases and cron keep running. In our lab, a site requested twice a second through a whole update had no failed request, including through an update that had to go back.
• Everyone's open tabs show "The panel is being updated" and come back by themselves, still signed in.
• Every server follows, one at a time, with the agent kept for a way back. A server that fails stops the rollout and is reported. Store modules update in the same job when the policy says so.
• An update needs a licence that is active or in grace. A security release still reaches a licence up to 90 days past its term.
• The Updates page shows the version, the channel, the release notes, history, each server's version and the modules waiting.