Run it · 8 of 11
Updating
Moving inbuxa to a newer release: with inbuxa upgrade, which archives the data and puts back anything that fails its check, or by hand, one program at a time.
On this page
From 27.1 the server, the console and the webmail share one version number, and a series is made to work together (Versions and upgrades). On the 2026 line each had its own, so check what you are moving between rather than assuming the three move together.
With the installer
Each installer release installs particular releases of the server, the console and the webmail, so a newer installer is what brings newer ones. Download it as for an install, then:
sudo inbuxa upgrade --dry-run # each component: what it is now, what it would become
sudo inbuxa upgrade # do it
inbuxa status shows the same versions. inbuxa upgrade server (or
console, or webmail) moves just that one.
The server goes first, then the console, then the webmail. Each is checked
once it is running again, and if the check fails it is put back as it was
and the upgrade stops there. The server is stopped first and its data
archived into /var/lib/inbuxa/backups, because a new release may convert
its store on first start and that can't be undone. --no-backup skips the
archive; a store kept elsewhere, such as PostgreSQL or S3, has to be backed up
where it lives either way. A server on the host keeps its previous binary
beside the new one, as /usr/local/bin/inbuxa-server.<version>.
By hand
Without the installer, pull the new image, restart that one program, and check it before touching the next.
Back up before an update that crosses a store format
Data-format upgrades are one-way. The server's --version names the
upstream release it is built on, and a release that changes that base may
convert your store on first start. Take a snapshot you have actually
checked before starting one — for the container install, that is the
/etc/inbuxa and /var/lib/inbuxa volumes.