mailcow vs Mailu: when each one is the right choice
Choose mailcow if your users need SOGo groupware and ActiveSync for phones, and your host can spare the memory that comes with them. Choose Mailu if you want a leaner, MIT-licensed set of Docker images, you plan to run on Kubernetes, or you do not need a groupware layer at all. The decision turns on four questions: whether users need SOGo and ActiveSync, how much RAM the host can give the mail stack, whether your team already operates Kubernetes, and how much vendor-backed support matters to your procurement process. mailcow is GPL-3.0 and its documentation sets a baseline of at least 6 GiB of RAM plus 1 GiB of swap for its default configuration, with 8 GiB suggested for about 5 to 10 users and 16 GiB for a company with 15 ActiveSync phones and about 50 concurrent IMAP connections. Its advantage is an integrated groupware and mobile sync story, and its support path is more formal: The Infrastructure Company GmbH maintains the project and suggests support contracts through Servercow. That advantage matters only if you need those features and can fund the memory. Confirm the current figures on the mailcow system requirements page against your user count before you size a host.
Mailu is MIT-licensed, and its configuration, Dockerfiles and code are under that license. It ships IMAP, SMTP, submission, webmail and an administration interface with per-domain delegation, and it documents both Docker Compose and Kubernetes setups. Its advantage is a smaller footprint and fit for a cluster your team already runs, but it does not aim to include groupware, so ActiveSync or a shared calendar will need a separate system. Before you commit, test the mobile clients your users rely on, confirm the Mailu release you will deploy in the Mailu releases list, and ask whether any paid support is available for your region. Plan for upgrades in either case: both projects change between releases, and your runbook should name who applies them and how you roll back.
Which mail server fits which team scenario
This table matches common team scenarios to the mail server suite that fits them better, based on groupware, memory needs, Kubernetes paths, support and platform support. Read each row as a starting point, and check the items marked for confirmation against your own hosts and vendor terms. The main takeaway is that mailcow suits teams that want bundled groupware and have memory to spare, while Mailu suits lean, groupware-free deployments.
| Team scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Small company wants calendar and shared contacts on phones | mailcow | SOGo groupware and ActiveSync are part of the stack. Mailu aims not to ship groupware features. |
| Team runs Kubernetes and wants a Helm-style path | Mailu, after confirming | Mailu documents Kubernetes setup guides. Neither supplied fact names a Helm chart, so check both projects for one. |
| Host has limited RAM and cannot run the full mailcow stack | Depends on your measurements | mailcow needs at least 6 GiB RAM plus 1 GiB swap by default. Test Mailu's memory use on your own host before deciding. |
| Organization needs a paid support contract from the project vendor | mailcow, after confirming terms | mailcow's maintainer suggests support contracts through Servercow. Ask Mailu's maintainers or a third party about paid support. |
| Host is an LXC container or NAS device | Mailu, after confirming platform support | mailcow does not support LXC, OpenVZ or NAS devices such as Synology and QNAP. Confirm Mailu's supported hosts. |
| Team wants no groupware and no tracker in the stack | Mailu | Mailu includes no tracker and does not ship unrelated groupware features, so the stack stays focused on mail. |
| Team needs antivirus scanning and anti-spoofing controls | Either, after checking settings | Both offer antivirus scanning. Mailu lists greylisting and DMARC and SPF checks. Confirm mailcow's antispam settings match your policy. |
How mailcow and Mailu are built and what that means for operations
mailcow and Mailu both ship as Docker images, but they split the work differently. The choices below shape how much memory you provision, how upgrades roll out, where you look first when mail stops flowing, and how many moving parts your team has to watch.
mailcow runs one container per service
mailcow starts a separate container for each component, including Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB, Redis, Nginx, Unbound, Olefy and an ACME client. Each service can be inspected and restarted on its own, which helps troubleshooting, but the stack is larger and needs more memory. Ask which containers you can disable, such as ClamAV and full-text search through the SKIP_CLAMD and SKIP_FTS settings, and test the effect on your mail flow before production.
Mailu ships a set of Docker images
Mailu is delivered as a set of Docker images, with configuration files, Dockerfiles and code under the MIT license. The footprint is leaner than mailcow's, but your team still manages each image version, its volumes and its environment settings. Before you commit, confirm which optional services you need, such as antivirus, and how each one is enabled in the release you plan to run.
Mailu routes traffic through a front container
Mailu uses a central front container that routes both HTTP and mail traffic to the other services. That gives you one entry point to monitor, certificate handling and port exposure in one place. The trade-off is that a fault or misconfiguration in the front container affects web access and mail at the same time, so check its logs and health first when either one fails.
Kubernetes guides for Mailu
Mailu's documentation includes Kubernetes setup guides alongside its Docker Compose guide. If your platform team already runs clusters, this lets mail follow the same deployment, storage and secret patterns as other services. Confirm that your cluster skills, storage class and ingress setup match the guide you follow, and keep in mind that the operating burden of a cluster falls on your team.
mailcow is Docker-only
mailcow's system requirements describe a Docker-based install on supported Linux distributions, and it does not support OpenVZ, Virtuozzo, LXC or NAS devices such as Synology and QNAP. Your team will not be running mailcow on a Kubernetes cluster from its documented path, so plan for a dedicated Docker host. Check the distribution list before choosing your base image and host.
Troubleshooting and moving parts
With mailcow, you watch about a dozen containers, each with its own logs, and failures often show up in one service while the cause sits in another, such as Rspamd or Unbound. With Mailu, you watch fewer images but rely on the front container and on the configuration you set for each service. Ask each vendor for its supported upgrade path and rollback steps, and test both on a copy of your data.
Feature and requirement comparison: mailcow against Mailu
This table compares mailcow and Mailu on license, groupware, sizing, platform support, ports, antispam, release cadence and optional components. Read the rows as a checklist: where a cell says to confirm, check that item in each project's current documentation before you commit to a design.
| Capability | mailcow | Mailu |
|---|---|---|
| License | GPL-3.0 (mailcow-dockerized), maintained by The Infrastructure Company GmbH | MIT for configuration files, Dockerfiles and code, per its README |
| Groupware | SOGo groupware bundled as a container | None bundled; its stated scope excludes unrelated groupware features, so plan a separate calendar and contacts service if you need one |
| ActiveSync support | Supported through the SOGo stack; confirm the exact client and version matrix in the mailcow documentation | Not in the supplied facts; confirm in the Mailu documentation before relying on it |
| Minimum RAM | At least 6 GiB plus 1 GiB swap in the default configuration; 8 GiB suggested for about 5 to 10 users | Not in the supplied facts; confirm current memory guidance in the Mailu general documentation |
| Disk baseline | 20 GiB excluding email storage | Not in the supplied facts; confirm in the Mailu documentation |
| Supported operating systems | Debian 11 to 13, Ubuntu 22.04 or newer, AlmaLinux 8 and 9, Rocky Linux 9; no OpenVZ, Virtuozzo, LXC or NAS appliances | Delivered as Docker images; confirm host OS and container runtime support in the Mailu docs |
| Required incoming ports | 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443 | Confirm the port list for your chosen deployment in the Mailu documentation |
| Antispam | Rspamd, with ClamAV and Olefy in the stack | Auto-learning, greylisting, DMARC and SPF checks, and anti-spoofing |
| Antivirus | ClamAV, which can be disabled with SKIP_CLAMD to save memory | Antivirus scanner included; confirm the engine and how to disable it |
| Let's Encrypt | ACME client container for Let's Encrypt certificates | Let's Encrypt certificates supported, per its README |
| Full-text search | Can be disabled with SKIP_FTS to save memory | Not in the supplied facts; confirm in the Mailu documentation |
| Kubernetes guides | Not in the supplied facts; confirm current guidance in the mailcow documentation | Docker Compose and Kubernetes setup guides in its general documentation |
| Latest release cadence | Date-based releases; 2026-09a published October 6, 2026 | Release 2024.06.64 published October 15, 2026, continuing the 2024.06 series |
What the licenses allow and what is paid for
The mailcow-dockerized repository is released under the GNU General Public License version 3.0, a copyleft license. The license governs what you may change and how you may pass modified code to others. It does not by itself create a fee. The project is managed and maintained by The Infrastructure Company GmbH, and its README suggests support contracts through Servercow.
- Copyleft scope: GPL-3.0 applies to the mailcow code. If you distribute a modified build outside your organization, you take on the license's source availability duties. Have counsel confirm how those duties apply to internal-only changes.
- Maintainer: The Infrastructure Company GmbH manages and maintains the project. Ask it about its release plans and how it handles security fixes for your version.
- Support route: The README suggests support contracts through Servercow. Ask Servercow what is covered, what response times it commits to and what it charges, because none of these terms appear in the supplied material.
- Commercial tiers: No paid edition or feature tier for mailcow appears in the supplied material. Confirm with the maintainer whether one exists before you assume the community code is the whole offer.
Before you budget, read the current README and any support terms, since commercial arrangements can change.
Mailu's configuration files, Dockerfiles and code are licensed under the MIT license, a permissive license with light conditions on redistribution. The project's README says all components are free software compatible with the MIT license, and it aims not to ship proprietary software or unrelated groupware features. Mailu also accepts outside contributions, so fixes your team needs can be proposed upstream. The Mailu repository is the place to verify these terms.
- MIT scope: Configuration, Dockerfiles and code carry MIT terms. You may modify and redistribute them, provided you keep the copyright and license notice in copies you distribute.
- Component compatibility: The README states that all components are MIT-compatible free software. Check the license of each container image you pull into your own software inventory, because your compliance record depends on the images you actually run.
- No bundled proprietary code: The project states that it does not ship proprietary software and advertises no tracker. Confirm this against the release you deploy, since a statement in a README does not replace your own review.
- Contributions: Outside contributions are accepted, so a patch your team writes can go upstream. Ask the project how it reviews and merges changes if you depend on a specific fix.
- Commercial tiers: No paid edition or support tier for Mailu appears in the supplied material. Ask the project directly whether a contract-backed support service exists.
Request written confirmation of any commercial support offer and the license of each third-party image in your deployment.
The mailcow name is a registered word mark of The Infrastructure Company GmbH, as stated in the project README. The GPL-3.0 license covers the code, while trademark law governs how the name may be used. A code license alone does not automatically grant you the right to use the name for a service you sell or for a fork you rebrand. Mailu's supplied material does not mention a comparable mark, so do not assume the same rules apply to it.
- Registration: The word mark is registered to The Infrastructure Company GmbH. Treat the name as owned property when you write policies, contracts or public materials.
- Code versus name: The GPL governs the code, and the mark governs the name. Ask the owner whether internal use, a modified build or a hosted offering needs permission.
- Forks and rebranding: A modified build that keeps the mailcow name may need a different name. Request the owner's written policy before you ship a fork under any name that resembles the product.
- Internal documentation: Use the product name accurately in runbooks, change records and procurement files so that auditors and counterparties see what you actually deployed.
Get the trademark usage terms in writing before you brand any service, product or managed offering around mailcow.
Neither project's supplied material includes a paid edition, a support tier or a service level agreement. Running either suite still carries costs regardless of license: your staff time, the servers that host the stack, backups and any third-party support you decide to buy. The license sets what you may change, while support terms determine what you can buy and what it covers. Each cost depends on different parties, so the quote you request should separate them.
- One-time costs: Deployment, initial configuration, migration of mailboxes and the first security review are usually one-time work. Ask any provider to itemize them separately from recurring work.
- Recurring costs: Hosting, patching, certificate handling, monitoring and any support contract recur. Ask whether support pricing is per year, per month or per incident.
- Who is paid for what: Servercow is the named support route for mailcow, while Mailu's support route is not stated in the supplied material. Identify each party that bills you and what it covers.
- What drives cost up or down: User count, mailbox volume, the number of domains and the amount of custom integration all change effort. Ask providers to price against your stated scope.
- What to request in a quote: Written scope, response expectations, upgrade handling, exit assistance and the license terms of any component you will run.
Ask each vendor or project to confirm its current commercial terms in writing before you compare totals.
What drives the running cost of each mail server
The running cost of either mail server is mostly set by the host you size for it, the storage you add for mail, and the hours your operator spends on upgrades and monitoring. For mailcow, the published baseline is at least 6 GiB of RAM plus 1 GiB of swap in its default configuration, with 20 GiB of disk excluding email storage, according to its system requirements page. Those figures set the floor for the instance, and the vendor's own guidance steps the recommended memory up as user counts and ActiveSync load grow. Mailu's documentation does not give a comparable memory table in the material supplied for this page, so confirm its sizing for your user count and antispam profile before comparing instance prices.
Costs fall into two groups. One-time costs include planning, the migration of existing mailboxes, and the DNS and certificate work that every mail domain needs before go-live. Recurring costs include the hosting itself, storage growth, patching, monitoring and any support contract. A mailcow deployment carries more containers to patch and watch, since Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB and Redis each run as their own service. Mailu also runs as a set of images behind a front container, so the operator still owns the patch cycle. Ask who applies upstream image updates and how often, because that effort recurs for the life of the server. Support is the other recurring line. mailcow's project notes that its maintainer suggests support contracts through Servercow, while Mailu's support depends on the open community and any arrangement you make separately. Antispam and antivirus capacity can add memory and CPU, so price ClamAV and full-text search as an explicit part of the sizing, not an afterthought.
DeployOpen does not publish a price list. A quote follows from written scope, and most engagements are fixed-scope. Before you request one, ask for memory and disk sizing for your user count, with the assumptions behind it, including whether ClamAV and full-text search stay enabled. Ask for the upgrade window and how rollbacks are handled, the monitoring and backup approach, and who responds to incidents at each severity level, including out-of-hours coverage. Ask which items are one-time and which recur, and whether ongoing support, upgrades and testing are priced as a retainer. A written scope with these answers lets you compare the two stacks on equal terms.
How to move mailboxes from one platform to the other
This sequence moves mailboxes, aliases and domains between mailcow and Mailu while keeping mail flowing during the switch. It ends with the old stack decommissioned and every client pointed at the new server. The exact work depends on mailbox sizes and client mix, so confirm migration tooling with each project before you commit.
Inventory domains, mailboxes and aliases
Export a list of every domain, mailbox, alias, forwarding rule, sender allowlist and admin account from the source stack. Record which users rely on SOGo calendars, contacts or ActiveSync phones, because those data sets do not move with plain mail. Note the mailbox sizes and the client mix (desktop IMAP, mobile, webmail) so you can estimate transfer and retesting work. The step is done when you have a written inventory that the team has reviewed and signed off.
Confirm migration tooling with both projects
Ask the mailcow and Mailu maintainers, through their documentation, repositories or community channels, which migration methods they support for their current releases. Confirm whether IMAP sync tools are recommended, whether any export of groupware data is possible, and how aliases and DKIM keys are handled. Record the answers and the versions you tested. The step is done when the chosen method is documented and both projects' versions are fixed for the migration.
Provision the target and run in parallel
Build the destination stack on its own host using the target's documented setup, either Docker Compose for Mailu or the mailcow installer, with the same domains configured but not yet receiving live mail. Copy mailboxes across with your chosen IMAP sync method and repeat incremental syncs until the delta is small. Reissue certificates for the new hostnames where needed, and rebuild DKIM keys and DNS-driven settings on the target. The step is done when test mailboxes on the new server match the source for message counts and folder structure.
Rebuild groupware and device pairings
Recreate calendars, contacts and any other SOGo data on the target through an export and import path you have confirmed, or plan for users to re-enter them. Re-pair ActiveSync phones against the new server, since device pairings tied to the source stack do not carry across. Rebuild admin configuration, such as spam policies, quotas and delegated admin roles, from your inventory. The step is done when each user group has tested its calendar, contacts and phone sync on the target.
Cut over DNS and mail routing
Lower the TTL on your MX, autoconfig, autodiscover and web records ahead of the change, then update them to the target server during a window agreed with the business. Verify SPF, DKIM and DMARC for each domain from outside your network and confirm the target accepts inbound mail on the required ports. Keep the source stack running and forwarding for a period you set in advance. The step is done when test messages arrive and send correctly for every domain.
Reconfigure clients and confirm delivery
Move each user's desktop, mobile and webmail clients to the new server settings, and update any applications that send mail through the old SMTP host. Watch delivery logs and the source stack's queue until mail for each domain arrives at the target without bounces. Collect feedback from a sample of users in each client group before you release the old service. The step is done when all groups report working mail and no mail is still arriving at the source.
Decommission the source stack
Take a final backup of the source stack, including mail storage, databases and configuration, and store it under your retention policy. Stop the old containers or Kubernetes workloads, remove stale DNS records and revoke any API tokens and admin accounts that belonged to the old platform. Update your documentation, runbooks and monitoring to reflect only the new stack. The step is done when the backup is verified, the old endpoints no longer respond and the records in your inventory are closed out.
Where mail server implementation projects usually run long
Mail server projects rarely run long because of the software install. They run long on the work around it: a reverse DNS record that the hosting provider has not set, port 25 blocked by default on the network, and SPF, DKIM and DMARC records that go live in the wrong order. Before either platform is installed, confirm in writing who controls the PTR record, whether outbound port 25 is open from the host, and which IP addresses will send mail. For mailcow, the host also needs incoming TCP ports 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443, and at least 6 GiB of RAM plus 1 GiB of swap in its default configuration. Sizing for the team, not the minimum, is a decision to make early.
The most expensive overruns come after go-live. Deliverability problems, such as a new sending IP landing on a blocklist or Gmail and Microsoft rejecting mail for failed DMARC alignment, can consume more time than the build itself, and they depend on warm-up and monitoring that no installer does for you. On mailcow, ActiveSync device testing is a common source of slippage: each phone client, from native mail apps to third-party clients, needs its own onboarding pass against SOGo. On Mailu, the Kubernetes path adds ingress, persistent volume and network policy work around the front container, which is often where a small team loses weeks. Ask any implementation partner to write down which device list and which Kubernetes assumptions are in scope.
The cost of the first upgrade cycle is the item most often missing from the original plan. Mailcow publishes date-based releases, such as 2026-09a, so upgrade planning means checking each release note against your customizations and backups. Mailu publishes numbered releases in the 2024.06 series, so the question is how far behind your deployment already is. A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts, so DNS and deliverability validation, device testing, and one scheduled upgrade rehearsal can be named as deliverables rather than discovered mid-project. Ask for those items explicitly in the written scope.
Questions buyers ask before choosing or hiring help for mailcow or Mailu
What does it cost to run mailcow or Mailu each month?
Neither project charges a license fee for the core suite, so the recurring cost is infrastructure, staff time and any paid support you choose. For mailcow, the supplied system requirements set a floor of at least 6 GiB of RAM plus 1 GiB of swap, with 8 GiB suggested for about 5 to 10 users and 16 GiB for a company with 15 ActiveSync phones and about 50 concurrent IMAP connections. Mailu's requirements depend on the services you enable and your deployment target, so confirm sizing against the Mailu documentation for your setup. Ask any provider for a quote that separates one-time setup, recurring hosting, monitoring, upgrades and support hours.
How much time does a mailcow or Mailu deployment take?
No duration is given here, because the effort depends on the variables that drive it: how many domains and mailboxes you host, whether you migrate existing mail and archives, how much DNS and certificate work is involved, and whether you need ActiveSync, antispam tuning and backups configured to your policy. Mailcow's larger container stack and its per-application components add more to test and monitor than Mailu's leaner images. Ask for a written scope with named deliverables and a timeline before work starts, and check whether migration is included.
Can an internal team run mailcow or Mailu without outside help?
Yes, if the team already runs Docker or Kubernetes in production, understands mail flow, and can own DNS, TLS, backups and incident response. Mailcow's documentation and its maintainers' support options cover much of the routine work, while Mailu's guides cover Docker Compose and Kubernetes. The gap usually appears during deliverability problems, blocklist removal, upgrades that touch several containers, and restores. Decide in advance who has on-call responsibility for mail, and whether that person can read Postfix, Dovecot and Rspamd logs.
What does the work need from our side before it starts?
Plan to provide administrative access to your DNS zone, a host or cloud account that meets the platform's OS and port requirements, proof that you own the mail domains, and a user list with aliases, groups and mailbox sizes. Mailcow requires incoming TCP ports 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443, and it supports specific Debian, Ubuntu, AlmaLinux and Rocky Linux releases, so confirm your host against its system requirements page. Also agree on who approves firewall changes, certificate issuance and the cutover window.
Do mailcow's RAM figures suit a small team?
For a small team of roughly 5 to 10 users, mailcow's own guidance points to 8 GiB, and its default configuration needs at least 6 GiB plus swap. If the host is tight on memory, mailcow documents that ClamAV and full-text search can be disabled with SKIP_CLAMD and SKIP_FTS, but that removes antivirus and search features you may need, so weigh that trade-off before you change it. A small team that adds ActiveSync phones or many concurrent IMAP sessions should size up. Test on a staging host with your real mailbox count before you commit.
Does Mailu suit an environment that only runs Kubernetes?
Mailu can fit a Kubernetes-only environment because its documentation includes a Kubernetes setup guide and describes a central front container that routes HTTP and mail traffic. Confirm how the mail ports, persistent volumes, certificates and the front routing map onto your ingress and load balancer, since mail protocols do not behave like typical web traffic. Check whether your cluster policies allow the required mail ports and outbound reputation work. If your platform team has no Docker experience, budget for learning the Compose and Kubernetes layouts before production.
What does a support contract change, and what does it leave unchanged?
A support contract changes who answers when something breaks and how quickly you get help with upgrades, but it does not change the software license or the work of running your mail. Mailcow's maintainers point to support through Servercow, and Mailu accepts outside contributions and is free software, so ask each option what is covered, response expectations, upgrade assistance and whether migration or incident work is billed separately. Ask for the terms in writing and confirm which tasks remain your team's responsibility.
How DeployOpen helps teams choose, implement or migrate a mail server
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, so a mailcow or Mailu deployment runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- We confirm which mail stack fits your domains, user count, groupware needs and ActiveSync requirements before any build begins.
- The written scope names the host OS, RAM and disk sizing, required inbound ports and whether ClamAV and full-text search stay enabled.
- We agree whether migration from an existing mail system, DNS and DKIM changes, and cutover testing sit inside the fixed scope.
How we build
- We install the chosen suite on your infrastructure, configure its containers, TLS certificates and outbound DKIM, SPF and DMARC records.
- We set up admin delegation, anti-spam and antivirus policy, and webmail or groupware access to match your access model.
- We test mail flow, deliverability checks and client connections against the documented requirements before go-live.
How we hand over
- You receive documentation of the deployed configuration, DNS records, port mappings, backup and restore steps and admin procedures.
- We walk your administrators through routine tasks, including how to apply the suite's release updates and what to check afterward.
- Acceptance follows the deliverables listed in the written scope, so you know exactly what was handed over and tested.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so your team does not have to track every release alone.
- Retainers can cover scheduled upgrades to new releases, backup verification and periodic security testing of the mail service.
- Ask for the support scope, response expectations and upgrade cadence in writing before you sign, since these vary by agreement.
