Mautic

Last reviewed Aug 26, 2026 · 828 words

Most self-hosted Mautic installs that "stopped working" have not broken; their cron jobs have. Segments stop updating, campaigns stop advancing, emails sit in a queue that nothing drains, and the web interface looks perfectly healthy the whole time. Mautic is a full marketing automation suite, about 10,400 stars and a decade old, and it is built around scheduled console commands rather than a resident worker. So the first thing to get right is a crontab, not a campaign.

Five cron entries, or nothing moves

The core loop is a handful of bin/console commands that must run on a schedule. On a bare-metal install the crontab for the web user looks like this:

*/5 * * * * php /var/www/html/bin/console mautic:segments:update
*/5 * * * * php /var/www/html/bin/console mautic:campaigns:update
*/5 * * * * php /var/www/html/bin/console mautic:campaigns:trigger
*/2 * * * * php /var/www/html/bin/console mautic:emails:send
0 * * * * php /var/www/html/bin/console mautic:broadcasts:send

Segments first, because campaigns pull members from segments; then update campaign membership; then trigger the actions; then send whatever landed in the queue. Get the order wrong and a new contact waits up to three cycles to receive the welcome email. Add mautic:import if you bulk-load contacts and mautic:webhooks:process if you queue webhooks.

The official Docker images make this explicit: the same mautic/mautic image runs in different roles, set by DOCKER_MAUTIC_ROLE, so a typical compose file has one mautic_web container, one mautic_cron and one mautic_worker, all sharing the same volume and database. That is three containers plus MySQL or MariaDB before you have sent a single email, and it is the correct way to run it.

Never send from the box itself

Mautic composes email; it should not deliver it. A home IP or a cheap VPS range has no sending reputation and a few thousand messages will land in spam or get the IP listed. Configure a transactional provider through the mailer DSN, which in current versions is a single MAUTIC_MAILER_DSN (or the mailer settings screen) pointing at SMTP or a provider API:

MAUTIC_MAILER_DSN=smtp://AKIA...:[email protected]:587

Amazon SES costs about $0.10 per 1,000 emails at last check, which is why it is the default choice for self-hosted senders. Whatever you pick, publish SPF, DKIM and DMARC on a dedicated sending subdomain such as mail.example.com, keep your main domain's reputation out of the blast radius, and wire the provider's bounce and complaint webhooks back into Mautic so it stops emailing dead addresses. If you are new to sending mail at all, the email category explains why nobody sane runs their own outbound MTA for marketing volume.

Two gigabytes is a floor, and MySQL is why

The catalogue says 2 GB minimum and Hard difficulty, and both are fair. PHP-FPM is light; the database is not. Every page view from the tracking script (mtc.js on your site) becomes a row in page_hits, every email open and click becomes a row, and a modest list with a busy website adds tens of thousands of rows a day. Give MariaDB its own memory budget (a 1 GB innodb_buffer_pool_size is a sensible start), put the data directory on SSD, and run mautic:maintenance:cleanup --days-old=365 monthly to prune old hit data. A 4 GB machine for Mautic plus its database is the size I would actually order.

Ask whether you need automation or a newsletter

Mautic's strengths are the things a newsletter tool cannot do: lead scoring, multi-step drip campaigns with branching, forms and landing pages that feed contacts straight into segments, and a REST API plus a plugin ecosystem that syncs contacts with CRMs. If your real need is "send a monthly email to 3,000 subscribers and see who opened it", that is a newsletter, and something like SendPortal does it in one container on a fraction of the RAM with a fraction of the surface area. Mautic earns its complexity when your marketing has stages and rules. If you are leaving a commercial suite, the HubSpot alternatives page is honest about what does not come across: the CRM half, mainly.

What I'd do

Run the official three-role compose on a 4 GB VPS with MariaDB, cron role enabled from minute one, SES as the mailer on a sending subdomain with SPF, DKIM and DMARC published before the first contact is imported. Take a nightly mysqldump and a copy of the media directory. Update on the minor releases only after reading the upgrade notes, because Mautic's major versions have historically been migrations, not upgrades. And put a monitor on the cron: if mautic:emails:send has not run in 15 minutes, you want to know from a pager, not from a customer asking where the welcome email went.