What the initial installation stores locally

The lightweight deployment uses RocksDB and local Docker volumes.

Important volumes:

stalwart_config
stalwart_data

These contain:

Domains
Accounts
Aliases
Mailbox metadata
Mail folders
Raw messages
Attachments
Calendars
Contacts
Server configuration
Search indexes
DKIM material
Other mail state

If the VPS is lost and these volumes are not backed up, the server cannot simply be recreated with all existing mail and identities intact.

Immediate recommendation: offsite backups

Before migrating storage, configure offsite backups.

Use Dokploy’s volume-backup feature or another consistent backup method.

Back up:

stalwart_config
stalwart_data

Recommended starting policy:

Frequency: Daily
Retention: 14–30 copies
Destination: S3-compatible storage outside the VPS
Consistency: Stop Stalwart during backup when practical

Suitable backup destinations include:

Amazon S3
Cloudflare R2
Backblaze B2
MinIO
Another S3-compatible provider

Run one manual backup immediately.

Then test a restore into temporary volumes.

A backup should not be trusted until restoration has been verified.

Can the entire server use S3 storage?

Not by itself.

S3-compatible storage is suitable for large blobs such as:

Raw email messages
Attachments
Other binary objects

It does not replace the structured database containing:

Accounts
Domains
Aliases
Folder state
Message metadata
Calendars
Contacts
Configuration objects

A more externalized architecture would be:

Structured data:
PostgreSQL

Messages and attachments:
S3-compatible object storage

Search:
PostgreSQL or a dedicated search backend

Temporary state:
Database or another supported backend

This makes the VPS less critical because the important state lives elsewhere.

Recommended storage roadmap

Stage 1: current deployment

RocksDB in Docker volumes
+
Daily offsite backups

This is simple and lightweight.

Stage 2: more durable deployment

PostgreSQL for structured data
S3-compatible storage for blobs
Offsite backups for both

This is appropriate once the mailbox starts handling important mail.

Migration outline

Do not casually change the active store on a live server.

A safe migration should include:

Create the external PostgreSQL database.
Create the private object-storage bucket.
Back up the current Stalwart volumes.
Stop Stalwart.
Export the existing Stalwart data using the version-specific migration process.
Configure PostgreSQL as the structured data store.
Configure S3-compatible storage as the blob store.
Import the exported data.
Start Stalwart.
Verify accounts and domains.
Verify mail folders.
Verify old messages and attachments.
Verify aliases and catch-all delivery.
Verify calendars and contacts.
Test incoming mail.
Test outgoing mail.
Keep the old volumes untouched as a rollback path.

Do not delete the old volumes until the migrated deployment has been stable and the new backups have been tested.

Storage and backup strategy