How updates work
PlusPanel OS (the operating system of every PlusPanel server) and the PlusPanel agent (the small program on each server that talks to the panel) are maintained by us. You never patch them yourself. This page explains how a new version travels from us to your servers, what protects your servers on the way, and what you see and control in the panel.
In short
Section titled “In short”- A new version first reaches a handful of servers, then more and more of them, in rings.
- Each server is checked after its update: it reconnects, its sites answer, nothing crashes, it has memory and disk to spare. One failed check on one server stops the whole rollout.
- A server whose checks fail is rolled back automatically to the version it ran before, and the panel shows you why.
- Updates happen inside your maintenance window, and your clients are told beforehand.
- Urgent security fixes use the same rings and the same checks, only with shorter waiting times.
Channels
Section titled “Channels”Every server follows one of two channels:
| Channel | For | What it receives |
|---|---|---|
| Stable · Production (default) | customer-facing servers | a version only after it has run on Preview servers and passed a full rollout |
| Preview · Early Access | test and staging servers, early adopters | every new version first, after our own test gates |
You set a default channel for your organization in Settings → Maintenance & updates; servers follow it unless you give an individual server its own channel on its Updates page. Changing a channel is a signed command to the server and is recorded in the audit log. A server that changes channel during a rollout simply leaves that rollout and follows its new channel from then on.
New installations always start from the version Stable servers already run: the public Stable channel moves only after a Stable rollout has completed on the fleet.
Rollout rings
Section titled “Rollout rings”A new version is never installed everywhere at once. It moves through five rings:
| Ring | Which servers | Waiting time before the next ring |
|---|---|---|
| 0 · Internal | our own servers | 30 minutes |
| 1 · Canary | 2 % of the servers (at least one) | 30 minutes |
| 2 · Wave | up to 10 % | 2 hours |
| 3 · Wave | up to 50 % | 2 hours |
| 4 · Wave | all remaining servers | 2 hours |
The next ring starts only when every server of the current ring has updated successfully and its checks have stayed green for the whole waiting time. Which servers are canaries is decided by a fixed formula from the release itself, so it is reproducible and not hand-picked. At most 20 servers of a ring update at the same time. Our operators follow every rollout live in the panel and can pause, resume or cancel it.
Health checks after every update
Section titled “Health checks after every update”After a server updates, the panel watches it. All of these must stay green:
- Reconnect: the server comes back on the new version within 15 minutes (agent updates: within the trial time).
- Online: it keeps talking to the panel during the waiting time (offline more than 3 minutes counts as a failure).
- Sites: every site that worked before the update works again (the panel checks the home page and, for WordPress, the login page). A grace period of 3 minutes covers normal restarts.
- No crashes: the agent did not stop unexpectedly.
- Resources: at least 5 % of memory is free and no disk is more than 95 % full (or no worse than before the update).
- Jobs: no operation on the server failed since the update started.
- Verification: the update was signed by PlusPanel and carried its signed software bill of materials; a server refuses anything else before installing it.
A check that cannot be evaluated yet is treated as “not yet green”, never as passed.
Automatic rollback
Section titled “Automatic rollback”If any check fails on a server:
- that server is rolled back to the version it ran before (for the operating system: the previous image, kept on disk for exactly this; for the agent: the previous binary), and the rollback is checked the same way (it reconnects, its sites work);
- the whole rollout stops: no other server receives the version until we have found and fixed the cause;
- we are alerted.
On the server’s Updates page you see the reason first, in plain terms, for example
gate:sites: site a1b2c3d4e5f6 broken 3m10s: health: GET / 503, together with the update history of that
server. For a server converted from AlmaLinux or Rocky Linux, the same page shows the outcome of the
conversion and, if it went back to its previous system, why. Servers that had already updated successfully
keep the new version; the next fixed version covers them.
Maintenance windows and client notification
Section titled “Maintenance windows and client notification”- You can define a maintenance window for your organization (Settings → Maintenance & updates) and, if a server needs a different one, on that server’s Updates page: the weekdays, a start time, a duration (15 minutes to 24 hours) and the time zone. Windows may cross midnight; daylight saving time is handled. Without a window, updates may happen at any time.
- A server is updated only inside its window.
- Your clients are told before their server is updated: at least 24 hours in advance for regular releases (1 hour for express security releases). The notice goes to your organization’s notification channels and, by e-mail, to the users of every account on that server. Your clients also see a banner in their panel while an update of their server is scheduled (“your server enters maintenance at …”, in their own time) or in progress, and an update history for their server.
- An operating system update restarts the server (a few minutes of downtime); an agent update does not (see below).
Express security updates
Section titled “Express security updates”When a fix for a critical or high vulnerability is available, we build an express release. Express releases go through exactly the same rings and the same health checks; no check is ever skipped. Only the timings are shorter:
| Regular | Express | |
|---|---|---|
| Waiting time, internal and canary rings | 30 minutes | 10 minutes |
| Waiting time, waves | 2 hours | 30 minutes |
| Client notice before the update | 24 hours | 1 hour |
Maintenance windows still apply.
Agent updates without a reboot
Section titled “Agent updates without a reboot”The agent is updated separately from the operating system, and without restarting the server:
- the server downloads the new agent and checks its signature and software bill of materials;
- it installs it next to the current one and restarts only the agent (a few seconds; your sites keep running);
- the new agent is on trial until it has reached the panel. If it crashes repeatedly, cannot connect, or hangs, the server switches back to the previous agent by itself, within minutes;
- once connected, the trial ends and the new version is kept.
Servers in Compatibility mode (AlmaLinux / Rocky Linux with only the agent installed) receive agent updates the same way; they do not receive operating system updates. A later operating system update that already contains a newer agent replaces the separately installed one automatically.
Cleanup after 7 days
Section titled “Cleanup after 7 days”After an operating system update has run with all checks green for 7 days, the server removes older
system images it no longer needs, to free disk space. It always keeps the previous version, so a rollback
stays possible. On servers that were converted from AlmaLinux / Rocky Linux, the files of the old operating
system are removed at the same time (data in /home, /root, /opt and /srv is kept and reported).
Questions
Section titled “Questions”Write to ops@pluspanel.net.