Updates

Release channels

The OPanel package ships from a signed APT repository with three channels:

Channel	For
stable	Production servers. Receives releases after they’ve been through beta.
beta	Servers that want the next release early.
nightly	Test servers only — development builds.

Set the channel at install time (opanel install --channel beta) or later (opanel install --channel beta again, then apt-get install opanel). Every server in a cluster should follow the same channel — a rollout installs one version everywhere.

Unattended security updates

Debian security updates and PHP updates install themselves daily, unattended. After a PHP update, each site’s PHP-FPM master moves onto the new binary at the node’s next drift check — no manual step required. The OPanel package itself is never upgraded unattended; that’s a deliberate, operator-triggered rollout (below), so you control exactly when a cluster moves to a new version.

Rolling out an OPanel upgrade

Start a rollout from the console or the API:

curl -X POST https://panel.example.com/api/v1/platform/updates/rollouts \
  -H "Authorization: Bearer $TOKEN" -d '{"version":"1.3.0"}'

Omit version to roll out the newest release your channel offers. The controller upgrades control servers first, then edges, then everything else, one server at a time. On each server:

1. It must be online, in sync, and not in the middle of a site move.
2. The agent refreshes package lists and installs the new version; the edge and SSH gateway reload without dropping a connection, the controller and agent restart.
3. The server must then pass a health gate — online, in sync, running the target version, every component that ran before still running, no new problems, and (for web servers) a sample of its sites still answering through the edge — held for 30 seconds before the rollout moves on.

A server that fails its upgrade or its health gate halts the rollout there, leaving the rest of the cluster on the previous version, with the reason surfaced in the console.

Task	Request
Follow a rollout	GET /api/v1/platform/updates/rollouts/{id}
Pause (current server finishes, no other starts)	POST /api/v1/platform/updates/rollouts/{id}/pause
Resume a paused or halted rollout	POST /api/v1/platform/updates/rollouts/{id}/resume
Abort (no further server is upgraded)	POST /api/v1/platform/updates/rollouts/{id}/abort

Roll out versions one minor release at a time — a release only works alongside the previous minor version during a mixed-version rollout, and going back more than one minor version isn’t supported because of database migrations.

Rebooting

Nothing reboots itself. When an update needs a reboot (typically a new kernel), opanel doctor warns and names the packages, and GET /api/v1/platform/updates lists the server under rebootRequired. In a cluster, drain the server first so its sites move off cleanly, reboot it, check it with opanel doctor, then uncordon it:

# on a controller, or via the API
POST /api/v1/nodes/{id}/drain
# on the server itself
reboot
# once it's back
opanel doctor
POST /api/v1/nodes/{id}/uncordon

Checking a server’s version

apt-cache policy opanel                  # installed version and what the channel offers
apt-get install opanel=1.2.3             # go back to a specific version
apt-mark hold opanel                     # keep a server on its version; rollouts skip it

opanel doctor verifies the repository and its signing key are correctly configured and that unattended upgrades are enabled.