# Update SixPanel itself > Source: https://www.allsweb.com/sixpanel/docs/update-sixpanel > Markdown for agents: https://www.allsweb.com/sixpanel/docs/update-sixpanel.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **Updating SixPanel is not the same as updating your 6ammart code.** They are two separate things, they use two different commands, and mixing them up is the most common mistake on this page. | What you want newer | Where in the panel | Over SSH | |---|---|---| | **Your 6ammart code** (your app, your theme, your fixes) | **Deploys** → update | `sudo sixpanel deploy` | | **SixPanel itself** (this panel, the CLI, the serving configuration) | **Settings** → panel updates | `sudo sixpanel server update` | | **The server itself** (Ubuntu and its security fixes) | **Settings** → **Server security updates** | `sudo sixpanel server os-update` | This page is about the second one. For the first, see [Deploy and update your code](https://www.allsweb.com/sixpanel/docs/deploy-update). For the third, see [Server updates and restarts](https://www.allsweb.com/sixpanel/docs/server-updates). **You need** - Root SSH access, or the panel open on the **Settings** page. - The server able to reach the internet over HTTPS. An update is downloaded from the same signed release channel your installer used. There is no offline update path. - A recent backup. Take one now if you are unsure: ``` sudo sixpanel backup run full ``` ## 1. Which build am I on? The version is printed under the product name in the panel's sidebar, on every page — so you never have to hunt for it. A chip next to it appears when there is something to act on, and it links to the button. Over SSH: ``` sudo sixpanel version ``` It prints the CLI version, the SixPanel version, the panel version, and the Node, nginx, PHP, MariaDB, kernel and OS versions. It also tells you when those numbers **disagree with each other** — for example when the panel has been updated but the `sixpanel` command on the server is still the older one. That matters, because the command line is what you reach for when the panel will not let you in. Re-running the update settles it. On older servers the CLI line could not be trusted: it reported the version of the folder it was pointed at rather than its own, so a command line several releases behind still printed the current number, and updates from the panel never replaced it on a server installed from the published link. Both are fixed. If your server has taken an update from the panel since then, the number is the command line's own. ## 2. Update from the panel 1. Open **Settings** (in the **Panel** menu group). 2. Find the panel-updates card. It shows the version this server runs, and one of these answers: - **This is the newest published version.** — nothing to do. - **A newer version has been published** — with a link to what changed. - **Installed but not running yet** — a previous update landed on disk and the panel has not restarted. It finishes when the panel restarts, and the card says so. - **Could not be checked** — treat that as unknown rather than up to date. Nothing was changed and your project is running normally. 3. Read what changed, then press the install button and confirm. Watch the log. The last step restarts the panel itself, so the page disconnects. Reload it after about ten to twenty seconds. **Most updates leave your project open the whole time.** If an update also rebuilds the customer website, that website is unreachable for a few seconds while it restarts — visitors see an error, not a slow page — so prefer a quiet hour. ## 3. Update over SSH Look first, change nothing: ``` sudo sixpanel server update --check ``` Then apply it: ``` sudo sixpanel server update ``` It tells you what changes, what restarts and how to undo, then asks. The old name `sudo sixpanel update` still works and still means this — it prints a note saying so. ## 4. What actually happens 1. The signed release record is fetched and its **signature is checked** against a key that was pinned onto this server when you installed it. If the signature does not match, nothing is changed and the update stops. A build older than the one you run is refused too, and so is a release record that has gone stale. 2. The small installer script that does the work is downloaded and **checked against the fingerprint inside that signed record** before it is run. If the two disagree, both fingerprints are printed and nothing runs. The key on your server is also what the installer verifies the release against — it is never replaced by whatever key the installer happens to carry, only by a new key that arrives signed by the one being replaced. 3. The new release is downloaded and its contents checked against the size and fingerprint in the same signed record. 4. The new code is laid over the SixPanel folder. Files it does not carry — your settings, your data, your certificates, your application code — are not touched. 5. **The Node.js version is matched to what this release needs.** See below. 6. **Everything the release ships is applied**, not merely copied: the web server and PHP settings, the database tuning, the pool your site's PHP runs in, the systemd units, the alerting, the server's own sizing numbers, and the `sixpanel` command line. This is the step that makes an updated server and a freshly installed one the same server. Configuration that a service has to parse is checked *before* that service is asked to use it, and put back if it does not parse, so a bad file can never take your site down. 7. The panel's own dependencies are re-installed from the release's lock file. 8. Any migration the release ships is run. 9. The services that are **running** are rolled onto the new configuration, in two ordered groups: everything a visitor's request passes through moves together, then the background workers. PHP is **reloaded**, never restarted, so no request is dropped. Services you had stopped stay stopped. 10. The panel restarts last. **Two things an update deliberately does not do.** It never upgrades a package your server already has — only one this release newly needs and your server is missing — so an update cannot restart your web server or database for a reason the release did not ask for. And it never touches your database passwords. Your site is up throughout, apart from short pauses as each service comes back. Expect the panel itself to be away for about ten to twenty seconds at the end. **Never touched by an update:** your settings file, your data (database, uploads, certificates, local backups) and your application code. ### About that Node.js step The panel ships as compiled bytecode rather than readable source. Bytecode is accepted by **only the exact Node.js version that produced it** — not "22 or newer", the exact one. Every release records the version it was built against, and step 3 above installs that version if the server is on a different one. Two things follow from that, and they are worth knowing: - **Do not change the server's Node.js by hand.** Not with `apt install nodejs`, not with `nvm`, not by adding another package source. A box that drifts off the pinned version has a panel that will not start, and the panel is where you would normally fix it. If it has already happened, the repair is one command on the server: ``` sudo bash /opt/sixpanel/installer/install.sh --node-only ``` That installs exactly the version the installed release names, and nothing else. - **Node.js on this server belongs to SixPanel.** Your 6ammart code runs on PHP; the only things using Node here are the panel itself and the customer website build. If you need a different Node for something of your own, run it somewhere else. ## 5. When the panel says it cannot do it Two honest refusals you may meet: - *the jump is too big for the in-place path*; - *this server has no pinned release key* — the file that proves which releases to trust is missing. Both have the same answer: fetch the installer again and run it. It is the same one line as the first install, and a re-run over an existing server **is** the supported update path: ``` curl -fsSL https://installer.allsweb.net/sixpanel-native/install.sh -o install.sh sudo bash install.sh --update ``` That does the full upgrade path and re-pins the release key. Your settings, data and code are not touched. ## How to check it worked - The version under the product name in the sidebar is the new one. - **Settings** says this is the newest published version. - `sudo sixpanel version` shows the same number for the CLI, SixPanel and the panel — no disagreement warning. - `sudo sixpanel doctor` is green. - Your site opens as normal. ## If it went wrong - **The download did not match its hash** — that is almost always an interrupted download. Run the update again. - **The update stopped in the middle** — the verified code is already on disk, so it is safe to run again. Then run `sudo sixpanel doctor`. - **The panel did not come back after the update** — give it a minute, then check it from SSH: ``` sudo sixpanel service status panel sudo sixpanel logs panel -n 50 ``` If the log mentions the panel's own code failing to load, the Node.js version is the first thing to check: `sudo bash /opt/sixpanel/installer/install.sh --node-only`. - **A service did not come back** — start it and read its log: ``` sudo sixpanel service start all sudo sixpanel logs all -n 50 ``` - **`sixpanel version` says the CLI is older than the panel** — run `sudo sixpanel server update` once more. The rescue commands live in the CLI, so a stale one is worth settling straight away. - **You want to go back** — there is no "undo update" button. The way back is a backup taken before it. A restore cannot be undone: it writes that snapshot over your live database and files, and everything created since it was taken is lost. Take a fresh backup first, then `sudo sixpanel backup list` and `sudo sixpanel backup restore SNAPSHOT_ID`. See [Backups](https://www.allsweb.com/sixpanel/docs/backups). - **The signature check failed** — do not retry in a loop and do not work around it. Send us the file from `sudo sixpanel support-bundle` and wait for an answer.