mailcow vs Mail-in-a-Box

mailcow-dockerized is licensed under GPL-3.0 and is managed and maintained by The Infrastructure Company GmbH. Its README suggests that organizations seeking support contracts look to Servercow. The license governs what happens when you copy, change or hand the software to someone else. Running mailcow for your own staff, with changes you make yourself, carries no license fee. Conveying modified copies outside the organization is where the obligations start.

• Running and modifying: You can run, study and change the code for internal use without paying a license fee.
• Redistribution: Giving modified copies to outside parties, including a contractor who operates the stack for you, can trigger GPL conveyance duties such as making corresponding source available.
• Support route: The README suggests support contracts through Servercow. The sources do not give prices or service levels, so ask for scope, response times and exclusions in writing.
• Word mark: mailcow is a registered word mark of The Infrastructure Company GmbH. The GPL does not grant trademark rights, so a fork or hosted service should not use the name without permission.
• Maintainer control: The Infrastructure Company GmbH drives the project's releases, such as the date-based 2026-09a published on October 6, 2026, so your upgrade plan depends on that maintainer's cadence.

Confirm with counsel whether your planned internal modifications and any contractor access fall within the license terms in your jurisdiction.

Mail-in-a-Box is released under the CC0-1.0 public domain dedication, listed in its GitHub repository. CC0 waives copyright to the extent the law allows, so there is no notice or attribution duty for a copy you change or redistribute. It does not grant patent rights and it disclaims warranties, so the operating risk of the machine stays with you. The project materials do not describe a paid edition or a commercial support plan, so buyers should confirm support options directly with the maintainers or with any third party offering help.

• Modification: You can change the scripts or configuration for internal use without any obligation to publish your changes.
• Redistribution: You can pass copies to others, and each recipient receives the same freedoms without a source-sharing duty.
• Patents: CC0 does not include a patent license, so ask counsel whether patent exposure matters for your team.
• Paid options: No paid edition appears in the project materials. Any hardening, consulting or support arrangement is a separate contract with a separate party.
• Warranty: Because CC0 disclaims warranties, nothing in the license promises a fix when your deployment fails.

Ask in writing who would fix a defect in your version and how quickly, since no license term makes that commitment for you.

The two licenses differ most when software leaves your organization. Under GPL-3.0, changes used only inside the company are generally not subject to publication duties, while passing modified copies to customers, affiliates or hosting partners can trigger source obligations. Under CC0-1.0, no source-sharing duty applies in either case. Both licenses leave trademark questions to separate rules, and both leave operating support to whoever you contract with.

• Internal changes: Under GPL-3.0, internal-only changes generally carry no publication duty. Under CC0-1.0, none applies either way.
• Shipping to others: A modified mailcow stack given to a customer or partner can start GPL conveyance duties. CC0-1.0 adds no equivalent duty.
• Combined works: GPL-covered code linked into your own program can extend copyleft to the combined work. Mail stacks usually run as separate components, so ask counsel to confirm where the boundary falls for your setup.
• Naming: The mailcow name is governed by trademark rules that apply separately from either license.
• Records: Keep a change log that records the exact upstream version, such as mailcow 2026-09a or Mail-in-a-Box v77 published on September 26, 2026, so you can show what you modified.

Ask counsel to review your intended use before you build the platform, especially if a service provider will operate it for you.

mailcow is sized by its documented memory guidance. Its default configuration needs at least 6 GiB of RAM plus 1 GiB of swap, and the project 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. It also needs 20 GiB of disk before email storage. Mail-in-a-Box runs on a single fresh Ubuntu 22.04 LTS machine, and its footprint is that one box plus the storage you give it. Hardware is usually a one-time purchase or a recurring cloud instance fee, so the instance size you pick sets the monthly bill.

• Memory sizing: mailcow's published tiers scale with user count and client type, so a mailbox count that grows past 10 users or adds ActiveSync devices moves you up a tier.
• Optional savings: SKIP_CLAMD and SKIP_FTS can disable ClamAV and full-text search to save memory, at the cost of antivirus scanning and search features.
• Single-machine limit: Mail-in-a-Box has no published multi-node layout, so growth means a larger machine rather than extra nodes.
• Storage growth: mailbox storage is separate from both footprints and grows with retained mail and attachments.

Ask providers and your own platform team to price the instance class, the disk size for mail retention and any backup storage, and to confirm the memory tier for your actual user and device count.

Most of the recurring cost is staff time. mailcow runs about a dozen containers, including Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB, Redis, Nginx, Unbound, Olefy and an ACME client, so an operator needs Docker and Compose skills, container log reading and a plan for updates. Mail-in-a-Box is a single configured Ubuntu system with Postfix, Dovecot, Roundcube, SpamAssassin, Nextcloud for contacts and calendars, Z-Push and its own nsd4 DNS server, so the work is closer to running one tuned server, with fewer moving parts but less room to change them.

• Container operations: mailcow staff spend time on image updates, volume backups and troubleshooting across services.
• Single-server operations: Mail-in-a-Box staff spend time on OS patching, the box's built-in admin tools and occasional repairs.
• Mail deliverability: both need someone who watches SPF, DKIM, DMARC and reputation, though Mail-in-a-Box sets those records automatically.
• Internal skills: a team already fluent in Docker will find mailcow familiar, while a team that wants changes beyond the defaults will find Mail-in-a-Box hard to adapt.

When you request a quote, ask who will be paid for daily operation, how many hours per month the vendor assumes, and whether handover includes runbooks your own staff can follow.

mailcow is GPL-3.0 and managed and maintained by The Infrastructure Company GmbH, which suggests support contracts through Servercow. That makes support a recurring contract you can buy, separate from the software itself. Mail-in-a-Box is released under CC0-1.0 with no vendor contract attached, so paid support, if any, comes from a third party you hire. Either way, the software is free to run, and the money goes to whoever keeps it working when something breaks.

• Vendor contract: mailcow support through Servercow is a recurring fee that you should confirm directly with the vendor, since the README only suggests it.
• Third-party services: DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms under a written, fixed scope, with ongoing support available as a retainer.
• Community support: Mail-in-a-Box depends on its public repository and releases, so the internal team or a hired partner carries the response load.
• Response expectations: no response times are published for either option, so ask for them in writing.

Before signing anything, ask each provider to state in writing what is covered, the response expectations, and whether the fee is one-time or recurring.

Upgrade cost depends on how often a platform changes and how much you have customized it. mailcow publishes date-based releases, with 2026-09a published on October 6, 2026, so upgrades are routine but frequent. Mail-in-a-Box publishes numbered releases, with v77 published on September 26, 2026, and its design discourages customization, which keeps upgrades simpler but limits what you can change. The cost difference is mostly in the custom work you add on top of the platform.

• Routine upgrades: mailcow updates are container image changes that need a test window and a rollback plan.
• Single-server upgrades: Mail-in-a-Box upgrades touch the whole machine, so plan a maintenance window and a full backup first.
• Customization cost: every change you make to mailcow, such as custom Postfix rules or extra containers, is work to re-check on each upgrade.
• Migration exit cost: moving mail to another platform later means exporting mailboxes, contacts and calendars, and that work grows with the amount of stored mail.

Ask for a quote that states the upgrade cadence the vendor expects, who tests upgrades, and what happens to custom changes during each release.