Open source marketing automation for technology and SaaS companies

Why open source marketing automation for SaaS starts with product events

If you run growth or lifecycle marketing for a software product, you are probably looking at trial users who stall after day three, usage thresholds that should trigger an upgrade conversation, and a HubSpot or Marketo contract up for renewal. Mautic can run this lifecycle email in infrastructure you control, provided three things are designed before the first campaign is built: how product usage events reach Mautic, how sending is configured, and how contacts sync with your CRM. Without those decisions, the self-hosted platform is simply a new place to send the same batch emails.

Product usage data differs from the generic marketing data Mautic was first set up to handle. It arrives at high volume, it is behavioral rather than declarative (a user who created three projects tells you more than a form field), and every event belongs to a customer account, often with several users per account. That changes the trigger model. A campaign keyed to a single contact record is rarely enough, so you need to decide whether account-level signals (seat count, plan, last active date) are stored on contacts, on companies, or sent to Mautic as custom fields from your product backend. Check the Mautic segment and campaign documentation for the trigger and field types your version supports, and test with a sample account before you commit to a model.

On cost, Mautic is licensed under GPL-3.0 and has no paid edition of the software itself, so you are not paying per contact or per seat for the platform. What you pay for is the server that runs it, the email sending service, the initial setup and integration work, and ongoing administration, including cron jobs and queue workers that campaign triggers depend on. Ask any partner to separate those lines in a written quote. On platform fit, the 7.x line is the current choice for new deployments, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, so confirm the release status with the project before you pick a version for a multi-year program.

Which requirements shape a SaaS lifecycle build

This table maps the regulatory and mailbox provider requirements that most often affect a self-hosted lifecycle email build for software companies, with the build decision each one forces. Read each row as a design input: the requirement on the left, what it changes in your sending domains, consent fields, data residency, export paths and evidence on the right. Confirm applicability with counsel, since several rules depend on whether your company is itself a regulated provider or only a customer of one.

Requirement	What it means for the build	Evidence to keep
Gmail and Yahoo bulk sender rules	Authenticate every sending domain with SPF and DKIM, publish a DMARC policy, and support one-click unsubscribe for marketing mail. Confirm current thresholds and header requirements with the mailbox providers before launch.	DNS records, DMARC aggregate reports, bounce and complaint rates per domain
GDPR Article 28(3) processor terms	If a vendor hosts contact and product usage data, the contract must limit processing to documented instructions, including transfers. Self-hosting inside your own cloud account narrows the vendor list you must contract with.	Signed processor agreement, list of sub-processors, documented instructions for each data flow
GDPR Article 32 security of processing	Usage events, email addresses and campaign logs need access control, encryption in transit and at rest, backups and logging sized to the data set. Restrict admin roles and separate production from test sends.	Access reviews, encryption configuration, backup test records, security logs
EU Data Act switching rights (Articles 23, 25, 50)	Hosted data processing services must let customers switch providers or move to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. Keep contact, consent and campaign exports in open formats so the switch stays possible.	Export runbooks, sample exports tested against a second system, contract notice terms
Switching-charge ban (Article 29, from 12 January 2027)	From that date, providers of data processing services may not impose switching charges. Check whether your hosted marketing or CRM vendor's exit terms comply, and do not build exports that depend on paid vendor tooling.	Contract clauses on exit fees, vendor exit plan
NIS2 and Implementing Regulation (EU) 2024/2690	Relevant only if your company provides cloud, data center, managed or managed security services to others. In that case, your lifecycle platform may fall within the technical requirements for those providers, so confirm scope before design.	Scope determination memo, mapping of Article 21(2) measures to your controls
SOC 2 Trust Services Criteria, security CC1 to CC9	Enterprise buyers often ask for evidence over the security common criteria. Design role-based access, change control for campaign and integration configuration, and monitoring of send and sync jobs so they can be shown in a report.	Access logs, change tickets, monitoring alerts, policy documents; the auditor decides sufficiency

How product usage events become Mautic campaign triggers

Product usage events reach Mautic through a data path that you design, and the path has three stages: the product writes events to a database or event pipeline, a process maps those events onto Mautic contacts and points, and Mautic's own scheduled jobs evaluate segments and campaigns against the updated contact records. Mautic does not read your product database directly. Before any trigger can fire, you must decide how events are sent (direct API calls from the application, a batch job reading a warehouse table, or a streaming pipeline) and who owns the mapping from an event such as project_created to a contact field or point change. Confirm this with your engineering team and your Mautic partner early, because event ingestion is a separate design decision with its own volume, retry and ownership questions.

Mautic depends on cron jobs for three recurring tasks: segment updates, campaign updates and campaign triggers. The Mautic cron jobs documentation says these should be staggered rather than run at the same moment, so that a heavy segment rebuild does not delay the campaign evaluation that sends a trial reminder. A separate broadcasts command sends segment emails, and when emails are queued, a messenger consumer must be running to deliver them. Each of these processes is sized against event volume: the more usage events per hour, the more contacts change segment membership, the more campaign decisions are evaluated, and the more messages enter the queue. Ask your partner to document the cron schedule, the consumer count and the expected peak event rate, and to test a launch-day load before the first onboarding campaign goes live.

How a SaaS team rolls out Mautic in phases

The sequence moves from event and data discovery to a supervised cutover, so that lifecycle email runs from product signals on infrastructure the team controls, with consent history and sending reputation intact at each stage.

Map product events and lifecycle stages
Start with a discovery workshop led by the product, growth and engineering leads. List the product usage events that should trigger email (sign-up, activation, first project created, seat invited, trial ending), define each lifecycle stage and inventory the contact, company and consent fields currently held in HubSpot or Marketo. Record which fields are authoritative and which are duplicates. Done when the team signs off a written event dictionary and a field-level data map that names an owner for each field.
Provision a dedicated Mautic server
The infrastructure team builds the environment on a VPS or dedicated server, since the Mautic project states that it should not be installed on shared hosting. Confirm the PHP, database and web server versions against the current Mautic requirements before provisioning, and plan separate staging and production instances. Cron scheduling and a queue worker are set up at this stage, not later. Done when a staging instance passes a test login, a test campaign run and a cron health check.
Configure sending domain and authentication
The email and DNS administrators set up a dedicated sending subdomain with SPF, DKIM and DMARC records, and confirm the sending service and bounce handling before any live send. Agree a warm-up plan that starts with engaged users and increases volume gradually, with the marketing lead approving each step. Confirm the current bulk sender requirements for Gmail with the mailbox provider's documentation at the time of build. Done when test messages pass authentication checks and the warm-up schedule is approved in writing.
Sync CRM and migrate contacts with consent
Build the CRM sync between Mautic and the existing CRM, using the data map from discovery to decide which system owns each field. Migrate contacts in batches, carrying across consent status, unsubscribe and suppression lists, and the source and date of each consent record. Remove duplicates before import and reconcile counts after each batch. Done when a sample reconciliation shows matching contact counts, suppression lists transferred without loss and sync errors below an agreed threshold set by the team.
Build trial and onboarding campaigns in pilots
Launch the trial and onboarding sequences in staged pilots, starting with one lifecycle stage and a limited audience. Test triggers from real product events, check that suppression rules stop emails to unsubscribed or converted users, and review bounce and complaint rates after each pilot wave. Expand to the next stage only when the previous one is stable and the product team confirms the event data is correct. Done when each campaign has a pilot report and a signed-off release for the full audience.
Cut over and run both systems in parallel
Switch live sending to Mautic for the approved lifecycle stages while the legacy platform stays available for a parallel run. Compare send logs, trigger counts and suppression behavior between the two systems for an agreed period, and keep a documented rollback path. Retire legacy sequences only after the parallel results match. Done when the marketing and engineering leads sign a cutover record and the legacy sequences are switched off on a dated change ticket.
Hand over monitoring and upgrade planning
Hand the environment to the operations team with runbooks for cron jobs, the broadcasts command, the queue consumer and backups. Set up alerts for failed cron runs and queue backlogs, and assign owners for patches. Agree the upgrade plan against Mautic's published release cadence and support windows, and confirm the current support dates before choosing a version. Done when the operations team has run a restore test and a supported upgrade path is documented and approved.

Which open source platforms fit a SaaS lifecycle stack

Mautic is open source marketing automation software licensed under GPL-3.0, written in PHP on the Symfony framework. For a SaaS team, its main value is a single self-hosted place for contacts, segments, campaigns, landing pages and email sending, with the data staying in your own infrastructure. The current line is Mautic 7.2 (Absolunto), which supports PHP 8.2 to 8.5 and receives active and security support until 30 September 2026. Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, which matters if you want fewer upgrades.

Team fit: Works best where a small operations or growth team can own campaigns and where someone can administer a server, cron and email queues.
Event volume: Segments, campaigns and triggers run through cron jobs that the Mautic docs say should be staggered, so high event volumes need capacity planning.
CRM sync: Plugins exist for HubSpot and Salesforce, so confirm the sync direction and field mapping before committing.
Hosting: Mautic should not run on shared hosting, so plan for a VPS or dedicated server.
Feature parity: Do not assume parity with HubSpot or Marketo. Confirm each feature you need against the release you plan to run.

Check which Mautic release line your PHP and database versions support before you choose a hosting plan.

What drives the cost of a self-hosted SaaS marketing stack

Mautic has no paid edition, so the cost of a self-hosted SaaS marketing stack is the work and infrastructure around it. The cards below separate one-time setup from recurring servers, sending volume, administration and deliverability care, so you can see which lines grow with your contacts and product events. DeployOpen does not publish price estimates; the quote follows the written scope.

Servers and VPS sizing

Mautic should not run on shared hosting, so the project recommends a VPS or dedicated server. Recurring hosting cost scales with contact count, product event volume and how many campaigns evaluate at once, because segment updates, campaign triggers and queued emails all run as scheduled jobs. Ask the partner to size the web, database and worker tier against your peak event rate, and to state what is one-time (provisioning, hardening) and what recurs (compute, storage, backups).

Email sending service and volume tiers

Mautic sends through a transactional or bulk email service that you contract directly, so the per-message fee and volume tier are a separate recurring line from the software. Lifecycle programs for software products can send large volumes of onboarding and usage messages, so tier thresholds and overage rates matter more than the base plan. Ask the quote to show the expected monthly send volume, the tier it falls into, and who holds the sending account.

Setup and CRM integration

Setup covers installation, configuring the product event ingestion, building segments and campaigns, and connecting the CRM so that contacts, lifecycle stages and opportunities stay in step. This is mostly one-time effort, but sync rules, field mapping and duplicate handling need ongoing review as the product and sales process change. Ask whether the quote covers the sync design in writing, the CRM objects in scope, and the test plan before cutover.

Migration of contacts and consent history

Moving from HubSpot or Marketo means exporting contacts, suppression lists, email history and the consent evidence attached to each record. Consent history is the costliest part to get wrong, because records that cannot show when and how a person opted in can block sending to them. This is one-time effort that grows with the size of the list and the number of legacy sources. Ask the partner how consent fields are mapped and validated and what is excluded from import.

Administration and LTS upgrades

Ongoing administration covers patching, backups, cron and queue monitoring, user access and vendor release tracking. Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and each line has its own support end date, so upgrades recur on a planned schedule. Ask for the retainer scope, the upgrade method and how long a version stays supported before a move to the next long-term support line is required.

Deliverability work

Deliverability is partly one-time configuration and partly continuing monitoring. Authentication records for sending domains, dedicated or shared sending IPs, bounce handling, complaint feedback loops and list hygiene all affect whether mail reaches the inbox, and mailbox provider bulk sender rules change over time. Ask whether the quote covers domain authentication, warm-up of new sending streams, bounce and complaint processing, and a recurring review of inbox placement and complaint rates.

Evidence enterprise buyers and auditors ask for

This table maps each piece of evidence a SaaS buyer or auditor typically requests to what it proves and where it usually breaks in a self-hosted Mautic setup. Read it as a preparation checklist: DeployOpen prepares these artifacts from your environment, while independent auditors issue any SOC 2 report and certification bodies issue any certificate.

Evidence	What it shows	Where it usually fails
SOC 2 system scope for the contact store	Which Mautic hosts, databases, queues and integrations fall inside the examined system, assessed against the security common criteria CC1 to CC9	Scope left vague, so SaaS integrations and staging copies with live contacts are missed
Type 1 and Type 2 readiness	Type 1 shows control design at a date; Type 2 adds operating effectiveness over a period, which needs months of consistent records	Controls designed on paper but no evidence captured across the observation window
Access and change records	Who can log in, who holds admin roles, and every change to campaigns, segments and configuration	Shared admin accounts, no SSO enforcement, and config edits made directly in production
Consent and suppression logs	Opt-in source, timestamp, withdrawal events and suppression status for each contact used in sends	Imported lists with no provenance, and suppression not applied to CRM-synced records
Processor agreements and sub-processor list	Contracts binding each processor to documented instructions and Article 32 security measures under GDPR Article 28(3)	Email sending service or CRM connector used without a signed processor agreement
Data export and deletion records	Proof that subject access and erasure requests reached Mautic, the CRM, the sending service and backups	Deletion done in Mautic only, with copies persisting in exports, logs or replicas
Cron and queue monitoring logs	Evidence that segment updates, campaign triggers, broadcasts and the messenger consumer ran as scheduled	Silent job failures during peak sends, with no alerting or retry record
Upgrade and patch records	Dated upgrades against supported Mautic releases, with test results and rollback notes	Running an unsupported minor version after its security support window has closed

Questions to ask a Mautic implementation partner for SaaS

Start with sending. Ask the partner which sending domains and subdomains will carry lifecycle email, how SPF, DKIM and DMARC are configured for each, and who owns the DMARC reporting mailbox after go-live. Ask how they will meet the Gmail bulk sender requirements for volume, how spam complaint rates and bounces will be monitored, and what happens to a sending domain that drops below the thresholds. Ask which mail transport is planned and whether the partner has run Mautic through the Messenger queue at your expected volume. A good answer names the people who will act on a complaint spike, not only the tools they will install.

Then test the event pipeline. Ask how product usage events are sent to Mautic, whether through the contact API or an intermediate queue, and how each event is mapped to a contact field, a point or a campaign trigger. Ask how duplicate events are deduplicated when a client retries a request, how event timestamps are handled across time zones, and which events are allowed to start an onboarding sequence. Ask how the CRM sync decides which record wins when a contact exists in both systems, and how it avoids creating a second contact when an email address changes. Request the mapping document and a test plan that replays a known set of events and checks the resulting contacts and campaign enrollments.

Finally, ask about capacity, migration and upgrades. Ask how the partner sizes cron jobs for segment updates, campaign updates and triggers, how they stagger them, and how they set up the broadcasts command and the messenger consumer. Ask how HubSpot or Marketo data will be moved, and specifically how consent history, unsubscribe records and suppression lists will be carried over with their original dates and sources rather than re-imported as opt-ins. Ask which Mautic release line they will run, when its support window ends, and how they will plan the move to the next long-term support release. Confirm that their security testing covers the event ingestion endpoints, API credentials and the queue, not only the public web pages.

Common questions from SaaS teams before hiring help

What drives the cost of moving from HubSpot or Marketo to Mautic?

Mautic has no paid edition of the software, so the cost is in the infrastructure, the email sending service, setup, CRM integration, data migration and ongoing administration. HubSpot and Marketo price mainly by contacts and seats and often add onboarding fees, so the comparison depends on your contact count, send volume and how much of the work your team already does. Your largest variables are the number of integrations with product and billing data, the number of sending domains, and whether you need a managed Mautic hosting service instead of your own servers. Ask any partner for a quote that separates one-time setup from recurring hosting, sending and administration, and that states which CRM and event sources are in scope.

How long does a migration from HubSpot or Marketo take?

The duration depends on the scope, so no fixed timeline applies to every SaaS company. The main factors are how many contacts, consent records, segments, campaigns and product event streams you move, how many CRM objects must sync, and how many sending domains need authentication and warm-up. Parallel running with your current platform usually extends the timeline but reduces risk during cut-over. Ask for a written plan that lists each workstream, its acceptance test and the point at which your current platform is switched off.

What does our team need to provide before an implementation starts?

Your team needs to provide four things: a documented event schema for product usage events that will trigger campaigns, read and write access to the CRM for sync testing, control of the sending domain so SPF, DKIM and DMARC records can be published, and access to your existing consent and unsubscribe data. Engineering time is needed to emit events reliably and to decide which user attributes are allowed in marketing. Confirm these items in the scope before work starts, because missing event data is the most common reason campaigns are delayed.

Can an in-house team run self-hosted Mautic without outside help?

Yes, many teams run Mautic in house, but the workload is more than installation. Mautic depends on 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. Someone must own server patching, database backups, the mail transport, bounce handling and monthly and quarterly updates. The project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. Assess whether you have operations skills for these tasks, and decide whether to retain an outside partner for upgrades and monitoring.

Does Mautic require a paid license for commercial use?

No, Mautic does not require a paid license for the software itself. The repository is licensed under GPL-3.0, and mautic.org offers the free self-hosted download. Separately, the project promotes managed Mautic and Mautic hosting services, which are paid services rather than license fees. Your costs will still include servers, sending services and any setup or support you buy. Have your legal team confirm how the GPL applies to any custom modules or plugins you build or distribute.

How do EU Data Act switching rights apply if our marketing tool is a hosted vendor?

The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, providers may not impose any switching charges, and until then reduced charges may not exceed costs directly linked to switching. Check whether your hosted vendor is in scope, what export formats it provides for contacts, events and consent records, and what it charges for exit. Self-hosting Mautic keeps your data in your own environment, but you should still document your export and exit procedure.

What happens to our campaigns when Mautic needs an upgrade?

Upgrades are planned around Mautic's release cycle, which the project describes as monthly patch releases, minor releases every three months and major releases every two years. Each version has a defined support window, and the project lists long-term support releases with security support through specific dates, so you should check which release your instance runs before planning changes. Before any upgrade, test campaigns, segments, plugins and CRM sync in a staging environment, take a database backup and confirm that PHP and database versions still meet the requirements. Ask a partner how they schedule upgrades so that campaign sends are not disrupted and how they handle rollback.

Is Mautic a good fit for product-led lifecycle email?

Mautic can trigger campaigns from contact fields and events, so it fits lifecycle email when your product sends clean, consistent usage data into it. The fit depends on your event volume, how quickly triggers must fire, and whether you need real-time in-app messaging, which is a separate capability you should confirm with your vendor. Ask your engineers to define the event schema, decide how events are deduplicated, and test trigger latency under expected load. Use a proof of concept with one onboarding sequence to check whether the design meets your needs before you migrate every campaign.

How DeployOpen scopes and supports a SaaS Mautic build

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts or data centers. For a SaaS Mautic build, that means starting from your product events, sending domains and CRM data, then delivering a written scope before any work begins. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

Map which product usage events should trigger lifecycle emails, and which should never reach marketing tools.
Confirm contact volume, trial length, sending domains and the CRM that Mautic must sync with.
Agree in writing the deliverables, hosting location, cron and queue sizing, and migration boundaries before work starts.

How we build

Deploy Mautic on a VPS or dedicated server in your cloud account, following its requirements for PHP, the database and the web server.
Configure SPF, DKIM and DMARC for sending domains, and test Gmail bulk sender rule compliance before the first live campaign.
Build product event ingestion, trial and onboarding campaigns, and CRM sync, then test each path with sample accounts.

How we hand over

Document architecture, cron schedules, queue workers, event mappings and the consent and unsubscribe logic in a runbook.
Train your marketing operations and engineering staff on campaign editing, segment rules and troubleshooting send failures.
Provide a written upgrade plan that follows Mautic's release cadence and identifies the support window for your installed version.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped to your sending volume and integrations.
Patch and upgrade Mautic on a planned schedule, testing campaigns, CRM sync and deliverability after each change.
Run security testing of the Mautic deployment and its integrations, and prepare evidence for your compliance reviews.