stalwartlabs/stalwart

Stalwart is worth a look if you want one server to handle mail, calendars, contacts and files, but the split between AGPL and Enterprise features deserves checking before you commit.

The problem

Running your own mail usually means assembling Postfix or an MTA, Dovecot for IMAP, something for CalDAV/CardDAV, and a WebDAV service for files. Each piece has its own configuration, user database and upgrade path, and you end up owning the glue between them. Stalwart collapses that into a single server that speaks SMTP, IMAP4, JMAP, POP3, CalDAV, CardDAV and WebDAV. The workflow change is that account and protocol setup happens once in one place rather than per daemon, and clients can use modern JMAP instead of only IMAP.

What's different

The distinguishing part is protocol breadth in one Rust codebase: the README lists JMAP for Mail and Sieve Scripts, object metadata, WebSocket, blob management and quotas, plus IMAP4rev2/rev1, ManageSieve, POP3 with STLS/SASL, and SMTP. That matters if you want a mail server that modern clients can talk to natively while legacy clients still connect over IMAP or POP3. One server also means one place to look when a calendar invite or a Sieve rule misbehaves, instead of tracing it across several processes.

The trade-off is licensing and scope. The project is dual-licensed: AGPL-3.0 for the core, with an Enterprise license for the rest. The README says roughly 85% of features are open source and that multi-tenancy, SCIM provisioning, sharded storage and live telemetry are Enterprise features. So a single-team deployment can likely stay on the AGPL edition, but a hosting provider planning many tenants or sharded storage hits the paid tier. The license comparison page is the right place to check what you actually need.

Who should try it

A good fit is a small team or self-hoster who wants one mail plus calendar/contacts/files server, is comfortable running a Linux, macOS, FreeBSD, Windows or Docker deployment, and does not need multi-tenancy. A poor fit is a provider that needs sharded storage or SCIM provisioning across many tenants, since those are documented as Enterprise-only and change the cost model. If you already have a working Postfix/Dovecot setup and only need mail, the migration cost may not be worth the broader protocol surface.

Requirements and limitations

Deployment is documented for Linux, macOS, FreeBSD, Windows and Docker, so a container path exists alongside native installs. Mail servers are operationally demanding regardless of implementation: you still need to handle DNS records, TLS certificates and deliverability, and none of that is removed by a single binary. The licensing split is the main structural constraint: features that matter at hosting scale are in the Enterprise edition, so the open-source edition is not the whole product. Ongoing upkeep includes tracking releases and the Enterprise feature boundary as your deployment grows.

HotRepo's take

The only dated signal is a Rust weekly board entry: +189 stars for the week ending 2026-10-27, rank #15. There is no daily-board history in the stored coverage, so persistence cannot be judged from one snapshot. Before adopting, verify the feature comparison to confirm the AGPL edition covers the protocols and scale you need, and check the install guides for your target platform.