Mautic or listmonk: which fits your marketing operation
If your team needs multi-step campaigns, contact scoring and marketing operations, choose Mautic. If you mainly send one-way newsletters and high-volume list mail, listmonk is the lighter fit. Mautic is GPL-3.0 software written in PHP on Symfony and backed by MySQL or MariaDB, while listmonk is AGPL-3.0, ships as a single Go binary and uses PostgreSQL as its only dependency. Neither is a hosted service on its own, so you run the infrastructure either way.
Mautic is the better choice when campaigns branch across many steps, when you need contact scoring and segments that drive automated journeys, or when marketing operations must own those rules without writing code. Expect to run it on a VPS or dedicated server, since the project advises against shared hosting, and plan for the cron jobs that update segments and campaigns and trigger them, plus a messenger consumer when email is queued. listmonk is enough when the work is newsletters, opt-in list management, segmentation by SQL expressions and bulk campaigns, with transactional mail and OIDC single sign-on available when you need them.
The decision turns on three questions. First, whether your campaigns need logic across many steps or only a message to a list. Second, how much PHP, cron and queue operations your team can run and monitor over time. Third, whether sending infrastructure is already in place, because listmonk relies on SMTP servers or messenger webhooks you supply, and Mautic also needs a mail transport configured. Confirm each answer against your own environment before you choose, and ask any implementation partner to price the work from a written scope.
Which scenario points to Mautic and which points to listmonk
This table maps common scenarios to the platform that fits them better, with the reason tied to supplied facts about each product. Read each row as a starting point: where a fit depends on a feature the researched facts do not cover, the cell tells you what to confirm with the vendor before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Nurture program with branching logic and lead scoring | Mautic | Mautic runs contact-centric campaigns on segment and campaign updates driven by cron jobs, which suits multi-step journeys. Confirm the exact lead scoring and branching options for your version in the Mautic documentation. |
| Single monthly newsletter with double opt-in | listmonk | listmonk manages single and double opt-in lists and sends through multi-threaded queues. A one-way newsletter does not need Mautic's campaign engine, and the smaller footprint is easier to run. |
| Transactional templates sent by an application | listmonk | listmonk offers a transactional mail API for pre-defined templates and sends through multiple SMTP servers with rate limiting. Confirm delivery guarantees and error handling against your own sending setup. |
| High-volume subscriber list with SQL-based segments | listmonk | listmonk lets administrators query and segment subscribers with SQL expressions on PostgreSQL, and the project reports large-volume sends on modest resources. Treat the project's own performance claims as a starting point and test with your own list size. |
| Sales team that needs CRM sync and contact-level activity | Mautic | Mautic publishes HubSpot and Salesforce plugin documentation, which listmonk's facts do not cover. Confirm the current sync direction, field mapping and plugin support in those vendor docs before committing. |
| Campaigns that must sit inside a lead lifecycle with scoring and sales handoff | Mautic | Mautic's contact model and campaign engine fit lifecycle programs, but it needs cron jobs staggered and a messenger consumer when emails are queued. Budget operator time for those jobs. |
| Single-binary operations with PostgreSQL as the only dependency | listmonk | listmonk ships as a standalone binary with PostgreSQL as its only dependency and a published Docker image. Mautic requires PHP, MySQL or MariaDB, a web server and a VPS or dedicated server, so its footprint is larger. |
How each platform is built and what that means for operations
Mautic and listmonk take very different paths to the same goal of sending email to a list. Mautic is a multi-component web application with scheduled jobs, while listmonk is one binary with one database dependency, so the work you take on differs in patching, monitoring and the number of moving parts.
Mautic is a PHP application stack
Mautic is written in PHP on the Symfony framework and needs MySQL with InnoDB or MariaDB, a web server (Apache, Nginx or IIS), and npm from version 5.0 onward. Each layer has its own patch cycle, so your team owns PHP, database, web server and Node tooling updates. Check that your runtime versions match the Mautic release you plan to run, because the supported PHP range changes between major releases. Ask your implementation partner to document which component versions are pinned and who patches each one.
Mautic avoids shared hosting
The Mautic project states that it should not run on shared hosting and recommends a VPS or dedicated server instead. This shapes the hosting decision before any feature is compared, because a shared plan that suits a small website will not run Mautic reliably. Budget for a server you control, with root access for patching and the cron schedule. Confirm the exact sizing with your infrastructure team against your expected contact volume, since the project's documentation does not give a single sizing figure.
Mautic runs on scheduled jobs
Segment updates, campaign updates and campaign triggers run from cron jobs that the documentation says should be staggered. Mautic also needs a broadcasts command for segment emails and a messenger consumer when email is queued. If a cron job stops or a consumer crashes, campaigns silently stop progressing, so monitoring must check job health, not only web uptime. Ask for the exact job list and alerting design in writing.
listmonk is one binary
listmonk ships as a standalone binary with PostgreSQL as its only dependency, built with a Go backend and a Vue frontend. There is no PHP runtime, no Node tooling in production and no separate scheduler to keep running for campaigns. Patching means replacing the binary and applying its database changes, which leaves fewer components to track. Confirm the upgrade steps for each release in the project's documentation before scheduling a maintenance window.
Container deployment with sample compose
listmonk publishes a Docker image on Docker Hub and a sample docker-compose.yml in its repository, which gives a fast path to a test environment. Production still needs decisions about PostgreSQL backups, TLS termination, secrets handling and where the container runs. Treat the sample file as a starting point and review its defaults with your security team before using it outside a lab.
Sending path and rate control
listmonk sends through multi-threaded queues across multiple SMTP servers with rate limiting, and its messengers deliver SMS, WhatsApp and push through HTTP webhooks. Mautic sends through its own queue and messenger consumer, so the send path depends on that worker staying healthy. Ask both vendors how bounce handling, sending domains and IP warm-up are configured in your environment, because deliverability problems usually surface in the sending path rather than in the application.
Which capabilities the supplied facts support on each side
This table sets Mautic's full marketing automation against listmonk's newsletter manager row by row, stating a cell only where the researched facts support it. Where a capability is not documented in our sources, the cell says what to confirm, so treat those as checklist items rather than gaps in either product. Read it as a shortlist filter: the rows where the two products differ most are usually the ones that decide the choice.
| Capability | Mautic | listmonk |
|---|---|---|
| License | GPL-3.0 for the GitHub repository. No paid edition of the software itself. | AGPL-3.0. Free to self-host as a single binary. |
| Language and stack | PHP on the Symfony framework. Requires Apache, Nginx or IIS and npm from Mautic 5.0 onward. | Go backend with a Vue frontend, distributed as a standalone binary. |
| Database | MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. | PostgreSQL as its only dependency. |
| Contact model and opt-in | Contact-centric records with campaigns and segments. Confirm the exact data model in Mautic documentation. | Subscribers on single and double opt-in lists, managed at scale. |
| Segmentation | Segments are updated by a scheduled cron job. Confirm filter options in Mautic documentation. | Subscribers queried and segmented with SQL expressions. |
| Campaign builder and triggers | Campaigns run on cron jobs for segment updates, campaign updates and triggers, which should be staggered. | Campaigns are sent from lists. Confirm whether multi-step journeys exist before relying on them. |
| Lead scoring | Confirm lead scoring rules and their configuration in Mautic documentation. | Not documented in the supplied sources. Confirm with the vendor. |
| Templates | Confirm template editor options in Mautic documentation. | Go templating with more than 100 functions. Drag-and-drop, WYSIWYG, Markdown, raw HTML or plain text. |
| Sending model | Broadcasts command for segment emails and a messenger consumer when emails are queued. | Multi-threaded queues across multiple SMTP servers with rate limiting. Messengers for SMS, WhatsApp and push via HTTP webhooks. |
| Transactional API | Confirm in Mautic documentation. | Transactional mail API for pre-defined templates. |
| Analytics | Confirm reporting options in Mautic documentation. | Built-in analytics for campaigns, bounces and links. |
| SSO and access control | Confirm supported SSO options in the Mautic authentication documentation. | OIDC single sign-on with granular roles, permissions and API tokens. |
| CRM connectors | HubSpot and Salesforce plugin documentation is published. Confirm sync scope for your version. | Not documented in the supplied sources. Confirm before assuming a connector. |
| Hosting requirements | Not recommended on shared hosting. The project recommends a VPS or dedicated server. | One binary plus PostgreSQL, with a Docker image and sample compose file published. |
What the licenses and editions mean for each platform
Mautic is licensed under the GNU General Public License version 3 (GPL-3.0), and the license text sits in the project's repository. The software has no paid edition. The mautic.org site offers the free self-hosted download and separately promotes managed Mautic and Mautic hosting services, which are commercial arrangements with providers. The project describes itself as 100% community-owned with no commercial entity behind it, and the MAUTIC name is a trademark held by the Mautic project of the Open Source Collective.
- No license fee for the software. The code costs nothing to download and run. You pay for your own infrastructure, the people who install and operate it, and any managed service you choose.
- GPL-3.0 applies on distribution. Running Mautic inside your organization does not, by itself, require you to publish your changes. If you give modified copies to other parties, you must provide the corresponding source under GPL-3.0 and keep the license notices intact.
- Managed hosting is a separate purchase. A managed Mautic or hosting contract covers operations, not the license. Check what it includes, who holds the data, and how you would move off it.
- The trademark is held separately. Distributing a modified build under the MAUTIC name is a trademark question as well as a code question. Check the project's trademark guidance before you rebrand a build.
Confirm with your legal team whether any internal modifications could reach partners or customers, because that changes your obligations.
listmonk is licensed under the GNU Affero General Public License version 3 (AGPL v3). AGPL-3.0 keeps the GPL-style duties for distributed copies and adds a network-use clause: if you modify listmonk and let users interact with it over a network, you must offer those users the source of your modified version. The project ships as a standalone binary with PostgreSQL as its only dependency. The source and license are in the listmonk GitHub repository.
- Network use can trigger source obligations. Running an unmodified build for your own staff raises no such question. A modified build that subscribers, partners or internal users reach through a browser or API may, so record every change you make.
- Distribution carries the same duties. If you pass copies or a modified binary to another party, you must provide the source and keep the notices. Teams that embed listmonk in a product should review these terms early.
- Packaging does not change the license. The project publishes a Docker image and a sample docker-compose.yml, which reduce packaging work but leave the license terms as they are.
- Edition structure needs confirmation. The information available for this page does not describe a paid edition. Ask the project to confirm the current edition structure, including whether any features sit outside the open-source release, before you budget.
Check the license file and current releases in the repository before you commit to a version.
The obligations above are general descriptions to help you frame the question, not legal advice. Whether a deployment triggers source obligations depends on how you use, modify and distribute each component, and on how your contracts describe those activities. Your legal team should review the license text for every component you deploy, including plugins, templates and custom modules. The Mautic license text is a useful starting point for the GPL side.
- Internal use versus distribution. Map which parties receive copies of the software, which ones only use the running service, and which ones only read reports.
- Network access under the AGPL. List every user who interacts with a modified listmonk over a network, and decide how you will provide source to them.
- Modifications and forks. Record patches, templates and integrations so you can show what changed and where it came from.
- Trademark and branding. Check the MAUTIC trademark guidance before you describe a modified build by the project name.
- Edition and commercial terms. Get written confirmation of editions, support and managed service terms from the vendor or provider.
Bring the component list, deployment model and contract terms to the review so the answer reflects your actual setup.
What drives the running cost of each platform
The running cost of either platform is set less by the software license, which is free in both cases, than by who operates the components around it. For Mautic, the main recurring line is a VPS or dedicated server, since the project states that Mautic should not run on shared hosting. Add the MySQL (InnoDB) or MariaDB service, sending fees from an SMTP or transactional provider, and staff time for patching, cron jobs and the messenger consumer that handles queued email. For listmonk, the footprint is smaller: one binary and PostgreSQL as its only dependency, plus the same sending provider fees and staff time for upgrades and monitoring. Ask your team to confirm which of these components they already run and who pays for each. Mautic's cron and queue workers are the line most often missed in estimates.
Separate one-time costs from recurring ones. One-time work includes installation, template migration from an existing tool, contact import, opt-in and tracking setup, and integrations with a CRM. For Mautic, the HubSpot and Salesforce plugins are documented, so check whether the integration work is configuration or custom development. Recurring costs include hosting, sending volume, monitoring and upgrades. Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, and Mautic's stated cadence is monthly patch releases, minor releases every three months and major releases every two years. A team that applies monthly patches on a predictable window will spend less than one that upgrades only when a release becomes unsupported. listmonk's pace of releases and its version history should be checked against your own change process before you commit to a budget.
When requesting a quote, ask for a written component list with the hosting size, database service, SMTP or API provider, and each messenger channel in scope. Request the upgrade path for each major version, including who tests it and who performs the rollback. Ask who handles incident response for a failed cron run, a stuck queue or a sending block, and what response the provider commits to in writing. Ask for the cost split between one-time and recurring work and for the assumptions behind any sending volume. DeployOpen prepares these items in a fixed-scope written plan before work starts, so compare quotes against the same list.
How to move between Mautic and listmonk without losing history
This sequence moves contacts, consent and sending identity to the new platform while keeping a documented record of what was migrated, what was rebuilt and what stayed behind in the old system. Each step ends with a check that the next step can rely on.
Export and reconcile consent records first
Before moving any contact, the marketing or compliance owner exports consent status, opt-in source, timestamps and list membership from the current platform and compares them against the consent evidence held elsewhere, such as the web forms or CRM that captured it. Contacts whose consent cannot be traced to a source are flagged and excluded from import until someone decides how to treat them. The step is done when every contact in the export has a consent state and a recorded source, and the exceptions are signed off by the data owner. Confirm with each vendor which import formats and fields their current versions accept, because the supplied facts do not describe migration tooling for either platform.
Map lists, segments and custom fields
The platform owner maps each Mautic list, segment and custom field to its listmonk equivalent, or the reverse. Simple list membership usually maps to a listmonk list, while Mautic segments that depend on behavior, scores or campaign history need to be rebuilt as listmonk SQL segment expressions or as sends driven from the source system. Write the mapping in a shared sheet with an owner for each row, and mark anything that cannot be carried over as a rebuild item. The step is done when every segment has either a mapped target or a documented decision to rebuild it.
Move templates and sending identity into staging
The sending team recreates the email templates as content in the target platform, reviewing any Mautic tokens or listmonk Go template functions that need rewriting, and confirms the sending domain, SPF, DKIM and DMARC records, and SMTP settings that the new instance will use. Templates are treated as content to move, not as logic that carries over unchanged. A staging instance is configured with the same sending identity but a test domain or restricted recipient list. The step is done when a test message renders correctly in the target platform and passes the authentication checks the domain owner expects.
Rebuild automation logic and transactional wiring
Mautic campaigns, their cron-driven segment and trigger updates, and any scoring rules must be redesigned in the target platform, since listmonk does not provide Mautic's campaign engine or lead scoring as described in the supplied facts. The application team also updates any transactional mail calls so they point to the new API and templates. Import a sample of contacts into staging, run each rebuilt flow against them, and compare the results with what the old campaign produced. The step is done when the rebuilt flows match the expected behavior for the sample, and the differences are written down.
Test sends and bounce handling on staging
The operations team sends test campaigns to internal seed addresses and checks delivery, bounce classification, unsubscribe handling and link tracking in staging. They confirm that a hard bounce or unsubscribe in the target platform suppresses the contact as intended and that the suppression state is visible to anyone who later imports data. Results are logged per test with the message identifier and outcome. The step is done when each test scenario has a recorded pass or a documented fix, and the owner approves the cutover criteria.
Cut over the sending domain and freeze the old system
The team imports the final production contact set, switches the sending domain or subdomain to the target platform, and pauses sends from the old system to avoid duplicate or conflicting mail. The old platform is set to read-only or sends are disabled, and a dated export of its campaign reports and logs is saved. The step is done when production mail flows from the new platform, the old system has no active sends, and the cutover record lists the timing, the owner and the exported archives.
Retire the old system after the retention period
Once the retention period set by the organization's own records and privacy policy has passed, the team removes the old instance, its database backups and its stored personal data, and records the decision. Analytics history that cannot be imported stays in the archived export under the same retention rules. The step is done when the retirement is approved in writing, the deletion is logged, and the archive location and access rules are documented for auditors who may ask for them.
Where implementation projects usually run long
Mautic's effort concentrates in the server build and the scheduled work around it. The project supports installation from the production package with the web or command-line installer, or with Composer using the recommended project template, which has been the recommended path since version 4.0. Mautic 7.0 runs on PHP 8.2 through 8.5 and needs MySQL with InnoDB or MariaDB 10.2 or higher, and the project advises a VPS or dedicated server over shared hosting. Your team also schedules the cron jobs for segment updates, campaign updates and campaign triggers, which the Mautic cron jobs documentation says should be staggered, plus the broadcasts command and a messenger consumer once email queuing is enabled. Confirm with your platform team how these run under your process supervisor before go-live.
Integration with an existing CRM is where Mautic scope most often grows. The project publishes plugin documentation for HubSpot and Salesforce, and the real work sits in agreeing which objects sync, which direction each field flows and which system owns a contact record when the two disagree. Plan for consent migration as well: imported contacts need a documented opt-in record before a campaign can email them, and that evidence should be verified against the source system. Campaign and template rebuilds are the other common overrun. Segments, campaigns and email templates rarely transfer from a previous tool intact, so budget time to rebuild and test each journey end to end, including the cron-driven triggers that fire it. Ask any implementer to list these items explicitly in the written scope.
listmonk's footprint is smaller, but its long projects come from different places. The stack is PostgreSQL plus the listmonk binary or its Docker image, and the project publishes a sample docker-compose.yml to start from. Your team sets the SMTP servers, sending threads and rate limits, then tests them against your provider's throttling before a large send. Sender authentication, meaning SPF, DKIM and DMARC records for the sending domain, usually needs the most coordination with DNS owners and the marketing team. Messenger webhooks for SMS, WhatsApp or push need an endpoint and credentials for each channel. For single sign-on, listmonk supports OIDC with granular roles, permissions and API tokens, and designing those roles against your staff structure is worth settling early. Staff training on list and segment handling is the item teams most often leave out of the plan, and listmonk's documentation is the right starting point for the admin team.
Questions buyers ask before choosing or hiring help
How much effort does it take to run Mautic compared with listmonk?
Mautic takes more ongoing effort because it is a full PHP application with scheduled work behind it. Its documentation expects cron jobs for segment updates, campaign updates and campaign triggers, which should be staggered, plus a broadcasts command for segment emails and a messenger consumer when emails are queued. listmonk is a standalone binary whose only listed dependency is PostgreSQL, so its moving parts are fewer. The effort in both cases is driven by sending volume, the number of automations you run, how many people administer the system, and how much you customize templates or integrations. Ask your team to map every scheduled job and queue before deciding which platform fits.
Can our team install and operate Mautic or listmonk without outside help?
A team with Linux, web server, database and mail administration skills can install either platform itself, using the documented installers or Docker where listmonk is concerned. Operating them well is the harder part: patching on the vendor's release cadence, monitoring cron and queue health, managing bounce handling, and keeping sending reputation healthy. Mautic also needs a supported PHP and MySQL or MariaDB version, and its project says it should not run on shared hosting. Be honest about who holds these skills today and who covers them during an incident. Outside help is most useful for initial hardening, documentation and a handover that your staff can actually follow.
How long does a typical Mautic or listmonk implementation take?
We do not publish durations, and the timeline depends on the written scope. The main drivers are the number of integrations to connect (CRM, identity provider, data sources), how many lists, segments and campaigns must be migrated or rebuilt, the state of your data and consent records, the sending infrastructure you already have, and how many approval rounds your legal and security teams require. A listmonk newsletter deployment has a smaller surface than a Mautic campaign platform with lead scoring and CRM sync, so scope and timing will usually differ. Ask for a written scope with clear milestones and named acceptance criteria before work begins.
What do we need to provide for an implementation to start?
Name a business owner for marketing decisions, a technical owner for hosting and upgrades, and a privacy or legal owner for consent. The work also needs DNS access for sending domains, SPF, DKIM and DMARC records, and access to your SMTP or transactional sending provider. You should supply a list of consent sources and existing opt-in records, and confirm how unsubscribes must be honored. Most teams also need a staging environment that mirrors production, so templates, segments and automations can be tested before any live subscriber is contacted. Confirm each item in writing during scoping.
Can listmonk replace Mautic for our marketing campaigns?
Not for every team. listmonk is a self-hosted one-way newsletter and list manager with multi-threaded sending across SMTP servers, SQL-based segmentation, campaign analytics, a transactional mail API and OIDC single sign-on. Mautic covers contact-centric campaigns, lead scoring and multi-step automation. If your need is high-volume list mail with simple segmentation, listmonk may be enough. If you depend on scoring, branching journeys and rich contact timelines, listmonk does not cover that need. Confirm the exact automation, scoring and CRM sync requirements with the vendor and in a proof of concept before you decide.
Can Mautic run on shared hosting?
No. The Mautic project states that Mautic should not be installed on shared hosting and recommends a VPS or dedicated server instead. Its requirements also include PHP 8.2 to 8.5 for Mautic 7.0, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, a supported web server such as Apache, Nginx or IIS, and npm from Mautic 5.0 onward. Plan the hosting footprint, cron scheduling and queue processing from the start. Check the current requirements page before provisioning, since supported versions change between releases.
Which cost components should we request in a quote?
Ask for each component separately so you can compare options fairly. Typical items are discovery and architecture, installation and configuration, integrations with your CRM or identity provider, data migration and consent mapping, template and automation build, hardening and security testing, documentation, staff training, and handover. Separate one-time work from recurring items such as hosting, sending provider fees, monitoring, upgrades and support retainers. Ask what drives each line up or down, such as sending volume, the number of integrations or the number of environments. A quote should follow from the written scope.
Does DeployOpen sell Mautic or listmonk licenses?
No. Mautic is free software under GPL-3.0 with no paid edition of the software itself, and listmonk is licensed under AGPL v3. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Any hosting or managed service you buy from a vendor is a separate contract. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure. For Mautic vs listmonk, we start by testing which workload the team actually needs to run, then build and hand over only what that choice requires.
How we scope
- Written scope lists the campaign, segmentation and lead scoring needs that would point to Mautic.
- Volume, list count and sending needs are documented to show whether a list manager is enough.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Hosting footprint is planned in the client's cloud account, data center or air-gapped network.
- Mautic cron jobs, the broadcasts command and the messenger consumer are configured and checked.
- listmonk sending queues, SMTP servers and rate limits are set up and tested against the agreed volume.
How we hand over
- Installation, configuration and integration decisions are documented in a handover pack for the team.
- Identity settings, such as OIDC single sign-on for listmonk, are documented with roles and API token rules.
- Operators receive runbooks for upgrades, backups and scheduled jobs matched to the chosen release line.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade plans follow the vendor's published release and support windows, which the client can review.
- Security testing of the deployed platform can be scoped separately, with findings handed to the client's team.
