For more than two decades, running your own mail server has usually meant assembling the same familiar stack: Postfix for SMTP, Dovecot or Courier for IMAP and POP3, SpamAssassin or Rspamd for filtering, OpenDKIM for signing, certificate automation, monitoring scripts and plenty of operational patience. The result can be extremely reliable, but it becomes harder to operate cleanly once high availability enters the picture.
The setup shared by Florian Paul Azim “gyptazy” Hoberg takes a different route: replacing the classic collection of mail daemons with a highly available Stalwart Mail cluster backed by FoundationDB. This is not just a drop-in Postfix replacement. It is a different architecture for self-hosted and small production mail platforms.
Stalwart brings SMTP, IMAP, JMAP, POP3 and mail security features into a single application. FoundationDB provides a distributed, transactional backend with strong consistency. Together, they make it possible to build a mail platform that is not tied to one machine, one local filesystem or a fragile shared storage layer.
Why the traditional mail stack starts to feel heavy
Postfix is still excellent software. It is mature, stable and battle-tested. The issue is not Postfix itself, but the number of surrounding components required for a complete modern mail service: SMTP, IMAP, spam filtering, DKIM, DMARC, SPF, TLS, mailbox storage, replication, failover and user management.
For a single-node setup, this modular approach is manageable. For a clustered service, the operational cost grows quickly. You need to decide how mailboxes are replicated, how configuration stays consistent, how to avoid single points of failure and how to recover cleanly when a node goes down.
Stalwart simplifies part of that map by bundling many of these functions into one Rust-based mail and collaboration server. It includes modern email security features such as DKIM, DMARC, SPF and ARC, while also supporting protocols like JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV.
FoundationDB brings the distributed storage layer. It is an ACID key-value database designed to run across multiple nodes, which makes it a better fit for highly available mail storage than a single local Maildir tree or a manually replicated filesystem.
Stalwart + FoundationDB vs Postfix + Dovecot
This is not a case of “new is always better”. Postfix and Dovecot remain excellent choices for many environments. The difference is architectural. The traditional stack gives you flexibility through separate components. Stalwart with FoundationDB gives you a more integrated platform with clustering designed into the storage layer.
| Area | Traditional stack | Stalwart + FoundationDB |
|---|---|---|
| SMTP | Postfix | Built into Stalwart |
| IMAP / POP3 | Dovecot, Courier or similar | Built into Stalwart |
| Mail security | OpenDKIM, SPF, DMARC, Rspamd, SpamAssassin and other tools | DKIM, DMARC, SPF, ARC and filtering built in |
| Storage | Maildir, mbox or external backend | FoundationDB distributed store |
| High availability | Requires extra design, shared storage or replication | More natural with distributed backend |
| Configuration | Multiple services and config files | TOML, web UI and centralised configuration |
| Operational model | Powerful but complex at scale | More integrated, with a new learning curve |
| Best fit | Classic mail infrastructure and highly customised environments | Modern self-hosting, HA clusters and smaller service platforms |
The main advantage is fewer moving parts. Fewer daemons, fewer separate configuration files and fewer manual integrations usually mean fewer places where things can break.
The trade-off is that you replace familiar complexity with different complexity. FoundationDB needs RAM, monitoring and operational understanding. Sysadmins who are deeply comfortable with Postfix and Dovecot may prefer the traditional model. Teams looking for a cleaner HA-first mail architecture may find Stalwart much easier to reason about.
What a basic HA architecture looks like
The guide by gyptazy uses Debian as the base system and starts by building a small FoundationDB cluster. Each node installs the FoundationDB client and server packages, exposes the correct network address, receives the shared fdb.cluster file and joins the database cluster.
Once FoundationDB is running, Stalwart is installed with FoundationDB support enabled from the beginning. The rest of the setup is completed from the Stalwart web interface: hostname, unique node ID, storage backend, encryption at rest, domains and accounts.
Because all Stalwart instances use FoundationDB as the shared backend, configuration and mail data can be distributed across nodes rather than locked to a single local filesystem.
| Component | Role in the cluster |
|---|---|
| FoundationDB | Distributed, transactional storage backend |
| Stalwart Mail | SMTP, IMAP, JMAP and mail service layer |
| DNS / MX records | Public mail routing |
| Load balancing or multiple MX records | Traffic distribution between nodes |
| TLS certificates | Encrypted client and server connections |
| Monitoring | Node health, queues, deliveries, errors and resource usage |
| Backups | Protection against accidental deletion and logical corruption |
High availability does not remove the need for backups. A distributed backend can protect against node failure, but it can also replicate mistakes. Deleted mail, bad configuration or application-level corruption still require proper backup and recovery procedures.
Deliverability also remains its own discipline. Even with Stalwart and FoundationDB, you still need correct DNS, SPF, DKIM, DMARC, PTR records, clean IP reputation, TLS, queue monitoring and abuse controls. A highly available mail server is only useful if mail actually reaches inboxes.
Why this matters for Linux and self-hosted infrastructure
The interest around Stalwart reflects a broader shift in open-source infrastructure. Administrators still value proven tools, but many are also looking for systems that reduce operational drag. The same trend is visible in virtualisation, storage, observability and collaboration tools: fewer disconnected components, more integrated control planes and better defaults.
For personal infrastructure, Stalwart can reduce the amount of glue needed to run a modern mail service. For small production deployments, the FoundationDB backend offers a path toward resilience without building a fragile tower of Postfix, Dovecot, shared storage, replication scripts and manual failover logic.
The guide is useful because it does not stop at architecture diagrams. It walks through the practical steps: installing FoundationDB, adjusting cluster addresses, copying the cluster file, installing Stalwart with FoundationDB support and completing the cluster configuration through the web UI.
Postfix is not going away, and it should not. It will remain the right tool in many environments. But Stalwart shows that self-hosted mail can move toward a more integrated design, with built-in security features and distributed storage available from the start.
For Linux administrators, this is the real story. The future of self-hosted mail may not be about replacing every trusted component overnight. It may be about choosing architectures that reduce maintenance burden while preserving control, transparency and resilience.
Frequently asked questions
Can Stalwart replace Postfix and Dovecot completely?
In some deployments, yes. Stalwart includes SMTP, IMAP, JMAP, POP3 and several mail security features. Postfix and Dovecot still remain excellent choices for classic or highly customised environments.
Why use FoundationDB with Stalwart?
FoundationDB provides a distributed, transactional backend. That makes it easier to run multiple Stalwart nodes without depending on local mailbox storage or fragile shared filesystems.
Is this ready for production?
It can be, if designed properly. Production use still requires monitoring, backups, DNS hygiene, TLS, failover testing, security hardening and clear operational procedures.
Who should look at this setup?
Linux admins, self-hosters, small hosting providers and infrastructure teams that want a modern HA mail platform with fewer moving parts than the traditional Postfix and Dovecot stack.