Ask AI about this page

Updating safely

Every new SubsiMail version is designed to be a drop-in replacement for the previous one — your existing database, campaigns, contacts, and connected accounts carry forward untouched. There is no "reinstall" path and none should ever be needed.

Upgrading to 8.0: just pull and restart, or replace the binary. Everything you have becomes the Default workspace and your license, users and opt-outs carry over. See What's new in 8.

Docker

docker compose pull
docker compose up -d

That's it. The named volume holding your database is untouched by the image update — only the application binary inside the container changes.

Linux binary / Windows .exe

  1. Stop the running process (systemctl stop subsimail on Linux, or close the window / stop the service on Windows)
  2. Replace the old binary with the new one, in the same folder
  3. Start it again — it opens the existing data/ folder in place

Database schema changes (if any) are applied automatically on startup via migrations built into the binary — you never run a separate migration step by hand.

Back up first

Still, treat your database like any production data: back it up before a major version jump, the same way you would before any software update. backup-db writes out a consistent snapshot (safe to run even while the server is up and taking traffic — it runs PostgreSQL's own pg_dump, bundled with SubsiMail, not a raw file copy) to wherever you point it, with the current date and time always appended to the filename so repeat backups never overwrite each other.

docker compose run --rm subsimail backup-db
./subsimail backup-db

With no destination given, it lands in data/backups/ — already inside your persisted Docker volume, so it survives a container recreate. Give it a path to save it somewhere else instead, e.g. backup-db /mnt/offsite/before-upgrade.dump. More in the FAQ.

Upgrading from version 5 (SQLite) to version 6 (PostgreSQL)

Version 6 stores everything in a built-in PostgreSQL database instead of a SQLite file. You don't have to do anything: the first time version 6 starts over an existing install, it copies every row from your old data/subsimail.db into the new database automatically. It is all-or-nothing — row counts are checked before it commits, and if anything is off it stops with a clear message rather than starting empty. Your original SQLite file is never modified and stays in place, so you always have it as a fallback. Expect the first start to take a little longer on a large database (a million rows takes about half a minute).

The upgrade guarantee

Every feature we ship is built so an existing install can upgrade with a plain docker pull + up (or binary swap) — never a reinstall, never a data-loss step. If a future release ever needs a manual action from you (rare), it'll be called out explicitly in that release's notes, not silently assumed.

Upgrading from 6.0.x to 7

Same two steps as above — nothing to export, nothing to reinstall. A few new database migrations run on first start. After upgrading, every contact gets a free background email check, and contacts that are certainly undeliverable are skipped by running campaigns (you can turn that off under Settings → Email verification). SubsiMail also begins storing the text of emails with people in your contacts for the new inbox. The full list is on What's new in 7.