we currently run a super outdated Mautic version (3.1.2) on a Bitnami stack hosted on EC2. It worked fine until recently, when we got more emails to send out and stumbled upon issues with our disk space being eaten up because the mail queue caused overflows. We also never had a proper database backup solution (shame on us), so we relied on saving the DB and the whole instance manually from time to time.
I know that’s a sub-optimal setup, so I want to change this, by moving that instance to a fresh EC2 instance, including the current database contents and setting up SES properly, so these overflows won’t happen anymore. I know that Mautic offers a hosted solution, but the price tag is too high for our startup, unfortunately. Maybe we cann afford that later.
Are there any tutorials out there describing a “best practice” for a solid EC2 self-hosted setup?
Mautic is only a glorified PHP web app. You could use any PHP web app tutorial and replace mentions of the other app with “Mautic”.
The key for a fast and reliable server is always the servers’ configurations. It need to be based on the underlying hardware.
Anyways, there goes what you need to focus on: a fast CPU and fast storage.
You could use for a control panel such as DirectAdmin to make it easier on you in regard to the server install, configuration and management.
About the CPU and RAM:
PHP is single-threaded. Each visitor will take one thread. And each PHP run will require RAM.
So, depending on your traffic, you may need more CPU threads and RAM.
Other than that, this is how I’m installing it on any web server:
download the archive
unzip it
create a DB schema w/ the user/pass
and point your browser to the domain used for your install.
the installation is usually relatively easy - I’ve just done one on a EC2 recently.
The key is really to get the server right. Then Mautic is simple.
Depending on your requirements, it’s best to start with a vanilla Ubuntu LTS or something similar and a standard LAMP setup + NPM.
Scope wise, that thread changes then to a server thread then, rather than a Mautic one.
If you’ve been on Bitnami, do you need to stick to a dockerized setup?
Docker is fine, if you don’t mind the additional layer of complexity and keep things secure and updated
As far as I understood newer Mautic versions, it’s not as simple as dropping Mautic into a LAMP server anymore. They recommend this composer thing, and there’s also a Docker option. So I was wondering what the best way of implementing things on EC2 was.
Also, I had quite some issues setting up the SES queues right. It worked fine for some years, but then - when we reached about 9,000 users - Mautic all of the sudden took all of the available disk space. I am also looking for solutions to preven this (and just gladly found a very detailed YouTube video on this).
Besides, I have the challenge of upgrading the database. Here I am wondering if it’s better to do this step-by-step, i.e. from Mautic 3 → 4 → 5 → 6, or if this can be done directly.
Since I am not very familiar with PHP and MySQL (my world is NodeJS and Mongo), my hope was to find some best practices somewhere.
Thanks for your feedback and pointing me to the Recommended Project and Docker. I am wondering if the docker or the direct setup would be better on EC2, maintenance-wise. Also, if it was better to run the database on the same machine or maybe on RDS instead. In other word, I am basically looking for best practice experiences from people who already set-up their Mautic systems on AWS.
Also, some of my questions are not purely related to the pure server setup: I am also wondering how to migrate my existing 3.1.2 database (in one go, or gradually?) and how to setup the SES queue so the overflows we had experienced won’t happen anymore. For the latter, I found a pretty good set of YouTube videos yesterday, by a guy named Joszef.
Composer is a simple PHP script. A WordPress equivalent would be the wp-cli tool.
How to install composer:
Download the PHP script to your web server, set the exec bit on the file, and use it (you don’t need to be root - and shouldn’t be anyways - in order to do this. That’s one of the best practices).
There’s a huge advantage/PRO on why doing it that way instead of deploying it at the server level:
Better control over the version (i.e. an older version may be required for an older web app version, and vice versa - which is actually the case for older Mautic versions).
About the update process, yes, you are correct. Going through each steps/versions is the proper way to update it.
But… You’ll ran into a problem when proceeding that way:
Mautic does expect and require different PHP versions depending on the Mautic version.
**And don’t forget to flush your cache in between updates and/or bumps.
