Can I upgrade from 0.14.1 to latest without using proxy?

Questions
1

Your question

I run a small server so I am not worried about a small amount of downtime. The plan was to create new Docker instance with latest version and use vandelay to migrate old data over. Also was wondering should I continue to use Rocks DB or use Postgre on the new version? Anybody done it this way or am I looking at a world of pain? Thoughts??

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

There’s a specific page about upgrading using stalwart-to-stalwart migration. Let me check it.

This gives good enough grounding. Let me check the migrate-accounts guide briefly for source-type compatibility (Stalwart-to-Stalwart JMAP source), and also check whether upgrading directly without proxy (just export/import via Vandelay, small downtime is fine) is a documented, supported path.

This confirms this exact scenario is well-supported. Now let me quickly check the RocksDB vs PostgreSQL recommendation more directly to answer the second part.

Now I have enough grounding to answer well.

Yes, that’s exactly the recommended approach. Since 0.14 is a “version 0.15 or below” source, an in-place upgrade isn’t practical (post-0.15 releases changed config, storage, and admin interfaces significantly), so the migration guide explicitly recommends running the old and new deployments side by side and moving data with a dedicated tool called Vandelay, optionally alongside a migration proxy for zero-downtime cutover. Given you’re fine with some downtime, you likely don’t even need the proxy: just spin up the new instance, migrate accounts with Vandelay, verify, then cut DNS/clients over.

Vandelay works by reading a source account (via JMAP, IMAP, CalDAV/CardDAV/WebDAV, ManageSieve, Maildir, etc.) into a local archive, then writing that archive to the new JMAP server. It’s convergent, so you can re-run it to catch up on new mail before final cutover, minimizing the downtime window.

On the database question: for a small single-node server, RocksDB remains the recommended backend and there’s no need to move to PostgreSQL unless you specifically want a relational/external DB for operational reasons (e.g. easier backups, multi-node clustering later, or external tooling). PostgreSQL is recommended mainly for organizations that need more scale or prefer not to run FoundationDB. If you do want to switch backends, Stalwart’s built-in import/export utility (separate from Vandelay, used for whole-database dumps) supports that, but for your case (old version → new version, same or different DB) Vandelay is the right tool since it operates at the JMAP/account level rather than raw storage.

Relevant docs:

  • Migration overview: /docs/migration/
  • Migration guide (step-by-step): /docs/migration/guide/
  • Storage backend guidance: /docs/cluster/deployment/storage
  • General upgrade notes: /docs/install/upgrade

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

What domain should I set for the target container? Is temp.mydomain.ca sufficient?

4

Yes, that works and it’s the intended route. 0.14.1 to 0.16 crosses the 0.15 boundary, so there’s no in-place upgrade anyway; you stand up a fresh current instance and move accounts over with Vandelay. The migration proxy only exists for zero-downtime cutover, and since you’re fine with brief downtime you can skip it entirely and just do the Vandelay import and export. Overview at Overview | Stalwart.

Since you’re building fresh, pick the final backend now rather than switching later: for a small single-node server I’d stay on RocksDB (the embedded default, simplest); go PostgreSQL only if you specifically want an external database (and note that true HA clustering is FoundationDB, not Postgres). One note though, configure the new instance with your real mail domain, not a temp. one, because account names on the new server are the full email addresses, so a temp domain would bake [email protected] into every account. The container’s own hostname is separate and can be whatever you like.