# Mautic for SaaS

> Running lifecycle email on Mautic: hosting and sending setup, segment and campaign builders, product event ingestion and the maintenance cost nobody mentions.

Source: https://saas-marketing.net/guides/mautic-for-saas/
Topic: SaaS Email Marketing
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/mautic-for-saas/

## Short answer

Mautic is open source marketing automation you host yourself. For SaaS it makes sense under three conditions: strict data residency requirements, very large contact lists on a small budget, or an in-house engineer who wants to own deliverability. It costs no licence fee and roughly 4 to 10 engineering hours a month in maintenance, plus sending costs through Amazon SES or similar. Below about 50,000 contacts a hosted tool is almost always cheaper in total.

## Key takeaways

- Mautic has no licence fee and a real maintenance cost of roughly 4 to 10 engineering hours a month.
- Cron jobs and queue workers are the whole operational story. Misconfigured crons are the top cause of Mautic failures.
- Sending through Amazon SES costs about $0.10 per thousand emails, which is where the economics get interesting at scale.
- At 10,000 contacts Mautic loses on total cost. At 100,000 contacts it wins clearly if you already employ the engineer.
- You own deliverability entirely: warming, reputation, blocklist monitoring and bounce handling are yours.
- Product event ingestion works through the contacts API, but you build the event semantics yourself.

---

Mautic is the main open source alternative to Customer.io, HubSpot and the rest. No licence fee, your database, your servers, your rules. The search traffic comes mostly from two groups: founders trying to cut a $1,200 monthly bill, and companies with a legal obligation to keep contact data inside a specific jurisdiction.

The honest framing is a trade, not a saving. Mautic converts a licence fee into engineering hours. Whether that is a good deal depends entirely on what those hours are worth to you and whether anybody wants to spend them.

## When does Mautic actually make sense?

Three situations. If none of them describe you, stop reading and buy something hosted.

**Data residency is a hard requirement.** You sell to German public sector, EU health, or a regulated financial segment that requires contact data stay in-country on infrastructure you control. Some hosted vendors offer EU regions, but "we host it ourselves in Frankfurt" answers a security questionnaire in a way a vendor DPA sometimes cannot. This is the strongest case for Mautic and the one I would not argue with.

**Very large lists at low value per contact.** 400,000 contacts on a freemium product with a $9 plan. Per-contact pricing makes hosted tools cost more than the segment generates. Mautic's costs scale with servers and send volume, not contacts, which changes the arithmetic entirely.

**You employ an engineer who wants this.** Not an engineer you can assign. One who volunteers, finds deliverability interesting, and will still be there in eighteen months. That person is rarer than the plan assumes, and the whole thing collapses without them.

At Series A your scarcest resource is engineering attention. Every hour spent on queue workers and IP warming is an hour not spent on the product. A $600 monthly licence that costs zero engineering hours is usually the better trade, and the fact that the licence appears on a budget line while the engineering hours do not is a reporting artefact, not a saving.

## What does the setup path look like?

More involved than a Docker command, less involved than the horror stories. Budget two to three weeks of part-time work to production.

**Getting Mautic to production**

Step two is where most installations fail. Mautic does nothing on a schedule unless a cron job tells it to, and when a cron silently dies, campaigns stop and the interface still shows them as active. Nothing alerts you. I have seen a company discover three weeks later that no onboarding email had gone out since a server reboot.

**$0.10** Approximate cost per thousand emails sent through Amazon SES

## How good are the campaign and segment builders?

Competent and dated. The campaign builder is a visual canvas with decisions, actions and conditions, and it expresses most of what a SaaS lifecycle programme needs: branch on a field value, wait, send, check, branch again.

Segments are filter based on contact fields, with AND and OR logic, and they rebuild on a cron. That rebuild cadence is the thing to understand: a segment is not evaluated in real time, so a contact who qualifies at 10:04 enters when the cron next runs. If that is hourly, your fastest possible trigger is roughly an hour.

For a usage limit email that needs to arrive in two minutes, that is disqualifying. For a weekly nurture sequence, it is irrelevant. Know which of your sequences are time sensitive before deciding this matters.

### Product event ingestion

Mautic has no first class custom event object with arbitrary properties. This is the sharpest functional gap against Customer.io and it shapes everything you build.

Your options, in rough order of robustness:

- **Custom fields via the REST API.** Your app PATCHes the contact with `last_limit_hit_at`, `projects_created`, `seats_used`. Segments filter on those fields. Works well for state, poorly for discrete events.
- **Tags via the API.** Add `hit_limit` to trigger a campaign. Simple, but a tag carries no properties, so the email cannot say which limit or what number.
- **Campaign trigger endpoints.** Push a contact directly into a campaign from your application, bypassing segment rebuild latency. This is the closest thing to a real event trigger and it is what you should use for anything time sensitive.
- **Webhooks inbound via a small middleware service.** Most serious installations end up with a thin service between the app and Mautic that translates events into the right combination of the above. Budget for building it.

That middleware is the hidden scope. Hosted product-led tools give you an events endpoint and a property model out of the box. On Mautic you write that layer, and then you maintain it.

Storing only `last_limit_hit_at` loses history. When someone asks how many times a user hit a limit before upgrading, you cannot answer, because you overwrote the field each time. Decide early whether you need event history, and if you do, keep it in your own database and send Mautic only the derived state it needs to segment on.

## Total cost of ownership, honestly

The comparison that matters includes engineering time at a loaded rate. Use $100 an hour as a rough loaded cost for a mid-level engineer; adjust for your market.

Read the bottom row twice. At 10,000 contacts Mautic costs two to four times as much as a hosted tool once you count the engineering. At 100,000 contacts the totals converge and Mautic pulls ahead, particularly if your maintenance sits at the low end because the installation is stable and the engineer is efficient.

The break-even in most scenarios lands somewhere between 50,000 and 80,000 contacts, and it moves earlier if your sends per contact are high, later if your engineering rate is high. Run the numbers on your own volume with the [SaaS email revenue calculator](/calculators/email-revenue/) so the cost decision sits next to the revenue the programme produces rather than alone on a spreadsheet.

## Owning deliverability

This is the part teams underestimate most, because hosted providers hide it so completely that people forget it exists.

On Mautic, you own: IP warming, reputation across Gmail, Outlook and corporate filters, blocklist monitoring at Spamhaus and elsewhere, bounce classification and suppression, complaint feedback loops, authentication records, and the list hygiene policy that keeps all of it healthy.

A competent engineer who cares can absolutely match a hosted provider's placement rates. An installation nobody owns will drift, and the drift is invisible until a customer mentions they stopped receiving your emails three months ago.

Three practices that make this manageable:

- Seed lists. Send every campaign to a set of test inboxes across Gmail, Outlook, Yahoo and a corporate Google Workspace, and check placement manually. Twenty minutes a week.
- Automatic suppression on two consecutive soft bounces, immediate on hard. Mautic will do this if configured, and will not if it is not.
- A sunset policy: stop sending to anyone with no engagement in 180 days. Nothing damages sender reputation faster than a large tail of dead addresses, and it is the mistake self hosted senders make most, along with the ones collected in [SaaS email marketing mistakes](/guides/saas-email-marketing-mistakes/).

## Mautic versus the hosted alternatives

| Dimension | Mautic | Customer.io | HubSpot |
| --- | --- | --- | --- |
| Licence cost | None | Mid | High at scale |
| Product event model | Fields and tags, build it yourself | First class, with properties | Weak for product events |
| Real time triggers | Only via direct campaign push | Yes | Partial |
| Data residency control | Total | EU region available | Limited |
| Engineering burden | High and ongoing | Low | Low |
| Time to first sequence | 2-3 weeks | 2-3 days | 2-3 days |

If your constraint is data residency, Mautic wins and the others mostly cannot compete. If your constraint is budget at very large list sizes, Mautic wins once you cross the break-even. If your constraint is anything else, including speed, reliability or the number of sequences you can ship per quarter, a hosted tool wins and it is not close. The hosted field is covered in [SaaS email marketing platforms compared](/guides/saas-email-marketing-platforms/) and the most common head to head in [HubSpot versus Customer.io](/comparisons/hubspot-vs-customer-io/).

## The verdict

Mautic saves licence fees and spends engineering hours. It only wins when you have an engineer who wants to own deliverability, or a legal requirement that removes the choice.

If that describes you, the setup path above is the whole job and the monitoring step is what separates a working installation from an intermittent one. If it does not, buy something hosted and spend the engineering time on the product instead. What you build matters more than what you build it on: the sequence design in [email marketing for SaaS companies](/guides/email-marketing-for-saas-companies/), the definitions in [lifecycle email marketing](/glossary/lifecycle-email-marketing/), the numbers in the [SaaS email benchmarks](/research/saas-email-benchmarks/), and the structured walkthrough in the [lifecycle email course](/courses/saas-lifecycle-email/) all apply identically on any platform, including this one. The rest of the programme design sits in the [SaaS email marketing](/saas-email-marketing/) hub.

## Frequently asked questions

### Is Mautic a good fit for SaaS companies?

For a specific minority, yes. Companies with data residency obligations that prevent contact data leaving a jurisdiction, companies with very large low-value lists where per-contact pricing is punitive, and companies with an engineer who genuinely wants to own the email stack. For everyone else the maintenance burden exceeds the licence savings.

### What does it cost to run Mautic?

Hosting runs roughly $40 to $300 a month depending on list size, sending through Amazon SES costs about $0.10 per thousand emails, and maintenance takes 4 to 10 engineering hours a month. At a loaded engineering cost of $100 an hour that maintenance alone is $400 to $1,000 monthly, which is the number people omit when they say Mautic is free.

### How do you send product events into Mautic?

Through the REST API, by updating custom fields on the contact, adding a tag, or posting to a campaign trigger endpoint. Mautic has no first class custom event object with arbitrary properties, so you model events as fields and tags and build the semantics yourself. This is the sharpest functional gap against Customer.io.

### What breaks most often in a Mautic installation?

Cron jobs. Mautic depends on scheduled tasks for segment rebuilds, campaign execution and email queue processing. If a cron silently stops, campaigns quietly stop firing and nothing alerts you. Monitoring cron completion and queue depth is the single most important piece of operational work.

### Mautic or Customer.io for a Series A SaaS?

Customer.io, unless you have a data residency constraint. At Series A your engineering time is the scarcest resource in the company, and spending it on queue workers and deliverability instead of product is a poor trade. Revisit at large scale when the licence bill genuinely rivals an engineer's part-time cost.

### Can Mautic handle deliverability as well as a hosted tool?

It can, but only with active ownership. You configure authentication, warm the IP, monitor blocklists, handle bounces and complaints, and set up feedback loops yourself. A hosted provider does that as a product. A competent engineer can match it; an unowned installation will not.