Mautic Installation: Mautic Hardware Requirements

The adequate amount of hardware resources you need for your Mautic installation will depend on the Mautic features you’ll be using.
There’s no silver bullet when it comes to Mautic performance, but we will try to provide a guide on how to calculate the requirements for your own, self-hosted, Mautic installation.

Find out how to accurately forecast the Mautic Requirements for your next Mautic installation and prevent Mautic from running slow or completely freezing.

As a Mautic Ops and Systems Architect, I have encountered several perfectly OK Mautic installations that were just terribly slow (to the point of not being usable anymore) but otherwise perfectly OK, what usually happens is that the new server is gauged accordingly to some basic rules, like 1GB of RAM for every 10K users. This way of forecasting your Mautic hardware requirements is too simplistic and will probably lead to either a slow-running Mautic installation or a too big invoice.

TL, DR:
– Minimum recommended: 2 CPU – 4GB RAM
– In most cases, Mautic will require about 2GB to 4GB of RAM per CPU core. So try to use High Memory instances where available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/memory-optimized-instances.html
Most top Cloud VPS providers sport this kind of instances and they usually have faster than average CPUs (more modern).
– As a rule of thumb, have at least as much RAM as the size on disk of your database, plus whatever RAM your OS and stack needs to run.
– If you use a Cloud VPS, such as AWS EC2, you can double your RAM and CPU with a few clicks, so don’t worry too much about it!
– If you are going to use bare-metal for Mautic, take the time to read every detail on this post.

How many resources does my Mautic instance need exactly?

There are several apps/services and Mautic features that need resources, each of these might need just very few or a lot of resources depending on which Mautic features are you using and how intensively you are using those features.

Here are the main resource-hungry parts of a Mautic Deployment:

– Campaigns: Simple campaigns execute very fast, the more complex your campaigns the more resources you’re gonna need.
A campaign is run/launched as a cron job.

– Tracking: The impact that Tracking will have on your resource needs will vary greatly depending on how much traffic you get on your website(s)

– Mautic UI: Contrary to your website, the Mautic interface is going to be used by very few people, hence it has little impact on your resource needs. However, it has a huge impact on how Mautic users perceive Mautic speed. Most of the time, the users will only be aware of Mautic running too slow after it starts affecting the graphical interface.

– Sending emails: Sending emails is CPU intensive, usually, CPU power is not an issue with Mautic, but if you plan on sending lots of emails per second, you might want to add some extra CPUs.

– Cron Jobs: Each cron job will consume ONE entire CPU/Thread for a period of time, it might be a long or short period depending on what the cron job is doing, how many contacts do you have and the type of operation it is performing.
We don’t really need to be too worried about this, as long as there is one free CPU available for each cron at the time of its execution, that’s why we need to carefully plan our cron timings.

– Database: Your database will be your top resource consumer, Mautic is really database intensive and if you enable website tracking, your DB will rapidly grow over time, the bigger your database the more RAM and CPU you will need. CPU is usually not a concern with Mautic, so concentrate on your RAM Needs.

– PHP: Even with caching enabled, PHP does not consume lots of RAM, it is more of a CPU bound process, in most cases, you will have abundant CPU power available to you, so this shouldn’t be a concern.

– Caching: Caching is a VERY RAM INTENSIVE task. You can run Mautic without caching, however, it will never feel snappy and most probably performance will degrade fast as your database grows.

My Mautic is getting really slow!

You are a lucky person! Slow = it is still running = not broken. This means you did a good job setting up your Matic instance and now you just need to do one of these things:

– Purge your database of old data you don’t have a use for.
– Just double (or quadruple) your RAM.
– Or maybe a little bit of both!

A more accurate way of forecasting your needs:

Couldn’t we try to define a unique unit of measure?

Like finding out how many of X feature equals 1 CPU, then find out how much memory is needed to run that very same X feature, then build a table would be much more simplified and anyone could calculate for a given number of users, traffic, emails, etc…

Yes! So here below is a way to more accurately calculate your hardware needs, instead of basing it on just # of contacts, you can now use various parameters, relative to the usage you plan on giving to your Mautic installation. Keep in mind this is not science, just approximation, so try to be generous, it’s always good to err on the plus side!

# of contacts	< 50K			<250K			<1MM			>2MM
	RAM	CPU		RAM	CPU		RAM	CPU		RAM	CPU
Sending emails via API	1	0.5		2	1		4	2		8	3
Sending emails via SMTP	1.5	0.75		3	1.5		6	2		6	3
Sending emails with Mautic queue	1.5	0.75		3	1.5		4	2		6	3
Few or simple campaigns	1	1		2	2		4	3		6	4
Many or complex campaigns	2	2		4	3		6	4		8	5
Email Tracking	1	1		2	2		4	4		8	6
Tracking anonymous visitors	1	1		4	2		6	3		8	4
Forms	1	0.5		3	1		4	2		6	3
Landing pages	1	0.5		3	1		4	2		6	3
Dynamic content	2	1		4	2		6	3		8	4
Webhooks	1	0.5		2	1		4	2		6	3
PLUGINS:
CRM (Salesforce, Suite, Zoho, vTiger)	1	1		2	2		4	3		8	4
Zapier	1	0.5		2	1		4	2		6	3
Social Media	1	0.5		2	1		4	2		6	3
SMS	1	0.5		2	1		4	2		6	3
			– – – – –			– – – – –			– – – – –

As an example, let’s say you want to use Mautic for email mostly, you won’t have any website tracking enabled and forms and landing pages are not created or tracked by Mautic, but you want to track email activity and build some basic campaigns for DRIP (Basically this would be a Mailchimp alternative).
The data you are going to use comes from a CRM.
Also as an example, let’s say you’re gonna have about 45K contacts in your Database.

		< 50K
		RAM	CPU
Sending emails via API		1	0.5
Simple campaigns		1	1
Email Tracking		1	1
CRM (Salesforce, Suite, Zoho, vTiger)		1	1

Total: 4GB of RAM and 3,5 CPU Threads (virtual CPUs)

Now let’s see an example where I want to use Mautic to its full potential:

		< 50K
		RAM	CPU
Sending emails via API		1	0.5
Complex campaigns		2	2
Email Tracking		1	1
CRM (Salesforce, Suite, Zoho, vTiger)		1	1
Tracking anonymous visitors		2	1
Forms		1	0.5
Landing pages		1	0.5
Dynamic content		2	1

Total: 11GB of RAM and 7,5 CPU Threads (virtual CPUs)

That’s for the same 50K Contacts!

Takeaways, tips, and recommendations:

– As a generic recommendation, try to round up RAM while you can usually safely round down CPUs.
– Even if you have just 10 or 20K contacts, try to provide Mautic with at least 4GB of RAM, it will work with 2, but the price difference is so small that its not worth it going below 4.
– Even if you have just 10 or 20K contacts, try to provide Mautic with at least 2 CPUs, a cron job can take over one CPU for a few minutes, and during that period, your Mautic GUI would become very sluggish. The price difference is so small that its not worth it going below 2.
– Tracking user activity on your website is really hard to forecast, you might have just 5K contacts but 1MM visitors on your website or 1MM contacts but just 100K visits a month, make that part of your calculations too.

Is there a simpler way?

Calculating the Hardware requirements for Mautic can get complex, however, after many deployments of all sizes, I found that:
As a rule of thumb, have at least as much RAM as the size on disk of your database, plus whatever RAM your OS and stack needs to run.
The only problem is, it’s really hard to know what your DB size will be until you start using Mautic for yourself.

That’s too much RAM, too expensive!

If your DB is 160 GB and you can’t afford that much RAM, consider using as fast as possible, local (to your VPS, not networked storage) NVMe drives so your database can read and write to them and use less RAM. I do not recommend this approach, at all, especially not with the regular block storage devices provided on any cloud service as those are always networked devices, there are some instance types with dedicated drives on the instance, however, these are usually volatile, which is a terrible idea for a database. If you need your database on disk, try to get yourself some bare-metal instances or a dedicated VPS.

One single VPS vs Multiple servers:

Or all in one box vs separated DB host:
In a next article, I will try to go over the differences in running the Mautic database on the same VPS as Mautic or in separated VPS and will review the advantages and cons of using Database services as RDS or Aurora.

So make sure to bookmark this blog and pay a visit now and then!