Mailcow vs docker-mailserver

Mailcow and docker-mailserver are the two most-recommended self-hosted mail stacks you'll see people running in production, and they sit at opposite ends of the same idea. Both wrap the classic Postfix/Dovecot combination in Docker and both get you off Google Workspace or Microsoft 365 for good. Where they split is philosophy: Mailcow wants to be a complete, self-managing product with a web admin panel doing the work for you; docker-mailserver wants to be a single transparent container that does nothing you didn't explicitly configure in a file. That one disagreement decides almost everything else — RAM, setup time, and how much you'll be clicking versus typing.

A polished suite vs. a bare container

Mailcow orchestrates roughly twenty containers — Postfix, Dovecot, Rspamd, ClamAV, SOGo for webmail and groupware, and a PHP admin UI — into a stack that behaves like one product. You get a web panel for managing domains, mailboxes, DKIM keys, and quarantine, plus a mature, well-documented setup that a lot of r/selfhosted threads point to as the default answer to "how do I run my own email." The cost of that completeness is running and updating twenty containers instead of one.

docker-mailserver is the other most-recommended answer on the same threads, and it takes the opposite stance. It is one container, no database, no web UI. You add a mailbox with setup email add, edit a handful of plain config files, and that's the entire admin surface. There is nothing to click through and nothing running that you didn't ask for — the whole server fits in your head, and in your git repo if you want to version it.

Footprint: an order-of-magnitude gap, measured

This is where the split shows up most sharply, and the numbers here are measured, not estimated. A fresh Mailcow instance idles at ~2.2 GB across its 18 containers at first boot, with no mail flowing yet — ClamAV alone accounts for roughly 960 MB of that (about 43% of the total), Rspamd around 326 MB, and SOGo's webmail around 251 MB. That's before any real usage, and it's why Mailcow's own docs put the practical minimum at 6 GB of RAM plus 1 GB of swap, with 8 GB recommended once you're supporting 5–10 users on ActiveSync. Mailcow's install also isn't unattended the way a single-binary tool is — its generator script prompts for hostname and timezone — so 6 GB is the honest planning number to budget against, not the measured idle figure.

docker-mailserver measures ~94 MB idle at first boot on the same box, with roughly 1.2 GB of disk. There's a wrinkle worth knowing: with zero mailboxes configured, docker-mailserver deliberately counts down and shuts itself off — the container literally tells you "you need at least one mail account to start Dovecot" — so that number is taken with one mailbox created, which is the honest, realistic reading rather than an idle-and-empty trick. Either way, a container that idles under 100 MB against a suite that needs 6 GB of headroom isn't a marginal gap — it's the difference between the cheapest VPS tier available and something several times the price, before you've sent a single email.

Setup and day-to-day admin

Mailcow's setup script asks a couple of questions and then docker compose up brings up the whole stack; after that, almost everything — adding a mailbox, rotating a DKIM key, checking quarantine, reading mail queues — happens in the web panel. That is a real advantage for anyone who doesn't want to live in a terminal, and it means a non-technical co-admin can be handed limited access without touching a config file.

docker-mailserver's day-to-day is the CLI: setup email add, setup alias add, and a compose.yaml plus a mailserver.env you edit directly. Nothing here is hidden behind a UI, which is exactly the point for people who want their mail server's entire state readable in a diff. It is also, unavoidably, less approachable for someone who would rather not memorize a setup script's subcommands.

Webmail, groupware, and what you give up

Mailcow's completeness earns its footprint here in a way docker-mailserver can't match. SOGo bundles a full webmail client, shared calendars, and contacts, and Mailcow's ActiveSync bridge means iPhone Mail and Outlook configure themselves against it — mail, calendar, and contacts sync the way people expect from a commercial provider.

docker-mailserver ships none of that. It's SMTP and IMAP, full stop — no webmail, no calendar, no admin UI. If your users need a browser-based inbox or calendar sync, you're standing up Roundcube or another IMAP client separately; docker-mailserver doesn't try to be more than a mail server.

Antispam and antivirus

Both take spam seriously, and Rspamd does the filtering in each — you are not choosing between "protected" and "unprotected" here. Mailcow bundles ClamAV on by default, which is also its single biggest RAM line item at that measured ~960 MB. docker-mailserver ships Rspamd with ClamAV available but optional; leaving it off is part of what keeps the container's footprint near 100 MB, and the same toggle exists in Mailcow if you're willing to trade virus scanning for RAM.

Which to choose

Choose Mailcow if you want the complete, all-in-one experience — webmail, calendars, ActiveSync, and a web panel doing the admin work — and you have the 6 GB-plus of RAM its docs call for. Choose docker-mailserver if you want the leanest, most transparent option: a single container, config files you can put in git, and a footprint that fits comfortably on the cheapest VPS tier. Both rate 4 out of 5 to deploy, for different reasons — Mailcow's difficulty is in operating twenty moving parts, docker-mailserver's is in hand-editing every config file yourself.

Not the only two options

Mailcow and docker-mailserver are the two most extreme points on the mail-server spectrum — full groupware suite versus bare config container — but the other two apps in this space sit in between and are worth knowing before you commit. Stalwart is a modern, all-in-one Rust binary that beats even docker-mailserver on footprint while still shipping a built-in admin UI and modern JMAP support; see our Stalwart vs Mailcow comparison for that angle. Mailu is the middle ground on the "managed vs. config-file" question specifically — a lighter, MIT-licensed Docker Compose suite with a setup wizard, an admin panel, and bundled webmail, without Mailcow's SOGo groupware layer or its RAM bill; our Mailu vs docker-mailserver comparison covers that exact trade-off in more depth than this page does.

Who should pick neither

If Mailcow's 6 GB feels like overkill but docker-mailserver's config-file-only model feels too bare — you want a web admin panel and bundled webmail, just not the groupware and ActiveSync layer — Mailu is the honest middle ground, and the Mailu vs docker-mailserver comparison is the better read for that specific question.

Choosing between docker-mailserver and Mailcow

Flip the framing and the decision is the same trade-off restated: default to docker-mailserver unless you have a specific reason to want Mailcow's SOGo webmail, calendars, or ActiveSync — its measured ~94 MB idle footprint and single-container simplicity make it the cheaper, easier-to-reason-about choice for most self-hosters. Pick Mailcow only when that completeness is a real requirement, not a nice-to-have, and you're comfortable budgeting for the 6 GB of RAM and twenty containers it takes to get there.

The part neither solves: deliverability

Whichever of these you run, the software was never the hard part of self-hosting email — getting the rest of the internet to trust your server is. You still need a clean sending IP, a correct reverse-DNS (PTR) record, and properly configured SPF, DKIM, and DMARC, regardless of whether you picked the twenty-container suite or the single lean one. Get those wrong and your mail lands in spam no matter how the admin panel looks. Budget as much time for DNS and IP reputation as for the install itself — that determines whether self-hosted email works for you far more than the Mailcow-versus-docker-mailserver decision does.