Frequently asked questions

Can I lose access to my instance if my license lapses?

No — your data is never held hostage. A lapsed or unreachable license pauses new sending and reply-checking (see License & activation issues), but you can still log in, view everything, and export data. There's also a grace period before a temporary connectivity issue affects anything at all.

Are my connected accounts' credentials stored securely?

Yes. Connected-account OAuth tokens and SMTP/IMAP passwords are encrypted at rest (AES-256-GCM) before they ever touch the database — the same approach tools like n8n use for stored credentials. The encryption key itself lives outside the database: either an env var you set (SUBSIMAIL_ENCRYPTION_KEY), or a key file generated once alongside your data directory if you don't set one. Either way, a copied or leaked database file alone isn't enough to recover any credential from it. Your own login password was already one-way hashed (Argon2) and was never affected by this.

Can I try SubsiMail locally before pointing it at a real domain?

Yes — localhost/127.0.0.1 is treated as a wildcard for license domain binding: any port works, and you won't need to reconnect or re-activate if the port changes between runs (a real domain still binds to that exact domain, as normal). This is meant for exactly this case: evaluating the product, or running it locally during development, before you're ready to bind a license to your real domain.

Can one campaign use multiple sending accounts?

No, a campaign sends from exactly one connected account. To split volume across multiple inboxes, create separate campaigns, each on its own account, enrolling different lists (or the same list split into smaller ones).

Can I edit a step after contacts are already enrolled?

Yes — editing a step's subject or body applies to anyone who hasn't reached that step yet. Contacts who already received it keep what they were sent (their thread doesn't retroactively change).

Can I move my install to a new server?

Yes. Stop SubsiMail, then copy the whole data/ folder (the database, your uploads, and the encryption.key file that protects your connected-account credentials) to the new server, install the same SubsiMail version there the same way, and start it from the folder that contains the copied data/. Use the same CPU type on both servers (x86_64 to x86_64, or ARM to ARM); moving between different CPU types needs a fresh backup-db dump instead — contact support and we'll walk you through it. If the domain changes too, update it on your account's License section and re-activate with a freshly signed token.

Does SubsiMail back up my data?

Not automatically on a schedule, but a one-off backup is a single command: backup-db writes out a consistent snapshot of the database (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; the result is a .dump file that can be restored with pg_restore) 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

On a Linux binary / Windows .exe install, run it from the same folder (no need to stop the server first — unlike a password reset, a backup doesn't touch anything):

./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/ (a directory) or backup-db /mnt/offsite/before-upgrade.dump (a specific name — the timestamp still gets inserted before the extension). Copy the resulting file to storage you actually control (another disk, S3, wherever) the same way you would for any self-hosted app's data.

I lost the super admin password — what now?

There's no in-app reset for the super admin specifically, since nothing outranks that role to approve one (see why super admin is special). Recovery is a command run directly on the server hosting your instance, not a self-service web flow — the same pattern used by tools like Django, Nextcloud, and Ghost for their own top-level admin recovery.

Run reset-super-admin with the new password against the same instance:

docker compose run --rm subsimail reset-super-admin 'your-new-password'

On a Linux binary / Windows .exe install, stop the running process first, then run it from the same folder:

./subsimail reset-super-admin 'your-new-password'

It sets the new password, re-enables the account if it was disabled, and signs out every existing session for it. Then log in with the super admin's email and the password you just set.

Where do I ask a question or report a bug?

The Support forum — open to anyone to read and search (no login needed), and free to post a new ticket once you're logged in with your subsimail.com account. It doubles as a searchable archive, so it's worth checking before you post in case someone's already hit the same thing. One thing worth knowing going in: it's public, so don't include passwords, license tokens, or other sensitive details in a ticket.