Updating Asternodis

Asternodis updates in place with a single command, the same shape as the installer:

curl -fsSL https://asternodis.com/update.sh | sh

Run it on the host where Asternodis is installed. It re-runs itself with sudo if needed (root is required), so you can launch it as any user with sudo access.

What it does

1. Reads the installed version (asternodis version) and the latest published version.
2. If you’re already current, it prints Already up to date and exits, so it’s safe to run anytime (including from cron).
3. Downloads the matching static binary for your OS/architecture together with the release’s signed checksums, and verifies the Ed25519 signature on SHA256SUMS and the binary’s SHA-256 against it. A release that doesn’t verify is refused and your current install is left untouched.
4. Sanity-checks that the verified binary runs before touching the current install. On the latest channel it also refuses to replace your install with an older signed release (pin a version to roll back on purpose).
5. Replaces /usr/local/bin/asternodis and restarts the asternodis systemd service.

The check uses OpenSSL 3.0 or newer or, on a host whose OpenSSL can’t verify Ed25519, the installed asternodis itself (asternodis verify-release). A host with neither is told so and nothing is changed. Update from Settings → Software updates in the web UI instead, which verifies with the key built into Asternodis.

Your state under /var/lib/asternodis (the controller database, this site’s identity, and its keys) is never touched, so pairings, licenses, and protected guests carry straight across the update.

Port 443: since Asternodis 1.0.2 the web UI serves on port 443 (with a :80 → :443 redirect). Updating from an older :8443 install migrates the systemd service automatically the first time you run update.sh.

Pin a version or roll back

Pass the version as an argument to install (or downgrade to) a specific release instead of the latest. Version folders are immutable, so a pinned version always installs exactly that build.

A version can only be pinned once it has been published as its own channel, and today only latest is published. Any specific version fails with “No published release at …”, so there is no working pinning command to copy yet. The syntax below is shown for when there is one. Check what exists with:

curl -fsSL https://dl.asternodis.com/latest/VERSION

To roll back today, keep a copy of the binary you are running before you update. That copy is your rollback: stop the service, put it back at /usr/local/bin/asternodis, and start the service again.

Once a version is published as its own channel, it is pinned by passing it as an argument: sh -s -- vX.Y.Z for either script. The -s -- is the part worth remembering: writing ASTERNODIS_VERSION=vX.Y.Z curl … | sh looks equivalent but is not. In a shell pipeline the assignment applies to curl, and the sh on the right never sees it, so that form silently installs latest, the opposite of a rollback.

Environment overrides

These work when you run the script directly (sh ./update.sh) rather than through a pipe. Over a pipe, use the argument form above for the version.

If the script re-runs itself with sudo, it forwards these and the version argument explicitly, so a pinned version and any overrides survive a non-root run.

Verifying

After the service restarts, the running version appears in the web UI (sidebar footer) and from asternodis version on the CLI.