Updating Dashmox

The release An archive and the signature made over its bytes.

Checked here Against a key built into the release you already run. The key is never fetched.

You press the button It snapshots first, and puts the old release back if the new one does not come up healthy.

The server's Updates section says which release you run and whether there is a newer one. A release is shown either as a newer release or as a release that fixes something, which is the distinction worth acting on: the second kind is a security release and should not wait for a convenient afternoon.

Alongside it are the date the release was Published and when this server Last checked. A server that has never asked says so plainly rather than implying it is up to date.

Every installation is offered every release, whatever plan it is on and whether it has a licence key at all. A server on the free plan is offered the same security release as a Business one, on the same day. Gating a security fix behind a payment would make the unpatched servers somebody else's problem as much as their owner's.

1. You press Install. Or a window you set does it for you, which is off until you turn it on.
2. The archive is checked against Dashmox's signature and refused if it does not match. An archive that arrived from anywhere else, or was altered on the way, does not install.
3. The panel snapshots its own state before it changes anything.
4. If the update fails, it tries to put the snapshot back rather than leaving a half-updated panel.

Websites keep serving throughout. Updating the panel is not the same as restarting what it hosts.

A switch in the same section installs a newer release by itself, in an hour you pick, in the server's own time. It is off on every server until somebody turns it on, and the panel records who did and when.

What runs in that window is the same ten steps as the button, with the same signature check, the same snapshot and the same rollback. Most windows install nothing, and the page says so: it shows what the last one did, which is how a window that is working can be told from one that stopped.

It is a decision for a person rather than for an integration, so an API token cannot turn it on.

The same section says what this server does about its own packages, which is a different question and one the panel used to be silent about. Ubuntu installs security updates by itself on a stock server and always has, so the first job here is to say what is already happening rather than to offer something new.

Three choices, and they are what apt can really deliver: nothing automatic, security updates only, or every update. Alongside is whether the server may restart itself when a package needs it, and at what hour. A policy somebody set at a shell is read and shown as theirs rather than claimed by the panel.

A new Ubuntu release is never installed for you. When one is offered the panel says so and leaves it: moving between Ubuntu releases is a decision with a backup behind it, and the login banner that offers it can be told to stop.

The same section names the database engine and its version. It matters for one practical reason: a dump written by MySQL 8 names a collation that MariaDB releases before 11.8 do not have, so a customer's database brought from another host fails to import on an older one until the file is edited. A server installed today gets 11.8 from MariaDB's own archive; a server installed on Ubuntu 24.04 before that has 10.11, which is supported and works.

Moving a running server between major versions is not a button, and that is deliberate: it cannot be undone, because MariaDB does not read a data directory back into an older release. What the panel does instead is write the sequence out for your server, with its own version, its own Ubuntu, its own dump path and how much space is free where the dump would go. You read it and run it.

Each step names itself as it starts, so a failure says which one. The order is the safety property: nothing is changed until the archive has been checked and the new release has been shown to run on this machine.

If any step fails, the snapshot from step 4 is put back and the panel is started again on the release it was already running. That rollback runs whether the step failed loudly or the script stopped on an unset value, which are different kinds of failure and used not to be treated the same.

Useful when the panel is the thing that is not working, or when you are updating several servers from a script. It takes the archive and the checksum you were given, and refuses anything that does not match both the checksum and the signature.

sudo dashmox update \
  --archive /tmp/dashmox-1.0.0-linux-amd64.tar.gz \
  --sha256 76bcef2f335c151de9acdc7a4ea9fbab...9c4900f

The signature file has to be beside the archive, with the same name and .sig on the end. Without it the server refuses the release and nothing installs. What you see is the ten steps, then:

DASHMOX-STEP 1/10 Checking the release archive
release signature verified
DASHMOX-STEP 2/10 Checking the new release runs on this machine
...
DASHMOX-STEP 10/10 Starting the panel and checking it answers
Updated to 1.0.0. Recovery snapshot:
  /var/backups/dashmox/pre-update-20261008T215113Z-881616

Afterwards, sudo dashmox doctor reads the whole health register from the machine itself, which is the quickest confirmation that the server is well rather than merely running.

Asking whether there is a newer release sends this installation's own identifier, the version it runs, and whether it is an amd64 or arm64 machine. That last one decides which archive you are offered, because a release is built for one kind of machine and the wrong one would download in full and then be refused.

No licence key is sent, deliberately: asking about a release needs no licence, which is what makes the previous section true. The panel's own Updates page lists these fields as well, and a build check keeps that list matching the code.

How the panel is put together, and why an update can be trusted at all, is on the security page.