Dovecot Community Edition vs Dovecot Pro

Feature split between Dovecot Community and Dovecot Pro

This table compares the IMAP scaling features that Dovecot 2.4 Community Edition removed against what Dovecot Pro offers, along with support and license terms. Read each row as a question to put to the vendor, since exact Pro feature lists are not publicly itemized in the sources we reviewed.

How licensing, support and updates differ by edition

The free and paid Dovecot lines differ on who licenses the code, who supports it and who answers when something breaks. The cards below separate those questions so you can check each one against your own obligations and a written Pro quote.

How the Palomar architecture replaces Director

Which edition fits which mail platform

What each Dovecot path costs to run

This table breaks down who gets paid for what under Dovecot Community Edition and Dovecot Pro, and which costs are one-time or recurring. Read it as a checklist for building a like-for-like estimate, since the free edition's software cost is only part of the total. Dovecot Pro pricing is not published, so the main takeaway is that the quote request must state the scale, storage design and support expectations.

Moving from Dovecot Community to Dovecot Pro, or back

This sequence turns a list of removed Dovecot 2.4 features into a tested, vendor-confirmed cutover plan, so the team knows which workloads move, what replaces them, and what is lost if the platform later returns to the Community Edition.

1. Inventory removed features in use

   The mail platform team, working with the people who run the Dovecot servers, lists every place the current deployment depends on features that Dovecot 2.4 removed from the Community Edition: the replicator, Director architecture, the fts-lucene or fts-squat full-text search plugins, and any scripts or cron jobs that call the dsync symlink. Check configuration files, systemd units, monitoring checks and backup jobs, not only the main config. The output is a written inventory with one row per feature, the host or cluster it runs on, and the owner. Done when every row has an owner and nobody can name a removed feature that is absent from the list.

2. Map each feature to its documented replacement

   For each inventory row, the team records the replacement that Dovecot's 2.3 to 2.4 upgrade guide documents: NFS or another shared filesystem in place of the replicator, Lua Director as an unsupported small-scale option or the Palomar architecture in Dovecot Pro in place of Director, fts-flatcurve or fts-solr in place of fts-lucene and fts-squat, and doveadm sync or doveadm backup in place of the dsync symlink. Note where a replacement changes behavior, such as search index rebuilds or storage layout, and who must approve that change. The output is a mapping table signed off by the platform owner. Done when every removed feature has a replacement or a documented decision to drop it.

3. Confirm Dovecot Pro scope in writing

   If the destination is Dovecot Pro, the buyer asks the vendor, Dovecot Pro, which architecture components, cluster design, support terms, and long-term support commitments apply to the mapped workload. Dovecot Pro is sold by a company that is part of Open-Xchange, and its home page cites dedicated vendor support and proactive updates but publishes no prices, so ask for the scope, the license terms and the migration assistance in writing. Ask whether migration support is included or separately billed, and what recurs after go-live. Done when the signed scope names the Palomar components, the support level, the migration responsibilities of each party, and the fees, which are one-time and which are recurring.

4. Build a staging cluster that mirrors production

   The infrastructure team builds a staging environment with the same Dovecot version family, storage backend, search plugin, authentication source and client mix as production, using a copy or representative sample of mailboxes. Shared storage is exercised over the same NFS or shared filesystem layout planned for production, and the team confirms that the Community or Pro package is installed from the vendor channel the organization will support. The output is a runbook that lists exact versions, config diffs and host roles. Done when the staging cluster passes a basic login, delivery and search test with production-like data volumes.

5. Test migration, search and recovery on staging

   The team runs the mapped migration on staging using doveadm sync or doveadm backup where data moves between instances, rebuilds full-text indexes with the new search plugin, and tests failover by taking one node out of service. Compare mailbox counts, message flags, folder structure and search results against the source, and sample client behavior from IMAP and mobile clients. Record the rollback steps and time them against the cutover window the business has agreed. Done when reconciliation reports show no unexplained differences and a rollback has been rehearsed successfully at least once.

6. Freeze, sync and cut over production

   The team announces a maintenance window, stops new writes or drains connections as the runbook requires, runs the final incremental sync, switches the load balancer or DNS to the new cluster, and verifies IMAP and POP access, delivery through the MTA, and search from a sample of accounts. Keep the old system read-only and intact until verification is complete. The output is a signed cutover record with timestamps, the reconciliation results and the named owner of each check. Done when every verification item is ticked and the old system is retained for the agreed rollback period.

7. Document the post-cutover state and the way back

   After cutover, the team updates architecture diagrams, backup and restore procedures, monitoring thresholds and the support contacts, and removes the removed-feature references from configuration. If the organization later moves back to the Community Edition, it should plan for losing the Palomar design and the vendor support that came with Dovecot Pro, and it should replace clustered features with the shared filesystem and tooling the Community Edition supports. Ask the vendor whether it provides migration support in either direction. Done when the runbook, the support matrix and a written return-path assessment are filed with the platform owner.

Questions buyers ask before choosing Dovecot Pro or staying on Community

Where to confirm edition details before you decide

This sequence checks what the free Dovecot release has dropped, which version is current, what the license allows, and what Dovecot Pro includes. The output is a written record of confirmed facts and open questions that a quote can be measured against.

1. Review removed features in the upgrade guide

   The mail engineer responsible for IMAP reads the Dovecot 2.3 to 2.4 upgrade guide line by line against the current configuration. Check every use of the replicator, Director, fts-lucene, fts-squat and the dsync symlink, and note the replacement the guide names for each. Done means a written list that maps each affected setting to its replacement, with any setting that has no replacement flagged for the architecture review.

2. Confirm the current Community Edition release

   The platform lead checks the dovecot/core releases page to confirm which Community Edition version is the newest. The researched record shows Dovecot Community Edition 2.4.5 published on August 28, 2026, so confirm whether a later release has appeared since then. Done means the target version is recorded with its publication date, and the team knows which release notes to read before any upgrade.

3. Check license terms in the COPYING file

   Legal or compliance staff read the COPYING file in the dovecot/core repository to confirm the license split. The file places the src/lib, src/auth and src/lib-sql code under MIT and the remaining code under LGPLv2.1 unless a file says otherwise. Confirm how this applies if you modify or redistribute Dovecot inside your own service packages. Done means a short memo states the license for each component you ship and names any files that need a separate review.

4. Compare Dovecot Pro scope on its site

   The procurement lead and platform owner review the Dovecot Pro site to identify what is offered beyond the Community Edition. The site describes a highly available, cluster-ready Palomar architecture, dedicated vendor support, long-term support and proactive updates. The home page publishes no prices, so note every feature claim as something to verify in writing. Done means a feature list with a column for each claim marked as confirmed, unconfirmed or excluded from the offer.

5. Test replacement components in a lab

   The mail operations team builds a non-production environment that uses the replacement components named in the upgrade guide, such as shared storage for replication, fts-flatcurve or fts-solr for search, and doveadm sync or doveadm backup for data movement. Measure failover behavior, search results and mailbox migration on a copy of realistic but non-production data. Done means a signed test report lists which replacements met your requirements and which gaps remain.

6. Get scope and license terms in writing

   The decision owner requests a written quote and a scope document from Dovecot Pro, using the confirmed and unconfirmed items from earlier steps as the checklist. Ask for the included features, support hours and response commitments, long-term support terms, license conditions and any items billed separately. Done means the vendor's written answers are filed with the architecture report, and no decision is recorded until each open item has a documented answer.