Upgrade from 0.8.x to 1.0.0

Before the update

• Confirm that 1.0.0 and its signed update feed are published before expecting the updater to install it. Website publication alone does not release Portal.
• Finish deployment, tool installation, Mail and background host operations. Old installed versions do not participate in the new maintenance lease protocol, so the first upgrade needs a confirmed idle host.
• Keep a consistent state snapshot and /etc/dashboard-portal/dashboard-portal.env with the original HOSTMGR_SECRET_KEY. Do not copy only a live SQLite file while writers are active.
• Back up application data, databases, volumes, managed service configuration and certificates separately. Record your Portal Node major and active project revisions.

Apply the signed release

Run over SSH on the Ubuntu host. Check the offered version first. The updater verifies Ed25519 manifest signatures and archive SHA-256 and preserves the selected Portal Node major. Stop on verification failure; never disable signature checks.

sudo dashboard-portal update --check
sudo dashboard-portal update
sudo dashboard-portal update --check

Maintenance and recovery

In 1.0.0, participating host operations use shared maintenance leases while installation takes an exclusive lock before stopping services. Busy or unsafe leases reject the operation; let the current work finish and retry. Never delete, truncate or replace the lock file to force an update. HTTP 503, including Monitor usage writes, can indicate maintenance. The installer captures managed files and consistent state, and attempts recovery after failed changes, including Portal/helper service state. Packages and issued certificates are outside automatic rollback coverage. Inspect reported recovery failures over SSH.

After the update

sudo systemctl is-active dashboard-portal hostmgr-deploy-helper nginx
sudo nginx -t
curl -fsS http://127.0.0.1:3100/api/health
curl -fsS https://portal.example.com/api/health
curl -fsSI https://portal.example.com/

• Sign in and check account, update and Monitor Settings, organizations, grants and readable encrypted configuration.
• Check active revisions and runtime logs for existing Web projects. Existing project records default to Web.
• Use a test project for domainless Web and Worker deploy/rollback. Process stability is not proof of queue/job success.
• Retain the original state/key backup. Code-release rollback does not restore application databases or reverse external side effects. Plan host restore/reboot checks separately.