When Mautic high availability becomes a design requirement
High availability for Mautic means deciding which of its roles must keep working when a node fails, then building each of those roles so it can. For a marketing team, the stakes are concrete. If the only Mautic server goes down, landing page forms stop accepting submissions, tracking and link activity goes unrecorded, and scheduled sends wait until the server returns. Some of that activity cannot be fully reconstructed later, so the cost of an outage extends beyond the hours of downtime. The practical question is which functions the business cannot pause while a server is repaired.
Mautic is harder to make redundant than a stateless web application because several parts carry state. Segment and campaign processing run from cron jobs, and the project's documentation says those jobs should be staggered so they do not compete for the same work. Broadcast emails depend on a broadcasts command, and when email is queued, a messenger consumer must be running to send it. Uploaded files, such as images used in emails and landing pages, must be available to every web node that serves them. The database holds contacts, consent records, campaign state and queue activity, so every node must read and write the same data consistently. Each of these needs its own answer.
The Mautic project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. The Mautic 7.0 requirements also set the platform baseline: PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, served by Apache, Nginx or IIS. These requirements constrain the design. Any shared file location, cache or database endpoint you add must work with the supported database engines and PHP versions, and the database layer needs its own sizing and failover plan, separate from the web tier's design. Confirm the exact versions against the release you intend to run before you commit to an architecture.
DeployOpen does not assume that Mautic ships a supported clustering pattern for running several application nodes against one database. Verify any multi-node layout before relying on it. Confirm the pattern against current Mautic documentation and with your own platform team before design work starts. Then list each role: web and tracking endpoints, cron scheduling, queue consumers, the database, shared file storage and any cache. For each, record whether it must survive a node failure, how much interruption your marketing operations can tolerate, and who owns recovery. That list determines the rest of the architecture and the scope of the work.
Which Mautic roles need redundancy and which can run as one instance
Mautic splits its work across web requests, scheduled jobs, background workers and shared services, and each role holds different state with different failure effects. Redundancy matters most for the web tier and the database, where an outage stops admin access and tracking at once. Cron, broadcasts and the queue consumer can often start on a single node in a first phase if each has a supervisor and an alert when it stops.
Web tier and cache
The web tier serves the admin UI, tracking and form endpoints, and landing pages. Nodes should hold no state of their own, so extra nodes can sit behind a load balancer once sessions and cache live in shared storage. If a node stops, its requests fail until the balancer removes it, and visitors may lose form submissions in flight. Check where PHP sessions and the Mautic cache are stored, because a cache kept on one node serves stale data or logs users out when that node is lost.
Database
The database holds contacts, consent records, segment membership, campaign state, email statistics and queued work, so it is the one role that cannot be rebuilt from files. If it stops, the web tier, cron jobs and queue consumer all stop with it. Mautic requires MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Ask your platform team how replication and failover will be handled, and confirm that restores from backup are tested, not just scheduled.
Shared file storage
Shared storage holds uploads, imported contact files and generated files that every web node and the job host must read. If the share is unavailable, uploads and imports fail, and pages that reference stored files break for every node that mounts it. In a first phase, all roles can share one node and one local disk. Before adding nodes, confirm the storage type supports the file locking and latency your Mautic version expects, and test a file written on one node from another.
Cron host
The cron host runs the jobs that update segments, update campaigns and fire campaign triggers. Each job should have one owner, because two hosts running the same job can apply campaign actions twice. If the host stops, segments go stale, campaigns pause and triggers fire late, with no error shown to users. A single cron host is workable in phase one. Schedules, staggering and batch limits are covered in the Mautic cron jobs and email queue topic.
Broadcasts command
The broadcasts command sends emails to segments as a long-running batch job. It should run on one node at a time, and it is usually scheduled on the cron host. If the run is interrupted, confirm how Mautic resumes it and which contacts already received the send, so that a rerun does not email the same people again. Test an interrupted send on staging before relying on it in production, and record the resume procedure in the runbook.
Messenger consumer and email transport
The messenger consumer takes queued emails and hands each one to the outbound transport, either SMTP or an email API. If the consumer stops, the queue grows and sends are delayed, with no failure visible in the campaign. If the transport is unavailable, messages fail or retry depending on how the transport is configured. Run the consumer under a process supervisor with automatic restart. Add consumers when queue depth shows a backlog, and ask your email provider about rate limits and any failover sending path.
Choosing a Mautic high availability topology and its trade-offs
This table compares three ways to lay out a Mautic installation, from a single application node with a standby restore to separated web, cron and queue tiers. Read each row as a question to answer for your own environment, since the right choice depends on contact volume, email sending pattern and how much operational work your team can carry. The main takeaway is that adding web nodes is the easy part; the cron schedule, queue consumers, shared files and failover runbook decide whether the extra capacity is safe to use.
| Topology | Single app node with managed database and standby restore | Two or more web nodes behind a load balancer with one cron host | Separated web, cron and queue tiers with dedicated workers |
|---|---|---|---|
| When it fits | Smaller contact lists and modest send volumes where a short outage during restore is acceptable | Steady traffic on tracking and form endpoints that needs more than one web server, with campaigns that are not time critical | Large contact volumes, heavy campaign processing or large queued sends that must not compete with web requests |
| Patching and upgrades | One node to patch and test, with a maintenance window for each Mautic release | Rolling patches across web nodes, but every node must run the same Mautic version and code before traffic returns | More hosts to patch and test, with a defined order: workers and cron first or last, then web nodes, per the release notes |
| Certificates and TLS | One certificate and one termination point to renew | Certificates on the load balancer or each node; confirm how forwarded headers and HTTPS detection are configured | Certificates at the edge plus internal trust between tiers if traffic is encrypted between hosts |
| Session behavior | Sessions stay on the single node, so a restart signs out active users | Confirm whether sessions are shared through the database or cache, or whether sticky sessions are required | Same session question as the web tier, plus confirm that workers never depend on web session state |
| Cron and scheduled jobs | Cron runs on the one node; check that staggered schedules are still correct after any move | Cron must run on exactly one host. Confirm with the Mautic cron documentation and your version whether a second host can run jobs safely or whether locking must be added | Cron runs on a dedicated host, separate from web and workers, with the segment, campaign and broadcast jobs staggered as the docs describe |
| Queue and email consumers | Messenger consumer runs on the node, so a stalled consumer is visible on the same host as the web app | Confirm where the messenger consumer runs and whether more than one consumer can process the same queue without duplicate sends | Dedicated worker hosts with supervised consumers; size and restart policy become part of the runbook |
| Shared files and storage | Local storage on one node; back up the media and configuration directories separately from the database | Uploaded files, cache and generated assets must live on shared storage that every web node can read and write | Shared storage must serve web and worker tiers; confirm which paths are shared and which are per host |
| Failover runbook | Restore the database and files to a standby node; the runbook is short but recovery time depends on restore testing | Node removal is straightforward, but database failover and cron relocation must be rehearsed together | Most steps to document: which tier fails, how cron moves, how queues drain and how web nodes rejoin |
| Monitoring | Disk, PHP errors, cron run status, database health and backup success on one host | Per-node health checks, load balancer health probes, cron heartbeat and shared storage latency | Per-tier alerts for web latency, queue depth, consumer status, cron runs and send failures |
| What to confirm before choosing | Restore time from your tested backups and the Mautic version and PHP version you will run | How your Mautic version handles multiple web nodes, session storage and whether cron can run on a second host safely | Queue consumer behavior, worker restart policy and the staggering of cron jobs for your send volumes |
Mautic high availability build sequence
This sequence takes a Mautic installation from a single server to a web tier that keeps serving when one node fails, with cron jobs, queue workers and email kept off the web nodes. Each step closes with a check the team can run before moving on. The release and PHP version are confirmed first, because every later decision depends on them.
Confirm release and PHP version
Before any infrastructure is ordered, the platform owner selects the target Mautic release and checks it against the release and requirements pages. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, and Mautic 7.2 supports PHP 8.2 to 8.5 with active and security support until 30 September 2026. Choose a release whose support window covers the planned go-live, and confirm that the chosen web server (Apache, Nginx or IIS) is supported. Check: the release, PHP version and web server are written into the design record and approved by the client's application owner.
Provision the database and recovery path
Create the database on MySQL 5.7 or higher with InnoDB, or on MariaDB 10.2 or higher, as the requirements page specifies. Decide the recovery target first. A replica with automated failover needs replication design and failover testing, while a backup restore needs a documented restore procedure and an agreed recovery point. Place the database where every web node reaches it over a private network. Check: a restore from the most recent backup runs on a separate host, and Mautic loads the contact list against the restored database.
Place uploaded files on shared storage
Mautic writes uploaded assets to disk, so every web node must read and write the same location. Mount a network file system or equivalent shared storage at the same path on each node, with ownership and permissions set for the web server user. Confirm with the release documentation which directories must be shared. Decide how the cache is handled, since a node-local cache will differ from the others unless it is shared or cleared on change. Check: an asset uploaded through one node loads through every other node after a web service restart.
Install Mautic on each web node
Install from the same production package or the same Composer project template on every web node, using identical versions and configuration files. The Composer project template is the recommended route since version 4.0. Install the same plugin set on each node, and keep the local configuration identical so the database, mailer and site URL settings match. Do not run the installer on more than one node against the same database. Check: a comparison of the installed version and configuration on each node shows no differences, and a second node serves the same contact record as the first.
Separate cron and messenger consumer hosts
Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and the documentation says these should be staggered. Broadcasts need their own command, and queued email needs a messenger consumer. Run these on dedicated hosts outside the web pool, so a web node restart does not stop campaign processing. Assign each job to exactly one host or use a scheduler with locking, so two hosts never run the same campaign update. Check: the logs show each cron job running once per scheduled window, and the consumer keeps processing after the web tier is restarted.
Place load balancer and health checks in front
Put the load balancer in front of the web tier with a health check that calls an endpoint confirming the application and database respond. Confirm how sessions are handled, either sticky sessions or centrally stored sessions, so that a user signed in on one node is not lost when traffic moves. Align the public hostname with tracking and form endpoints, and decide where TLS is terminated according to the client's standard. Check: with one web node taken out of service, the admin login and public tracking endpoints still respond through the balancer.
Configure outbound email and failover tests
Configure outbound email through the chosen sending service or SMTP relay, and confirm that bounce and unsubscribe handling works. Queue a test email, stop the messenger consumer, then start it again to confirm the queued message is processed. Run a failover test on each component: a web node, the database replica or restore, and the cron host, recording the observed recovery steps and how long each took. Check: a queued email is sent after the consumer restarts, and the failover results are signed off with an owner for each gap found.
Database sizing, replication and shared storage for Mautic high availability
The database holds contacts, tracking history, segment membership, campaign state and queued work, so it usually sets both the scale ceiling and the recovery point for a Mautic installation. If it becomes unavailable, every web node, cron job and queue worker stops doing useful work at the same time. Any writes made after the last good backup are lost unless replication or point-in-time recovery covers them. Set recovery objectives for the database first, then design the web and worker tiers around what the database can deliver.
Mautic 7.0 requires MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Confirm which engine and version your target release supports on the Mautic requirements page before you choose, and check that every Mautic table uses InnoDB. The supplied facts do not give sizing figures, so size from your own inputs: total contact count, event volume (sends, opens, clicks and page hits), the growth rate of tracking history, your retention period for that history, the number of active segments and the number of campaigns running at once. Load test the sizing with a copy of production-scale data and ask the partner to show the worksheet and assumptions behind the figures.
A read replica can take reporting, list views and other read-heavy work off the primary, but it does not remove the single writer. Contact updates, tracking inserts, segment membership changes and queue writes still go to one primary. Whether Mautic sends any read traffic to a replica safely is not described in the supplied facts, so confirm the read and write paths with the Mautic project and your database vendor before you route application reads to a replica. Also test replication lag: a replica that trails the primary can show stale contact or campaign state, which can cause duplicate sends or missed steps. Rehearse failover while cron and the messenger consumer are running.
Uploads, images, generated assets and any files that web nodes write must sit on storage that every node can see. Local disks diverge quickly: an asset uploaded through one node is missing on another, which produces broken images, failed downloads and inconsistent forms. Options include a network file share, a clustered filesystem, or object storage if a supported plugin or configuration exists for your release, which you must confirm. Also confirm where the cache lives (local filesystem or a shared cache), how sessions are handled across multiple web nodes (sticky sessions or a shared session store), and whether cron jobs and queue workers use the same storage paths as the web tier. Ask the partner for this list in writing before implementation starts.
What drives Mautic high availability effort and cost
This table lists the drivers that change Mautic high availability effort and cost, why each one moves the work, and how to keep it contained before you request a quote. Read the middle column for the reason and the last column for the control you can apply during scoping. The main takeaway is that node count, queue design and integrations set the one-time build, while monitoring, patching and failover tests recur for as long as the platform runs.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Contact volume and tracking event rate | Larger contact tables and heavy tracking traffic enlarge database sizing, index maintenance and cron run times. One-time sizing, then recurring capacity reviews. | Model contact table growth and event retention early. Archive or purge tracking history under a written policy. |
| Email send volume and broadcast size | Large broadcasts depend on queued sends and the messenger consumer, so queue faults become visible to campaign teams. Recurring: queue monitoring. | Stagger cron jobs and set batch limits. Schedule large broadcasts in windows that have been load tested. |
| Web nodes and environments | Each extra web node, plus staging and disaster recovery copies, adds configuration, deployment and sync work. Build once, then recurring patching of every environment. | Keep node count to what load tests justify. Use one automated deployment path for all environments. |
| Database replication and backup targets | Replication topology, failover design and restore procedures add build work and a recurring test schedule. | Agree recovery targets in writing first. Test failover and restores on a fixed calendar and after major changes. |
| Shared storage choice | Uploads, cache and generated assets must be reachable from every web and worker node. Locking and latency problems usually appear under load. | Choose the storage type with the client's infrastructure team. Confirm locking and latency behavior with a load test. |
| Salesforce or HubSpot integrations | Scheduled sync jobs and point-triggered pushes add run-time load and a second system to reconcile. Recurring: field mapping changes and duplicate checks. | Limit sync direction and fields. Assign one owner for mapping changes and reconciliation reports. |
| Custom plugins and customization | Custom code must run identically on every node and stay compatible across Mautic upgrades. Recurring: compatibility checks at each release. | Keep custom code in version control. Document the plugin list and test it against each release before rollout. |
| Compliance evidence the buyer needs | Auditors typically expect evidence of access control, backups, monitoring and change records, collected again each review cycle. | Agree the control list and evidence format before build. Ask the auditor which artifacts they expect. |
| Internal team skill | Teams already running PHP, Linux, database replication and load balancers need less onboarding. Skill gaps add training time and partner hours. One-time handover, then recurring on-call load. | Name owners for each layer before scoping. Ask for runbooks and a supervised handover in the written quote. |
Protecting shared storage, cron hosts and secrets in a clustered Mautic
A clustered Mautic has more places where credentials, files and network paths can be exposed than a single server does. The controls below apply to each tier in turn, from the database and shared file store to the cron host, the load balancer and the certificates that protect traffic between them. Work through them together, because a gap in one tier often undermines the others.
Database credentials and network reach
Mautic's database account should be usable only from the Mautic web and worker hosts, and the database should accept connections on a private network address rather than a public one. Confirm that the account has the privileges Mautic needs for its migrations and nothing broader, and that administrative accounts are separate from the application account. Check the allowed-host list after every host is added or replaced.
Consistent configuration and secret handling
The local configuration file holds the database password, the mailer credentials and the secret used for signing, and every web and worker node must read the same values. Keep the file out of version control and inject the secrets from your platform's secret store or environment at deploy time. Confirm that a configuration change on one node is rolled to all nodes and that no node runs with a stale copy.
Cron host and consumer access
The host that runs Mautic's scheduled commands and the messenger consumer has the same database and mailer access as the web tier, so it needs the same protection. Restrict who can log in to it, run its jobs under a dedicated non-login user, and record every change to its crontab and service units. Confirm that only one scheduler is active for each job so that segment and campaign updates are not duplicated across hosts.
Shared file store ownership and permissions
Nodes that share the Mautic file store must agree on which user owns uploaded assets, cached files and generated content, and the web server user must be able to write only to the directories it needs. Avoid world-writable paths, and check that the cron and consumer users can write to the same locations without loosening permissions for everyone else. Test ownership on a new node before it receives traffic.
Network rules between tiers
Allow traffic only along the paths the design needs: the load balancer to the web nodes, the web nodes and worker hosts to the database, and the worker hosts to the mail relay. Deny direct access from the internet to the database, cache and cron hosts, and document each rule with its purpose. Review the rules whenever a node is added, because a rule written for three nodes often remains in place for a fourth.
TLS termination and certificate rotation
Decide whether TLS ends at the load balancer or on each web node, and make sure the forwarded protocol and client address headers are trusted only from the load balancer. Plan certificate renewal so that every node and the load balancer receive the new certificate in the same window, and confirm the rotation on each node after it happens. Traffic between tiers that crosses untrusted segments should also be encrypted, and the choice should be written into the design.
How to test Mautic high availability before go-live and after each change
A Mautic high availability test plan should prove how the platform fails and how it recovers, not only that every component starts. Run the same set of fault tests before go-live and again after every change to web nodes, cron scheduling, the messenger consumer, the database, shared storage or mail configuration. Before each test, write three things: a pass condition, the log or metric that will prove it, and a rollback step. Set the targets from your own recovery time and recovery point objectives, agreed by the business owner and the risk owner. Do not copy targets from a template or from another project, because a failover that meets someone else's objective may still miss yours.
Start with the web and cron tests. To remove one web node under load, run a load generator that submits forms and fires tracking requests while several administrators hold active sessions. Pass when submissions and tracking hits succeed or retry through the load balancer, when the stored submission count matches the number of accepted requests, and when admin sessions persist or re-authenticate as your design specifies. Evidence comes from load balancer health check logs, web server 5xx counts and a reconciliation query. For the cron host, stop the machine across a scheduled window that covers the segment, campaign and broadcast commands. Pass when monitoring raises an alert for the missed run, and when the first run after restart processes the backlog without repeating campaign actions for the same contacts. Evidence is the scheduler log, the alert record and campaign event counts per contact. Rollback means restarting the host, removing any duplicate schedule entries and confirming the staggered run times again.
Next, test the queue and storage. Stop the messenger consumer while a send to a small test segment is in the queue. Pass when queued messages wait without delivery, when none are sent twice after the consumer returns, and when the queue drains fully. Evidence is queue depth over time, the consumer process status and the mail transport send log, matched by message identifier. Rollback is restarting the consumer and clearing only the test messages. For the file store outage, block access to the shared storage used for assets and uploads from one web node. Pass when pages that depend on those files show the error you defined, when no uploads are lost and when they return after access is restored. Evidence is the web error log and the storage mount monitoring. Rollback is remounting the storage and checking file integrity against your inventory.
Finish with the database and mail transport. For a database failover or restore rehearsal, promote a replica or restore the latest backup to a standby, and time the interval from the fault to the first successful form submission and the first completed cron run. Record that measured recovery time in the test log beside the objective it must meet. Pass when the measured time falls within your recovery time objective and the tracked event count after recovery is within your recovery point objective. Rollback is returning traffic to the primary and confirming replication. For an email transport failure, block the SMTP relay or sending API endpoint during a queued send. Pass when messages are retried or held, when no failure disappears silently and when alerts fire. Evidence is the transport log, the failed send count and the alert history. Confirm the exact log locations, failover commands and retry settings against the Mautic and database documentation for your version and your own environment before scheduling these tests.
Monitoring, backup, upgrades and documentation after launch
A highly available Mautic deployment has more moving parts than a single server, and most failures show up as stalled campaigns or undelivered email rather than as an outage. The cards below list what the operations team must watch, back up, patch and document once the platform is live, so that the buyer's team can run it without the implementation partner in the loop.
Health checks on each web node
Each web node should be checked separately, not only through the load balancer, because a node with a stale code release or a broken PHP extension can still pass a shared check for a while. Confirm that the tracking endpoint, the login page and a form submission each return the expected result on every node. Include the node's connection to the shared file storage and the database in the same check.
Cron run logs and missed-run alerts
Mautic relies on scheduled jobs for segment updates, campaign updates and campaign triggers, along with the broadcasts command for segment emails. Log the start and end of every run, record the duration, and alert when a scheduled job has not started within its expected window. A silent cron failure usually means contacts stop moving through campaigns without any visible error.
Consumer supervision and queue depth
When email is queued, the messenger consumer must stay running under a process supervisor that restarts it after a crash or reboot. Track queue depth over time and alert when it grows faster than it drains, since a growing backlog delays every send behind it. Confirm the supervisor configuration is included in the configuration backups described elsewhere in this section.
Database replication lag and backup success
If the database runs with a replica, measure replication lag continuously, because reports, segment counts and campaign state can read stale data while lag is high. Separately, confirm that each scheduled database backup completes, is copied off the primary host and is kept for the retention period agreed with the buyer. Ask the partner or platform team which replication tool and backup method they will use before the build begins.
Storage capacity and file permissions
Shared storage holds uploaded assets, cache and logs that every web node and worker reads or writes, so disk growth and file ownership both need monitoring. Alert on free space at a threshold the operations team agrees, and check that the web server and worker users can write only to the directories they need. Permission drift after a deployment is a common cause of failed uploads that appear only on one node.
Certificate expiry and tracking domain availability
Tracking pixels, forms and landing pages are served from public hostnames, and an expired certificate on any of them breaks contact capture. Track expiry dates for every certificate on the load balancer and web nodes, including the hostnames used for tracking, and renew them with enough lead time to test the change. Confirm the renewal method, whether a managed issuer or an internal process, before go-live.
Email delivery signals
Watch bounce, complaint and unsubscribe rates by sending domain and by campaign, and check that the sending service's webhooks or logs reach Mautic as expected. A sudden change usually points to a DNS, authentication or list problem rather than to Mautic itself. Agree with the buyer which thresholds trigger a pause in sending and who has authority to make that call.
Backup of database, files and configuration
A recovery plan needs three sets of data: the database, the uploaded and generated files, and the configuration, including the local settings file, web server and supervisor definitions, and cron schedules. Restore each set into a separate environment on a fixed schedule and time the result, because a backup that has never been restored is an untested assumption. Record which restore steps need access to the secrets store.
Patch and upgrade routine
Plan a recurring routine that applies Mautic's monthly patch releases and reviews each minor and major release against the PHP versions it supports. Check the Mautic releases page for security support end dates for the version in use, since a release that falls out of security support needs a planned move. Upgrade planning details, including plugin compatibility checks, are covered in the upgrades topic.
Runbook and architecture diagram
The buyer's team should receive a runbook covering start, stop, scaling, failover, restore and the alert response for each check above, along with an architecture diagram showing web nodes, workers, cron hosts, database, shared storage and the load balancer. Confirm that the runbook is tested by the team that will use it, not only reviewed. Keep both documents under version control so they match the deployed configuration.
Questions buyers ask before they hire help for Mautic high availability
What drives the cost of a Mautic high availability project?
The cost is driven mainly by how many components must be designed, built and tested, and how many systems they touch. The main cost components are: design and scoping of the topology (web nodes, cron and queue workers, database, shared file storage, caching), build and configuration of those parts in your environment, failover and recovery testing, and documentation and handover. Work that is one-time includes the initial design, build and test. Work that recurs includes monitoring, patching, upgrades and any retainer for ongoing support. Costs rise with the number of environments, strict recovery targets, large contact volumes and integrations that need their own testing. Ask any quote to list each component separately, state what is one-time and what is recurring, and name the environments and failure scenarios it covers. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does a Mautic high availability implementation take?
The schedule depends on the scope, your environment and how quickly your team can provide access and decisions. The main schedule factors are the number of environments to build, whether your cloud, data center or air-gapped network already has the database, storage, load balancing and monitoring services in place, how many integrations must be re-tested after the change, and how long your change approval process takes. Failover testing usually takes longer than the initial build because each failure case needs to be run and checked. No duration is fixed here. Ask for a timeline that lists the phases, the dependencies on your team and the testing window, and confirm it against your own change calendar before work starts.
Can our own team build Mautic high availability without a partner?
Yes, a capable team can build it alone if it has the right skills and time. The work needs operational skills in Linux, PHP and its runtime, MySQL or MariaDB administration with replication, cron scheduling, shared file storage, caching and load balancing. It also needs time to test failure: stopping a web node, a cron host or a database primary under load and confirming that segments, campaigns, broadcasts and queued email still run correctly. Many teams underestimate the testing and the documentation of recovery steps. If one or more of those skills is thin, or if no one can spend time on failure testing, a fixed-scope engagement can cover the gap while your team keeps ownership of the result.
What do you need from our team to start a Mautic high availability project?
You need to provide decisions, access and information before the build starts. Typical inputs include: environments (production, staging and where they run), access to cloud accounts, hypervisors or data center systems, and to the existing Mautic install if there is one, recovery targets for how long the service may be down and how much data loss is acceptable, contact and send volumes with the expected growth, and the names of integration owners for your CRM, email sending service and identity provider. You should also name an approver for changes and a contact for testing windows. Missing inputs are the most common cause of schedule slips, so confirm each one in the written scope.
Is a single Mautic server enough for now?
A single server can be enough for a small contact base and modest send volumes, but it leaves no redundancy. If that server fails, tracking, forms, cron-driven segment and campaign updates and queued email all stop until it is restored. Before you decide, check your contact volume, the size of your sends, how long an outage would be tolerable for your campaigns and whether you have a tested restore process. Mautic should run on a VPS or dedicated server rather than shared hosting, according to the project's requirements page. A design review can show where a single node is a risk and which parts you can separate later without a rebuild.
Is our chosen Mautic high availability topology supported?
Confirm support for your exact topology before you commit to it, because support depends on the Mautic release, PHP version, database engine and web server you choose. Check the requirements page for the release you plan to run, which lists supported PHP versions, MySQL or MariaDB versions with InnoDB, and the supported web servers. Then check the release page for the support dates of that release, since a release near end of support may need an upgrade soon after launch. For the topology itself, such as multiple web nodes sharing storage or a separate database cluster, confirm the approach with Mautic's documentation and with the vendor or community channels for your specific version. Put the result in the design record.
How does a fixed-scope agreement define what is included?
A fixed-scope agreement lists the systems, environments, deliverables and timelines in writing before work starts, so the boundary is set in advance. For high availability, the scope should name the Mautic release and components covered, the web, cron, queue, database, storage and caching layers, the environments to build, the failure scenarios to test, the documentation to hand over and the integrations that are in or out. It should also state what is excluded, such as third-party email sending service changes or CRM configuration, and how change requests are priced and approved. Ask for the list of acceptance tests in the scope, because they define when the work is complete.
How DeployOpen scopes, builds and hands over Mautic high availability
DeployOpen approaches Mautic high availability as a written, fixed-scope engagement inside your own infrastructure. We start from how your web, cron and queue workloads, database and file storage will behave under your real contact volumes, then build, test, document and hand over the result.
How we scope
- Inventory expected contact volumes, segment counts, campaign load and email send patterns before choosing a topology
- Confirm Mautic release line, PHP version and database engine against the published requirements for your target release
- Agree in writing which components are in scope: web nodes, cron host, queue workers, database, shared storage and caching
How we build
- Separate web requests, scheduled cron jobs and messenger queue consumers onto distinct, independently scalable processes
- Stagger segment, campaign and broadcast cron schedules and test their behavior under concurrent load before go-live
- Configure shared file storage, session handling and database replication or failover, then document each component's recovery path
How we hand over
- Deliver architecture diagrams, configuration records, runbooks for failover and cron recovery, and sizing notes
- Walk your platform and operations staff through failover tests and the monitoring signals they should watch
- Document open decisions and the Mautic upgrade steps that must be repeated across the high availability layout
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope build is handed over
- Re-test the high availability layout when Mautic moves to a new major release or when contact volumes change materially
- Confirm support terms, response expectations and included testing in the written scope before work begins
