System Updates

Panelica updates itself and every service it manages, nginx, Apache, the PHP versions, PostgreSQL, MySQL, Redis, BIND, the mail stack, the panel backend and frontend, from a central catalog, with each update backed up and health-checked so a bad one rolls back automatically. This page explains the update screen, the two channels, and why an update is safe to run on a live server.

The screen

The page has two tabs, Service Updates (the main screen) and Auto-Updates (per-service automatic-update status). The main tab lists every installed service grouped by category, Web, Database, Runtime, Email, FTP, DNS, Web Apps and Panel, each row showing the installed version and, if one is available, the new version with an Update button. Four cards summarize the fleet: total services, up-to-date, updates available, and categories. Categories with a pending update open expanded by default.

Every service row also offers Reinstall (re-apply the current version, useful to repair a service) and, where a previous version was backed up, Rollback (with the backup's expiry date shown).

Updating

You can update one service at a time or all at once.

• Single update: click Update on a row. A dialog shows the current and new version, the download size, a security badge, the changelog and any breaking-changes warning, then applies it with a progress bar.
• Update All: one click runs every available update in sequence. It is a real sequencer, it applies each package, stops immediately if one fails (the failed package is already rolled back, the rest are skipped), and always does the panel backend last, because updating the backend restarts it.

Stable and beta channels

Updates come on two channels, set on the System Updates settings tab:

• Stable, released versions only, the default.
• Beta, released plus testing versions, for trying updates early.

The channel is stored server-side (in the panel database), not just in your browser, so it survives a browser reset or a move to another machine, and changing it takes effect immediately.

Dependency gating

Some updates require a newer panel backend first (for example, a database engine upgrade that needs the backend's new upgrade logic). Panelica enforces this with a minimum-panel-version gate on the offending package: an older backend simply doesn't see that update until it has updated the panel itself. So the order is enforced technically, not left to you to remember, update the panel, and the dependent update appears on the next check.

Why an update is safe on a live server

Every update runs through Panelica's hardened apply path, which is built to survive a crash, a power loss or a bad package without leaving the server broken. For each update it:

• Verifies the download against a SHA-256 checksum before touching anything.
• Backs up first, the current files, the relevant configs, and, for a panel-backend update, a snapshot of the panel database (because the new backend will run migrations). If the snapshot can't be taken, the update aborts while the old, working version is still running.
• Writes a journal of each step, so if the process is interrupted, the next boot knows exactly where it was and finishes or reverses it.
• Extracts atomically (a rename, never a half-written binary) and re-checks the files.
• Health-checks after restart, and if the service doesn't come back healthy, it rolls back to the backup automatically. For the panel backend, the new version is only marked "successful" once it has actually started and run its migrations, so a bricked update can never masquerade as a good one.
• Handles database engines specially, a MySQL or PostgreSQL major upgrade has extra pre-checks and its own rollback strategy, because those can't be undone as casually as a file swap.

Auto-Updates

The Auto-Updates tab shows each service's automatic-update status, its last result (success, failed or rolled back), current version and last check. The global automatic-update settings, whether auto-updates run at all and the maintenance window they run in, live on the Panel Settings → System Updates tab; this tab links you there. You can also trigger a per-service Check Now or Update Now from here.

Access

System Updates is available to ROOT and ADMIN (other roles can't reach it). It is not behind a license feature, keeping the platform patched is core. Everything you do here goes through the same audited, checksum-verified, auto-rollback apply path described above.