Skip to content

Coming from Stalwart

INBUXA is a fork of Stalwart and keeps its data format unchanged. That is the whole reason this is a copy rather than a conversion, and it is what the promise below rests on.

The migration tool is not built yet

inbuxa migrate is specified and still to be written. The migration is a procedure you run yourself today, and the phases below are the steps of it — INBUXA's own service moved this way on 20 September 2026, by hand, in a 78-second window. What that run took is what the tool will automate. Read the whole page before you start any of it.

What comes across

Everything that defines the server lives in its data store, so copying the store carries all of it:

  • accounts and their passwords, and app passwords
  • OAuth clients and live sessions
  • aliases and mailing lists
  • tenants, domains, and the DNS provider settings
  • certificates and ACME state
  • Sieve scripts
  • the queue, and the mail itself

Nothing is re-entered and nothing is re-issued. Nobody is asked to change a password, re-authorize a client, or re-point a DNS record.

One migration at a time, and not across an upgrade

A migration that would also cross a Stalwart version is that upgrade first, then this. Do them separately, and check the server works in between.

The shape of it

Side by side. The existing install is stopped but left standing, INBUXA goes in at its own path with a copy of the data, and the old install is what a rollback returns to.

You read the source and write only to the new install. The source's store is copied, never moved, and never opened for writing:

rsync -aH --delete /opt/stalwart/data/ /var/lib/inbuxa/

rsync -a preserves ownership

The copy arrives owned by the source's user. Change it to the user the fork runs as before starting the server, or it will fail to open its own store.

The phases, and which ones cost you

  1. Preflight, with nothing stopped: the source's version and store backend, disk for a second copy, the target path, the ports, the front ends' plan, and a snapshot you confirm exists. Anything wrong here costs no downtime at all, which is why it is a separate step you run on its own. Read the existing unit (systemctl cat) before touching anything — our own run found a network namespace that nothing in the plan knew about, and it would have cost outbound mail with no local symptom.
  2. Stop the mail server, then the webmail. The unit is disabled as well as stopped, so a reboot cannot put two servers on one set of ports with two diverging stores.
  3. Copy the store to the new path.
  4. Configure the fork and its unit, pointing at the copy.
  5. Start it, and wait for it to answer.
  6. Front ends: INBUXA Admin and the webmail, against the same store's OAuth clients.
  7. Verify. This is a gate, not a formality.
  8. Report.

Downtime is phases 2 to 7. Preflight and the copy dominate the total, and nobody experiences those, so the total is not the number worth quoting. The report gives both, per phase, and writes them as JSON beside the readable summary.

Verification, before mail flows again

Work down this list yourself. It is the list the tool will check once it exists, and until then it is the gate:

  • it answers on every listener the source had, with the certificate the source was serving;
  • an account signs in over IMAP, JMAP and both front ends, with the credential it already had;
  • a message arrives from outside, and one leaves;
  • aliases still receive;
  • a tenant administrator sees its own accounts and domains, and no others;
  • the queue drains, and the task queue gains no permanent failures;
  • nothing but INBUXA is listening on those ports.

A failed check is a failed migration. Roll back rather than leaving yourself a half-migrated server to reason about at 2am — that is what keeping the old install standing is for, and why it is stopped but not removed.

Rolling back

Because the source was never written to, a rollback is starting the old install again. That is the point of leaving it standing, and it is why this is a different operation from an in-place upgrade tool, which cannot undo one.

Keep the old install until you have watched real mail flow through the new one for longer than you think you need to.

Afterwards

A migration that passes its own verification has proved the server works. Pointing a stock, unmodified ihasmail at the migrated server proves something else: that a client which knows nothing about INBUXA still gets a working mailbox, which is what keeps the protocol surface honest.