iRedMail vs Mailcow
Two long-running self-hosted mail stacks, same Postfix + Dovecot core underneath, very different deployment models: iRedMail installs straight onto the OS with no Docker required, Mailcow is an 18-service Docker Compose stack with a polished web UI and SOGo groupware built in. Neither ships a transactional sending API. If that gap matters to you, we're a third option — more on that below.
At a glance
Side-by-side, current as of October 2026.
| iRedMail | Mailcow | |
|---|---|---|
| Mail stack | Postfix · Dovecot | Postfix · Dovecot |
| Deployment | OS-native (no Docker) | Docker Compose, 18 services |
| Supported OS | Linux + FreeBSD + OpenBSD | Linux (wherever Docker runs) |
| Backend storage | OpenLDAP, MySQL, MariaDB, or PostgreSQL | SQL (bundled MySQL/MariaDB container) |
| Antispam default | SpamAssassin (Rspamd configurable) | Rspamd |
| Webmail | Roundcube (SOGo optional) | SOGo |
| Calendar / contacts | Optional add-on (SOGo) | Yes, bundled by default |
| Configuration model | Files + iRedAdmin web panel | Bash mailcow.conf + web UI |
| REST API for config | No | Minimal admin API only |
| Transactional sending API | No | No |
| Update model | Manual, scripted package upgrade | Manual update.sh |
| Automatic rollback | No | No |
| Pricing | Free (paid Enterprise Edition + iRedAdmin-Pro available, quote-based) | Free (paid ServerCow support optional) |
How they differ
Deployment model
This is the decision that actually matters between these two. iRedMail's installer script lays Postfix, Dovecot, Roundcube, Nginx, Fail2ban, and SpamAssassin directly onto the host OS — no container runtime, no Docker daemon. That's a deliberate fit for sysadmin teams who prohibit container runtimes on policy grounds, run on BSD, or want the smallest possible runtime surface between the mail server and the kernel.
Mailcow is the opposite bet: a Docker Compose stack of 18 services, each isolated and independently restartable. If your environment already standardises on containers, that isolation is a feature — a broken component restarts on its own without touching the rest of the stack. If your environment prohibits Docker entirely, Mailcow is a non-starter and iRedMail is the only one of the two that fits.
Backend flexibility
iRedMail is unusually flexible on storage: OpenLDAP, MySQL, MariaDB, or PostgreSQL, your choice at install time. The OpenLDAP option matters specifically for shops that already run centralised directory services and want mail accounts to live there rather than in a separate database. Mailcow doesn't offer that choice — it ships with its own bundled SQL database container as part of the compose stack.
Groupware (calendar + contacts)
Mailcow bundles SOGo by default, so CalDAV/CardDAV calendar and contacts work out of the box with no extra configuration. iRedMail can also run SOGo — it's explicitly supported — but it's an optional add-on to the base install rather than a default component, so there are more steps between "fresh install" and "calendar working." If groupware is a hard requirement from day one, that's a real point in Mailcow's favour.
Admin surface
iRedMail's day-two admin surface is the iRedAdmin web panel plus direct file edits in /etc/postfix, /etc/dovecot, and /etc/nginxfor anything the panel doesn't cover. Mailcow's admin surface is a single, more comprehensive web UI covering domains, mailboxes, DKIM, and the SOGo groupware config in one place, backed by the bash-style mailcow.conf for lower-level settings. Neither exposes its configuration as code — there's no declarative file you diff and apply, and no API for driving either one with Terraform or Ansible.
Programmatic sending
Neither ships a transactional sending API. Both are classic mailbox-hosting stacks: the only way to send mail programmatically is SMTP submission, authenticating as a real mailbox with its own username and password. Mailcow's API is administrative — domain and mailbox CRUD — not a sending surface. iRedMail has no REST API at all. If you need both real mailboxes and a sending API for transactional email, neither of these two is built for that out of the box.
Updates
Both treat updates as a manual, operator-supervised procedure. iRedMail's update path is a documented sequence of package upgrades and file diffs. Mailcow's is a single update.sh script that pulls new images and restarts containers. Neither takes an automatic pre-update snapshot, runs a health-check gate, or auto-rolls-back on failure — if an update breaks something, recovery in both cases is whatever the operator does by hand.
Pricing
Both are free to self-host. iRedMail splits into three editions: the open-source base (free), iRedMail Enterprise Edition (one-time per-server payment), and iRedAdmin-Pro (annual subscription for advanced admin features) — pricing on the paid tiers isn't published; you contact iRedMail for a quote. Mailcow's revenue comes from optional ServerCow support contracts rather than a paid product tier — the software itself stays GPL-3.0 either way.
Who each is best for
Choose iRedMail if
- Your environment prohibits Docker or any container runtime.
- You deploy to FreeBSD or OpenBSD, not just Linux.
- You already run OpenLDAP and want mail accounts to live there.
- You want the smallest possible runtime surface between mail and the kernel.
Choose Mailcow if
- You're already standardised on Docker and want per-service isolation.
- You want calendar and contacts (SOGo) working with no extra setup.
- You'd rather manage everything through one comprehensive web UI.
- You value a decade-plus of community mindshare and documentation.
The third option: Vectis Mail
If what's missing from both iRedMail and Mailcow is a programmatic sending API, a declarative config you can diff and apply, or an update path that doesn't depend on the operator remembering to supervise it — that's specifically the gap Vectis Mail is built to close. Same self-hosted control, same proven mail core (Postfix, Dovecot, and Rspamd by default), different operating model:
- Domains, mailboxes and API keys managed from a dashboard or the REST API, with no restarts; stack settings in one declarative
config.yamlthatvectis config applydiffs against the running state, regenerating only what changed. - A 40+ endpoint REST API: transactional sending (single + batch, attachments), inbound webhooks (HMAC-signed, retry-with-backoff), mailbox/domain/alias CRUD, analytics, audit logs.
- Atomic 6-phase updates (snapshot, migrate, pull, deploy, health-check, complete) with automatic rollback on any phase failure.
- Domain-scoped API keys with per-domain rate limits — the multi-tenant pattern neither iRedMail nor Mailcow ships out of the box.
To be equally honest about where Vectis Mail doesn't fit: it's Docker-only (no BSD, no OS-native path), and it doesn't yet ship calendar/contacts — that's on the roadmap, not shipped today. If either of those is a hard requirement, this isn't your answer either. See the dedicated Vectis Mail vs iRedMail and Vectis Mail vs Mailcowcomparisons for the full detail on each.
Frequently asked questions
Is iRedMail or Mailcow better?
It depends on your constraints, not on which is objectively better. Choose iRedMail if you can't run Docker, need an OpenLDAP backend, or deploy to FreeBSD/OpenBSD. Choose Mailcow if you want a Docker-based stack with a polished web UI and SOGo calendar/contacts bundled in. Both build on the same Postfix + Dovecot core, so mail delivery itself is comparably solid either way — the real decision is deployment model and admin surface, not mail quality.
Does iRedMail or Mailcow use Docker?
Mailcow is Docker-only — it ships as mailcow-dockerized, a compose stack of 18 services. iRedMail is OS-native: its installer script lays Postfix, Dovecot, Roundcube, Nginx, Fail2ban, and SpamAssassin directly onto the host, with no container runtime involved. If your environment prohibits Docker, iRedMail is the one that fits; if you want everything isolated and restartable independently, Mailcow's containers do that.
Which has calendar and contacts (CalDAV/CardDAV)?
Mailcow bundles SOGo by default, so calendar and contacts work out of the box. iRedMail can also run SOGo, but it's an optional add-on to the base install rather than a default component — so Mailcow gets you there with fewer steps if groupware is a requirement from day one.
Do either have a transactional sending API?
No. Neither iRedMail nor Mailcow ships a REST API for programmatic sending, inbound webhooks, or per-domain analytics — both are classic mailbox-hosting stacks where the only way to send mail programmatically is SMTP submission with a mailbox's own credentials. If you need a sending API alongside mailbox hosting, that's the gap a platform like Vectis Mail is built to close.
What's a third option if neither iRedMail nor Mailcow fits?
Vectis Mail is a Docker-based self-hosted mail platform (same Postfix/Dovecot/Rspamd core) built around a declarative config.yaml, a 40+ endpoint REST API for sending and inbound webhooks, and atomic updates with automatic rollback. It doesn't run on BSD and doesn't yet ship calendar/contacts — so it's not a fit for every case either, but it's worth a look if the gap in both iRedMail and Mailcow is "no API" or "no safe update story."
Related comparisons
See how Vectis Mail itself compares to each.
Vectis Mail vs iRedMail →
REST API, declarative YAML, and Rspamd by default vs iRedMail's OS-native, file-configured stack.
Vectis Mail vs Mailcow →
Declarative config and a transactional sending API vs Mailcow's web-UI-driven, admin-only surface.
Best self-hosted email servers (2026) →
The whole landscape by buyer type — seven options including both of these, compared side by side.