mailcow vs Stalwart: when to choose each for self-hosted email
Choose mailcow when you want a familiar multi-container suite and can carry its footprint. A team hosting its own domains that already knows Postfix, Dovecot and Rspamd, and that wants SOGo groupware and ActiveSync for phones, gets a stack where each service runs in its own container. The cost is resources: mailcow needs at least 6 GiB of RAM plus 1 GiB of swap in its default configuration, recommends 8 GiB for about 5 to 10 users, and 16 GiB for a company with 15 ActiveSync phones and about 50 concurrent IMAP connections. Confirm that budget, along with the 20 GiB of disk excluding mail storage, before committing. Its license is GPL-3.0 and the project suggests support contracts through Servercow, so ask who on your side can troubleshoot a container-level fault.
Choose Stalwart when you want one server, JMAP and a choice of storage and clustering. Stalwart handles IMAP, POP3, SMTP, CalDAV, CardDAV, WebDAV and JMAP in a single Rust server, stores data in backends such as PostgreSQL, S3-compatible storage or FoundationDB, and clusters either peer-to-peer or through Kafka, Redpanda, NATS or Redis. The trade-off is licensing: Stalwart is dual-licensed under AGPL-3.0 and the proprietary Stalwart Enterprise License for commercial use. The Community edition has no mailbox limit, while Enterprise is a per-mailbox subscription with features unlocked by a license key. Have legal review which terms apply to your use before you rely on either path.
Decide on five questions: client protocols, RAM budget, clustering, paid support and in-house skills. List the clients your users actually run, since ActiveSync and SOGo points toward mailcow while JMAP-capable clients point toward Stalwart. Set a memory ceiling per mail node and check it against each stack. Ask whether you need multiple nodes sharing storage, which favors Stalwart's clustering options. If you need a support contract with a response commitment, check Stalwart's pricing page, where Premium Support starts at 150 mailboxes, and ask Servercow for its terms. Finally, be honest about skills: a team fluent in Postfix and Dovecot will run mailcow faster, while a team comfortable with Rust-based services and a database backend may prefer Stalwart's single process.
Which scenario favors mailcow and which favors Stalwart
This table maps common mail scenarios to the platform that fits better and states the condition under which each one wins. Read each row against your own user count, client mix, host size and support requirements, since the answer often changes at a specific threshold.
| Scenario | Better fit | Why and the condition that decides it |
|---|---|---|
| Small office with standard IMAP and SMTP clients | mailcow | mailcow bundles Postfix, Dovecot, Rspamd and SOGo in a documented stack that many operators already know. It wins when your team wants a familiar, webmail-equipped suite and is comfortable running Docker. |
| ActiveSync-heavy company with many phones | mailcow | mailcow's default configuration includes ActiveSync support through SOGo, and its requirements page sizes a 15-phone company at 16 GiB RAM. Choose it if phone sync is a core requirement and you can budget for that memory footprint. Confirm your exact ActiveSync needs against the mailcow documentation. |
| Clients demanding JMAP | Stalwart | Stalwart supports JMAP alongside IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV in one server. It wins when your mail clients or internal apps are JMAP-based and you want the protocol served natively, not bridged. |
| Clustered or multi-node mail service | Stalwart | Stalwart clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis. It fits teams that need several nodes sharing one mail service. Confirm the cluster topology and failover behavior with the Stalwart documentation before committing. |
| Tight RAM host or small virtual machine | Stalwart | mailcow needs at least 6 GiB of RAM plus 1 GiB of swap by default, while Stalwart's single Rust binary avoids running a separate container per service. Stalwart wins when memory is the binding limit, but confirm its actual footprint on your workload, since its published requirements were not part of the researched facts. |
| Team needing published paid support tiers | Stalwart | Stalwart's pricing page publishes Enterprise per-mailbox prices, a 25-mailbox minimum and Premium Support from 150 mailboxes with a first response within 48 business hours. mailcow's support comes through Servercow, so ask for its current terms in writing before comparing. |
| Team wanting one container per mail component | mailcow | mailcow runs Postfix, Dovecot, Rspamd, ClamAV, MariaDB, Redis and Nginx as separate containers, so each part can be inspected, restarted or swapped with standard Docker tooling. It suits operators who prefer to debug each component separately. |
How mailcow and Stalwart are built and what that means for operations
mailcow assembles a mail system from separate containers, each with its own version, configuration and logs. Stalwart runs as one Rust server that talks to pluggable storage and optional clustering backends. The cards below cover what each design means for upgrades, troubleshooting and component-level tuning, and where the trade-offs fall for your team.
mailcow's container-per-service layout
mailcow runs Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB, Redis, Nginx, Unbound, Olefy and an ACME client for Let's Encrypt certificates, each in its own container. Each service can be inspected, restarted and tuned on its own, and the mailcow documentation describes the stack that way. The cost is more moving parts: a fault can sit in the seams between containers, so your team needs to know which container owns which symptom before it starts changing settings.
Stalwart's single server process
Stalwart serves JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV from one Rust server, with spam filtering built in. Fewer processes means fewer inter-service configurations to keep aligned, and one log stream to read during an incident. The trade-off is that component-level tuning happens inside one application rather than in the separate tools many mail teams already know, so skills built on Postfix and Dovecot do not transfer directly.
Upgrades and version coupling
With mailcow, an upgrade touches several containers that are versioned and released together through the project's date-based releases, so you upgrade the suite as a unit and test the whole stack. Stalwart upgrades replace one binary, but the server carries every protocol, so a regression in one area affects all of them. Ask each vendor how it handles configuration changes between versions and whether a rollback path is documented for your storage backend.
Storage and state location
mailcow keeps its state in MariaDB and Redis containers alongside mailbox storage, so backups must cover several data stores that must stay consistent. Stalwart stores data in a choice of backends, including RocksDB, PostgreSQL, SQLite, S3-compatible storage and others. That choice lets you move metadata and blobs to infrastructure your team already operates, but it also means the storage decision is an architecture decision you should make before go-live and test restores against.
Troubleshooting across boundaries
When mail stops, mailcow failures often surface in one container while the cause lies in another, such as Unbound DNS resolution affecting Postfix delivery or Rspamd scoring affecting Dovecot delivery. Stalwart concentrates the same decision path in one process, which shortens the search but leaves less isolation between protocols. Before selecting either, have your team run a delivery failure drill and confirm which logs, health checks and metrics each platform exposes.
Clustering and resource footprint
mailcow's footprint is set by its container stack, and its system requirements list a minimum memory figure plus recommended sizes by user and connection count. Stalwart supports clustering through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis, which matters if you need more than one node. Confirm the clustering model you need with each vendor in writing, since a single-node mailcow deployment and a clustered Stalwart deployment fail over in different ways.
Protocols, filtering, clustering and identity compared
This table sets mailcow's container stack against Stalwart's single server on the capabilities that shape day-to-day operation. Read each row as a question to answer for your own environment, and treat any cell marked for confirmation as an open item to resolve with the vendor before you commit.
| Capability | mailcow | Stalwart |
|---|---|---|
| Mail protocols | Ports required for IMAP, POP3, SMTP and ManageSieve, with SOGo providing the groupware front end | Lists JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV in one Rust server |
| Spam filtering | Rspamd runs as its own container, with ClamAV available for antivirus and optional disabling to save memory | Built-in filter with LLM-driven analysis, DNS blocklist checks, greylisting and Pyzor |
| Storage backends | Postfix, Dovecot and MariaDB as separate components, configured per container | RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, S3-compatible storage, Azure and Redis |
| Clustering | Multi-node design is not covered by the supplied facts; confirm the approach with mailcow maintainers | Peer-to-peer coordination or Kafka, Redpanda, NATS or Redis, with the deployment details to confirm |
| Container packaging | Each application in its own container, managed through the mailcow-dockerized project | Single server binary, with container images and packaging options to confirm in the Stalwart documentation |
| Identity provider integration | Confirm LDAP, OIDC or SSO options against the current mailcow documentation before planning | Confirm directory and SSO integration with Stalwart before planning |
| ActiveSync and groupware | SOGo groupware with ActiveSync support in the mailcow stack, consistent with its published requirements for ActiveSync phones | Confirm ActiveSync support with Stalwart; CalDAV, CardDAV and WebDAV are listed |
What the GPL, AGPL and Enterprise terms mean for each
mailcow is a GPL-3.0 dockerized mail server suite. Its code is published under a copyleft license, so if you modify mailcow and distribute the modified version, the GPL-3.0 terms apply to that distribution. Running it internally for your own organization does not, by itself, trigger distribution obligations, but your legal team should confirm how the license applies to your specific use. The project is managed and maintained by The Infrastructure Company GmbH, and that company also holds the registered word mark for mailcow.
- License: GPL-3.0, a copyleft license covering the mailcow-dockerized code.
- Maintainer: The Infrastructure Company GmbH manages and maintains the project.
- Support path: The mailcow README suggests support contracts through Servercow, which is the route the project points to for paid help.
- Trademark: mailcow is a registered word mark of The Infrastructure Company GmbH, so naming a hosted or rebranded service mailcow requires checking the trademark terms.
- Paid edition: No separate Enterprise edition of mailcow was supplied in our research. Confirm directly with the maintainer whether any paid tier exists before you budget for one.
Confirm with your legal team how GPL-3.0 applies if you plan to modify or redistribute mailcow, and ask Servercow or the maintainer to state in writing what support covers and what it costs.
Stalwart is dual-licensed. The code is available under the AGPL-3.0, and commercial use can also fall under the proprietary Stalwart Enterprise License. The Community edition is free and has no mailbox limit. Enterprise is a per-mailbox subscription, and its features are activated by a license key. Cancelling reverts the server to Community without data loss, according to the Stalwart pricing page. That means the license choice affects both your legal position and your budget.
- Community: Free with no mailbox limit, under the AGPL-3.0 terms.
- Enterprise prices: The pricing page lists 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, falling to 1.04 euros from 10,000 mailboxes (source: Stalwart pricing page).
- Minimum: Enterprise has a 25-mailbox minimum, and quotes are required above 100,000 mailboxes.
- Premium Support: Included from 150 mailboxes, with an initial response within 48 business hours. Smaller Enterprise customers use community support.
- Reversibility: Cancelling the license key reverts to Community without data loss, which matters if you plan for a future change of tier.
Before buying, check the current pricing page for the exact terms, confirm how the AGPL-3.0 applies to your deployment, and ask whether the license key covers the features your mail team needs.
Procurement teams usually need to see license terms, support commitments and the price basis in writing before approving a mail platform. The two products answer those questions differently. mailcow leans on a copyleft license with support available through a named vendor, while Stalwart offers a dual-license model with a published per-mailbox price list and tiered support. Neither choice removes the need to document how the software is licensed in your environment.
- Paper trail: Keep the license file, the pricing page version and any signed quote together for the audit file.
- Per-mailbox math: Stalwart Enterprise costs scale with mailbox count, so a headcount change changes the annual subscription.
- Support scope: Ask for the written support scope, response times and escalation path, since the published Stalwart terms and mailcow's suggested Servercow contract are not the same kind of commitment.
- Recurring versus one-time: License fees recur on Stalwart Enterprise, while mailcow's cost depends on any support contract and on your own operating effort.
- Certification claims: Neither license is a certification. Auditors assess your controls, not the license file.
Ask each vendor for a written statement of license terms and support scope, then ask your auditor which evidence they expect for the mail platform.
What Stalwart Enterprise costs per mailbox and when it applies
The published Stalwart Enterprise price is 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, according to the Stalwart pricing page. The rate falls to 1.04 euros per mailbox from 10,000 mailboxes, the subscription carries a 25-mailbox minimum, and deployments above 100,000 mailboxes are quoted individually. Premium Support starts at 150 mailboxes, with an initial response within 48 business hours. Smaller Enterprise customers rely on community support. Calculate the annual figure from your actual mailbox count, and check whether shared, resource or service mailboxes count toward the total under the pricing terms before you budget.
The Enterprise license is a recurring cost, paid per mailbox each year, and it unlocks features through a license key. The Community edition is free with no mailbox limit and is licensed under AGPL-3.0, so the subscription buys the proprietary Enterprise license, features, and support rather than the mail software itself. Cancelling reverts the server to Community without data loss, which lowers the risk of a commitment, but confirm in writing which Enterprise features stop working after reversion and whether any of them your team depends on. The supplied facts do not give a published subscription for mailcow. The mailcow project is GPL-3.0 and its maintainers suggest support contracts through Servercow, but no price is listed. Ask Servercow and the mailcow maintainers for a written quote covering response times, scope and the cost of any support tier, and compare that quote with the Stalwart figure for your mailbox count.
Your quote should separate one-time costs from recurring ones. The recurring items are the Stalwart subscription, any mailcow support contract, and the time your staff spend on patching and backups. The one-time items are migration, configuration and testing. Ask each vendor what is included, who responds to incidents, and what changes at the mailbox tiers you expect to cross during the next few years. Illustrative example: a team that starts at 240 mailboxes and grows past 10,000 would see the per-mailbox rate change, so ask whether the tier is applied to the whole base or only to the mailboxes above each threshold.
How to move mailboxes from mailcow to Stalwart, or back
This sequence moves a mailcow installation to Stalwart, or reverses the path, with DNS, certificates and client settings changed only after data has been verified on the target. The result is a tested cutover and a mailcow instance that can be retired after a monitoring period.
Inventory domains, mailboxes and aliases
The mail administrator exports a list of every domain, mailbox, alias, forwarding rule and shared folder from the mailcow admin interface, and records which users rely on ActiveSync, CalDAV or CardDAV. Mailcow also uses its own containers for SOGo groupware, so calendars and contacts need a separate export plan. Record the current DNS records for MX, SPF, DKIM, DMARC, autodiscover and autoconfig for each domain. This step is done when the inventory is reviewed by someone other than the person who wrote it and every mailbox has an owner and a target account on Stalwart.
Choose and prepare the Stalwart storage backend
Decide which backend will hold metadata and message blobs before importing anything, because Stalwart supports several options including PostgreSQL, MySQL, SQLite, RocksDB, FoundationDB and S3-compatible storage. Confirm in the Stalwart documentation which combination is supported for your scale, backup method and clustering plan. Install Stalwart on a test host, create one domain and two test mailboxes, and confirm that mail can be sent and received through the standard ports. This step closes when a test message round-trips and the backend backup has been restored once in a scratch environment.
Recreate domains, DKIM keys and certificates
Add each domain to Stalwart and generate new DKIM key pairs there, because private signing keys do not move cleanly between mailcow and Stalwart unless you export them deliberately and confirm the import path in the documentation for both platforms. Prepare TLS certificates for the mail host names, using Let's Encrypt or your certificate authority, and check that the ports mailcow uses (25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443) are open on the new host. Publish nothing to public DNS yet. This step closes when the new DKIM selectors are visible to a test lookup and a test message passes SPF and DKIM checks against a staging address.
Migrate mail and calendar data with IMAP sync
Create each mailbox on Stalwart with a temporary password, then run an IMAP synchronization tool from the mailcow mailbox to the Stalwart mailbox for each account, starting with a low-volume pilot group. Calendars and contacts are handled separately through CalDAV and CardDAV export and import, and you should confirm the supported formats and any attachment limits in the Stalwart documentation. Keep the source mailbox read-only during the final pass where possible. This step closes when message counts, folder structures and a sample of calendar entries match between source and target for every pilot account, and the sync log shows no unresolved errors.
Rebuild spam rules, filters and client profiles
Mailcow's Rspamd rules, per-user filters, sieve scripts and allowlists do not move automatically into Stalwart's built-in spam filter, so list each rule from the mailcow admin panel and recreate the equivalent policy in Stalwart. Stalwart's spam filter uses DNS blocklists, greylisting, Pyzor and LLM-driven analysis, and you should confirm which of these you want enabled and how they are configured in its documentation. Rebuild client profiles for mail apps, including autoconfig and autodiscover records, and test each client type. This step closes when a reviewed list of rules shows each one as migrated, replaced or deliberately dropped, and a test message from an external sender is scored and filtered as expected.
Test client connections on every platform
Have a small set of users connect from desktop mail clients, mobile devices and webmail, and check sending, receiving, folder sync, calendar and contact access, and push or background behavior on each. Confirm which protocols each client needs, because Stalwart supports JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV, and some clients may fall back to a different protocol than they used with mailcow. Record the client version and protocol in use for each test. This step closes when every test user can complete a full send and receive cycle on each client type, and the test log lists any client that required manual settings.
Cut over MX and client settings
Lower the TTL on the MX, autodiscover and autoconfig records well ahead of the change, using a value your DNS provider supports. At the agreed window, point the MX records to Stalwart, update the SPF include for the new sending address set, and switch client settings to the new host, keeping mailcow running so that inbound mail can be redirected if a problem appears. Run a final incremental sync for any mail received during the window. This step closes when inbound and outbound test messages arrive correctly for all domains, DMARC reports show aligned sending, and no user reports missing mail for the first monitoring interval.
Retire mailcow after a monitoring period
Keep mailcow in read-only or standby mode through a monitoring period agreed in writing with the business owner, while watching queues, bounce rates, spam scores and support tickets on Stalwart. Take a final mailcow backup, store it according to your retention policy, and then shut the stack down rather than deleting it immediately. Confirm in the mailcow documentation what the backup contains and how a restore would be executed, and do the same check for Stalwart backups. This step closes when the stack is powered off, the backup restore test has been completed once, and the change record shows who approved retirement.
Where self-hosted mail projects usually run long
Most mail projects run long before the first mailbox is created, in the DNS and network work that both mailcow and Stalwart depend on. Forward and reverse DNS for the mail host, SPF, DKIM and DMARC records, and the PTR record your provider controls all need to match before outbound mail is trusted. Check the reverse DNS with your hosting provider early, because changing it can depend on their ticket queue rather than your team. Port access is the second common delay. mailcow requires incoming TCP ports 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443, and many cloud networks block port 25 by default or route it through an egress policy. Confirm each port in writing with the network owner, including the firewall, load balancer and any security group between the internet and the host. Certificate automation and deliverability are where the work tends to stretch. mailcow ships an ACME client for Let's Encrypt, and Stalwart manages its own TLS configuration, but both need the hostnames to resolve publicly before issuance succeeds, and the certificate covers the mail, web and autodiscovery names you publish. Deliverability warm-up is not a configuration task. New sending IPs and domains usually need a gradual ramp and monitoring of bounce and complaint signals, so plan for a period where some outbound mail lands in spam folders. Spam tuning follows the same pattern: mailcow's Rspamd and Stalwart's built-in filter both need thresholds, allow lists and DNS blocklist choices tuned against your real traffic. Ask any partner to scope a tuning window and a review of false positives, not just an installation. Client migration and clustering design are the decisions that change the scope most. Moving mailboxes from an existing server means agreeing on IMAP sync windows, handling folder mapping and deciding how calendars and contacts move. Stalwart clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis, while a mailcow stack runs as a single set of containers, so high availability needs a different design from the start. Ask for a written scope that names the migration method, the cutover plan, the rollback path and the clustering topology, and confirm which items the quote covers and which the client's own team must provide.
Questions buyers ask before choosing a self-hosted mail server
Is Stalwart free to run in production?
Yes, the Community edition is free and carries no mailbox limit, and Stalwart is dual-licensed under the AGPL-3.0 and the proprietary Stalwart Enterprise License for commercial use. Production use on Community is a licensing question you should confirm against the AGPL-3.0 terms with your legal team. What changes in production is the set of features unlocked by an Enterprise license key, so list the features you need before deciding. Cancelling an Enterprise subscription reverts the server to Community without data loss, according to the Stalwart pricing page.
What does Stalwart Enterprise cost, and from how many mailboxes?
Enterprise is a per-mailbox annual subscription, and the published price is 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, falling to 1.04 euros from 10,000 mailboxes. The minimum is 25 mailboxes, and quotes above 100,000 mailboxes are negotiated, per the Stalwart pricing page. Your total depends on your mailbox count, the tier you land in and any support you add. Premium Support is included from 150 mailboxes with an initial response within 48 business hours, so smaller customers rely on community support.
Does mailcow need a paid subscription to run?
No. mailcow is a GPL-3.0 dockerized suite, and you can run it without a subscription. The project is managed and maintained by The Infrastructure Company GmbH, which suggests support contracts through Servercow, according to the mailcow repository. Your recurring costs are the server, storage, DNS and your staff time for patching and monitoring. A support contract is optional, and you should ask Servercow or your provider what it covers before assuming it is needed.
How much RAM does each mail server need?
mailcow needs at least 6 GiB of RAM plus 1 GiB of swap in its default configuration, and the system requirements page recommends 8 GiB for about 5 to 10 users and 16 GiB for a company with 15 ActiveSync phones and about 50 concurrent IMAP connections. mailcow also needs 20 GiB of disk excluding email storage. Disabling ClamAV and full-text search with SKIP_CLAMD and SKIP_FTS saves memory at the cost of antivirus scanning and search. No comparable RAM figure for Stalwart was supplied here, so benchmark it on your own mailbox count and load before sizing hardware.
Can a small IT team run either server by itself?
A team with Linux administration, DNS, TLS and mail deliverability skills can run either one, but the work differs. mailcow runs about a dozen containers, including Postfix, Dovecot, Rspamd, SOGo and MariaDB, so your team patches and debugs several components through Docker. Stalwart is a single Rust server with built-in spam filtering and pluggable storage, so the skills are fewer but the storage and clustering choices are yours to make. Confirm that your team can manage DKIM, SPF, DMARC and reverse DNS in either case.
How long does a migration to either server take?
The duration depends on mailbox count, total mailbox size, the source platform, how many domains and aliases you move and how much DNS and client reconfiguration your users need. No migration duration was supplied for either server, so ask any implementer for a timeline based on a written inventory of your mailboxes, folders and client connections. Plan a parallel run and a rollback path, and confirm which protocols and calendar or contact data must move with each mailbox.
What does outside help cover for a self-hosted mail server?
Outside help is usually bought in separate pieces: vendor support, a platform implementation partner and independent security testing. Stalwart Enterprise includes Premium Support from 150 mailboxes, and mailcow support contracts are offered through Servercow. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, under a fixed scope agreed in writing, and offers retainers for ongoing support. DeployOpen does not publish prices, so request a quote against a written scope and ask which mail components are included.
How DeployOpen helps choose, implement and migrate a self-hosted mail server
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For mailcow vs Stalwart, that means turning the choice between a Postfix, Dovecot and Rspamd container stack and a single Rust server into a written scope, a tested build and a handover your mail team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the mail domains, user counts, client protocols and storage backends that mailcow or Stalwart must serve.
- Scoping records which Enterprise features, if any, are required, so licensing and support questions are settled before build.
How we build
- Build covers installation on the host OS and hardware you confirm, plus DNS, TLS certificates and mail routing.
- Testing covers spam filtering, mailbox migration, client access over IMAP or JMAP, and clustering or backup where in scope.
- Hardening follows your security baseline, including firewall rules for the mail ports each platform requires.
How we hand over
- Deliverables include architecture notes, runbooks for routine administration and a documented upgrade procedure.
- Backup and restore steps are written and exercised so your team knows how to recover mailboxes and configuration.
- Handover sessions walk administrators through the platform you chose, so operating knowledge stays in your organization.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should state which upgrade releases, security patches and response expectations are included, in writing.
- Ask for a quote built from your written scope, since DeployOpen does not publish a price list.
