I’d first heard of Mautic on the first day of my internship with InboundRx (and truth be told that’s the first time I’d heard of marketing automation – I’ve worked with web analytics and email marketing campaigns, but the idea of setting stages and points for your participants and having software facilitate the process flow was something that lay outside my loop until then). The idea was to use this as an alternative to Hubspot which is regarded as the proverbial Cadillac of such services (with features and price tag to go with that), and we were tasked with customizing this open source tool with modified branding and launching an instance of it on the cloud.
No-Go, Daddy
First we tried a local installation with MAMP. Great, I can follow directions and have it running on my MacBook. Next, on a Cloud 9 workspace. Then the first brick wall of publishing this app on Heroku. It took very little digging to discover that Mautic doesn’t support PostgreSQL (and Heroku doesn’t do MySQL), so no go. Next, a GoDaddy Virtual Private Server. No, Daddy, no. Upgrading to the required version of PHP was a mild pain in the rear (and trying to get PHP7 installed on their VPS was an extreme pain in the rear), and then trying to configure outbound email delivery that didn’t deliver everything as spam was as fruitless. Lesson learned: don’t try DIY when doing bulk mail.
Sailing the Open-Source Seas of Cheese
Even trying to work with the platform once it was launched (on wobbly legs) was a trial. Importing 8,000 contacts required some heavy massaging and eventual breakup of the CSV file into more manageable (or less crash-prone) chunks of 1,000. And the default pagination of 100 line items proved to be yet another pain in the rear for site admins who wanted to bulk-assign thousands of contacts into Segments and Campaigns. I’d managed to modify the PHP code to allow up to 500 items in a bulk operation, which resulted in my first (pending, probably not going to go through) pull request to an open source project.
In the meantime, I’d installed an instance of Mautic on a Digital Ocean Droplet for my own nefarious purposes, with greater success (or fewer faceplants) than with GoDaddy. But then I don’t have 8,000 folks in my contacts list. Yet.
You Can’t Spell “Awesome” without “AWS”?
Over the past couple of weeks, I’d started working with Amazon Web Services, and in particular with their EC2 virtual machines. I’d launched InboundRx’s new website on an EC2 instance, and I was curious as to the lower limit of an instance size that could support Mautic. Starting with an Ubuntu/LAMP Amazon Machine Image that I’d set up for future WordPress sites, I spun up (insert a merry twirl of a magic wand here) a t2.nano instance (insert sage shaking of heads going “that ain’t gonna work, son, that there nano’s too small!”) and installed Mautic. So far so great.
As an aside, I had to get myself up to speed on setting up key pairs for SSH access, which also came in handy in my later forays onto Google Cloud Platform, but I digress.
Cloud Rockets in Flight, APM Delight
Right around that time (a whole week-ish ago?!), I’d started mucking around with New Relic’s Application Performance Management tools (this is what happens when one attends a few Meetups in New Relic’s offices and asks the obvious question of what do these folks do), and while my initial install of the APM PHP agent was easy-peasy and uneventful (a Digital Ocean Droplet doing triple-duty with Drupal, WordPress, and Mautic), I figured I’d use the APM to see if I could get any more insights into a low power (t2.nano doesn’t get much lower!) install of Mautic tasked with importing thousands of contacts.
The PHP agent requires root access in order to install, which means (a) no-go on the GoDaddy VPS and (b) no-go on Media Temple’s Grid Server, but awesomesauce on AWS. I felt a bit like those automotive crash test engineers in that I was deliberately putting load on the application server to see whether and how it’d buckle and crumble. I definitely wasn’t disappointed, as there were plenty of hangs and crashes (nothing fatal that required calling Mulligan to re-do everything from scratch!), and having to tweak php.ini while using Mautic’s, MySQL’s, and NewRelic’s logs to cross-reference and triangulate errors was actually a lot of fun.
Probably the biggest lesson learned is that the mere 0.5 GiB of memory will cause MySQL to keel over a few times a day. I’m sure this is going to poleaxe the server’s responsiveness, but setting up a swap file seemed to alleviate that multiple-times-a-day MySQL crash.
That said, on one hand, I think a t2.nano can handle Mautic, but I do wonder about this CPU Credits per Hour thing and whether I’d end up running out of them at some point on such a small EC2 instance. #weshallsee
Deliver This Mail, ‘Cos Amazon SES So!
When we tried hosting Mautic on GoDaddy, we tried using the host VPS as an SMTP relay to send outgoing emails. Spam by any other name is still canned meat, or so the saying goes, and more often than not the outgoing marketing emails landed in the junk bin. Reverse DNS helps to an extent, and I suspect that setting up DKIM and other identity authentication would have helped as well. But since I was using AWS, I figured why not try their Simple Email Service?
Verifying a domain was quite straightforward in making a few DNS zone file tweaks, and verifying email addresses was even simpler. The biggest holdup (and relatively speaking this seems minor in retrospect) was getting Amazon to get our account out of the “sandbox” to allow us to actually send mail (as opposed to the severely limited delivery parameters of the sandbox). While we’ve yet to actually do a full-scale email campaign with the AWS setup, initial experiments are quite promising.
That said, the next instance of Mautic on AWS is going to use a bigger machine with more hamsters at the wheel.