Panel update
Update OSS Panel itself — five preflight checks, a dry run, fourteen steps, and a rollback if the last of them fails.
Admin Panel → Panel Update updates the panel software. Not the operating system — that is Settings → Updates & restart — and not your applications. Just OSS Panel.
The subtitle is the promise worth repeating to anyone nervous about pressing it: hosted applications stay online; only this panel restarts.
Up to date
When there is nothing to install, the page is one card: the installed version, the commit it was built from, and the branch. Check again asks the release server once more.
The version is also on the Admin Dashboard tile, which caches its answer — so immediately after an update the tile can lag this page by a few minutes.
If the release server cannot be reached, the panel is explicit that this is not your problem: "The release server was unreachable. Your panel is fine — try again in a bit."
When an update is available
The card gains the new version, its publication date, what is new, a link to the full release notes, and a Before updating list.
The five preflight checks
| Check | Passes when | Blocking? |
|---|---|---|
| Installed from a git checkout | The installation directory is a git repository | Yes |
| No uncommitted local changes | Nothing in the checkout has been edited by hand | Yes |
| Enough free disk space | At least 2 GB free where the panel lives | Yes |
| Installation directory is writable | The panel can write to its own directory | Yes |
| Enough free memory | Memory is comfortable for the build step | No — advisory |
Four of the five block the update. Enough free memory is advisory: it is shown, it may be red, and the Update now button still works — a build on a small server is slow, not impossible.
Edited a file on the server?
No uncommitted local changes is the check that stops most people, and it stops them on purpose: the update does a forced checkout, which would throw your edits away without asking. The check names the files that are in the way — up to five of them, then "and N more" — so you can see what you changed. It also fails closed: if the panel cannot prove the checkout is clean, it refuses rather than guessing.
Updating
Run a dry run first, if you want one. The Dry run button walks every step without changing anything, and reports exactly what a real update would do. The hint on the button says it: "Not sure? Run a dry run first."
Press Update now and confirm. The dialog is honest about the cost: "The panel goes offline for a few minutes while it updates, then restarts. Hosted applications are unaffected."
Watch, or don't. A progress bar reports "Step 7 of 14" with the step's name. The page says outright that you can leave: "You can safely leave this page — the update keeps running on the server." Coming back resumes the display.
Reload when it finishes. The panel restarts, the page notices and reconnects, and offers Reload panel with a countdown. The browser is still holding the old interface until you do.
The fourteen steps
In order: preflight · back up the database · create the release directory · link shared files · install PHP dependencies · build the frontend · sync privileges · maintenance mode on · migrate · swap · restart services · verify · maintenance mode off · prune.
The design point is where the line falls. Everything through "build the frontend" is undoable by deleting a directory — nothing live has changed yet. The steps that touch the running installation come after it, and are the short tail of the list.
The panel's own database is backed up by the update, not by you
Step two takes a copy of the panel's database before anything else happens. This is separate from your application backups — the panel's own database is never written to your storage destinations, and this copy is the only one of it that exists.
If it fails
The panel reports one of three outcomes, and they mean different things:
- "The previous version was restored, so the panel is still working." — the failure happened at a step that could be rolled back. Nothing to do but read the reference and try again.
- "Nothing was changed; this panel already contains that release." — not a failure at all.
- "The panel may be in an inconsistent state — check the server." — the failure happened past the point of no return. This is the one that needs an SSH session.
Every failure carries a reference and the captured output, so there is something concrete to attach to a bug report.
Limits worth knowing
- Only administrators see this page, and only Admin Panel access grants it — no role in the catalog includes it.
- The panel must have been installed from a git checkout. An installation that is not a repository fails the first preflight check and cannot be updated from the interface at all.
- There is no downgrade. The page installs the release the server offers; it does not let you pick a version.
- The checked-for version is cached on the dashboard tile but not on this page — Check again here is always a live request.