Upgrading

One-click updates

Since 1.3 a server can update itself from a signed release feed:

• The admin UI (port 2087) shows the installed and the latest version on the dashboard and on Updates; one confirmation click installs the new release. panelctl update check / panelctl update apply do the same from the shell, and panelctl doctor warns when a newer release exists. Servers check the feed once a day; nothing is ever installed without an admin asking.
• The feed is a directory URL holding latest.json, latest.json.sig and the tarballs, set as [update] url in /etc/minipanel/config.toml (or install.sh --update-url); fresh installs use the public feed https://panelowl.com/releases/. The installer already writes an [update] section; edit its url line rather than adding a second [update] section — a duplicate section makes the file invalid and minipaneld refuses to start (journalctl -u minipaneld says so). Every manifest is signed with the publisher's Ed25519 key, whose public half is built into the binaries (public_key in [update] overrides it for self-built releases); the tarball's SHA-256 is part of the signed manifest. A release that does not verify is never unpacked, let alone run.
• Under the hood the helper downloads and verifies the release into /var/lib/minipanel/updates/, then runs its install.sh --yes as the transient unit minipanel-update — the same upgrade path as below — while the page polls the status and shows the installer log.

Publishing a release (on the build machine): make release signs dist/latest.json when ~/.minipanel/release.key exists (create it once with go run ./cmd/minipanel-release keygen --out ~/.minipanel/release.key), and docs/guide/publish.sh uploads the tarball, manifest, signature and the docs site to panelowl.com over SFTP (make docs-deploy keeps a copy on the LAN docs server). Keep the private key off the servers.

Upgrading by hand

Upgrades are the installer re-run from a newer release. Nothing else is needed.

tar xzf minipanel-v1.1.0.tar.gz
cd minipanel-v1.1.0
./install/install.sh

On an existing installation the installer:

• reads the current settings from /etc/minipanel/config.toml (hostname, email, PHP versions) and only asks for confirmation;
• prints Upgrading v1.0.0-rc1 -> v1.1.0 (or Re-applying when the version is unchanged), replaces the binaries atomically and updates the version marker /usr/local/lib/minipanel/VERSION;
• restarts minipaneld, which runs any new database migrations on start;
• runs panelctl rebuild, re-rendering every managed configuration file for every account from the state database (with each service's own configuration checker before anything is swapped in);
• restarts the services and finishes with a health summary.

Client sites stay up during the upgrade apart from the reloads; existing sessions in the panel survive.

Check afterwards:

panelctl version
panelctl doctor

Version numbers

Releases are numbered MAJOR.MINOR.PATCH (for example 1.1.0); panelctl version, the installer's messages, the panel footer and the tarball name all show the same number. A build made from uncommitted source shows a -dev suffix (1.1.0-dev) and should not be installed on a production server.

Notes

• Operating-system updates are yours. panelOwl enables unattended security upgrades but does not run apt upgrade for you. Reboot for kernel updates as usual.
• Adding a PHP version does not need a release: panelctl php install 8.4.
• Rolling back is re-running an older release's installer. Database migrations are forward-only, so only roll back to a release with the same schema version (panelctl ping prints it).
• The installer never touches client data (/home/<account>), MariaDB databases or mail.