Hosting Multiple Mautic Instances with Linux Containers

Agencies who need to host multiple Mautic instances for their clients have plenty of options for multi-tenant Mautic server architecture, so which one should you choose? Having no licensing cost as an open source product, Mautic is an attractive choice for agencies who want to resell a marketing automation platform as a SaaS as a recurring source of revenue.

Multi-tenancy means that the data is segregated between the customers on the infrastructure where you host Mautic. Each customer has a separate Mautic instance for their own domain, but the underlying virtual machine is shared with other customers.

Increase density & utilization of idle servers to reduce infrastructure cost.

Why is sharing the same virtual machine preferable to provisioning a new virtual machine for each customer, and using one VM per Mautic instance? It lowers your infrastructure costs by cutting down on the number of VMs (such as AWS EC2 machines, DigitalOcean Droplets, or Linodes) you need to host all of your customers’ Mautic instances. At any given time, most Mautic users leave the majority of the CPU & RAM allocated to their server idle – especially if their instance has a small number of contacts and campaigns. Increasing the number of Mautic instances hosted on a virtual machine lowers the per-instance cost of hosting.

Easily create, manage & maintain multiple Mautic instances.

When multiple Mautic instances are hosted on the same server cluster (i.e. group of servers), it also simplifies maintenance & monitoring, such as performing Mautic upgrades and patching server components such as Apache, NGINX, PHP, and MySQL to keep them up to date. With the Docker option, an admin panel is installed so that you can spin up brand new Mautic instances on your cluster, with pre-configured cron jobs, from a graphical interface. You can also monitor existing instances at a glance, without relying on SSH.

Achieve scale & increase reliability with self-healing containers.

As your Mautic hosting business grows, multi-tenant Mautic hosting can increase the scalability and reliability of your operation. With the LXC/LXD and Docker container options, multiple Mautic instances can share common components such as a load balanced database backend that can be self-managed, or managed by a service such as Amazon RDS. Each Mautic instance is more resilient than it would be on its own (as a single node), as the cluster has the excess capacity to absorb peaks in resource demand from any individual instance – such as during the high traffic of a major marketing campaign.

The Docker option leverages the Docker Swarm orchestrator to continuously monitor the state of the Mautic containers. If a Docker Swarm node goes down for any reason, the containers which were running on it are automatically redeployed to a healthy node – with no human intervention required. Docker Swarm is a comparatively simpler orchestration tool compared to Kubernetes, and it will meet the needs of most agencies or resellers hosting Mautic.

Comparison of Multi-Tenant Mautic Hosting Architectures

Hosting Mautic with Virtual Hosts 

Virtual hosts in Apache or server blocks in NGINX allow hosting multiple Mautic instances on a single web server using the target hostname in the Host HTTP header and Server Name Indication (SNI).

By pointing multiple domains (or subdomains) at the public IP address of a web server, you can host separate Mautic instances at each FQDN (fully qualified domain name). Each virtual host configured in Apache or NGINX’s /etc/ directory points to a different document root (folder) on the server, containing a unique Mautic instance. For each Mautic instance, a database & database user is created on the MySQL server which may reside on localhost, or a separate database node.

Hosting Mautic with LXC/LXD Containers

LXC/LXD Linux ContainersLXC containers are a lightweight virtualization technology that uses namespaces and cgroups to run multiple Linux systems with a shared, underlying kernel from the host machine. LXC/LXD is the predecessor to Docker containerization. Compared to a “full fat” virtual machine, the overhead of a LXC container is much lower, as each container does not have to run its own instance of the Linux kernel.

An LXC/LXD container behaves like a real virtual machine, but with better performance than nested virtualization. When an LXC container is created by lxc launch, it pulls an LXC image from the nearest image server for the operating system of choice. A single LXC host can run multiple LXC containers with different Linux distributions including Alpine, CentOS, Debian, and Ubuntu. Using the lxc exec command from the host, you can invoke a shell for any LXC container, akin to using SSH to connect to a VM.

From there, you can install Apache or Nginx and PHP-FPM to set up a Mautic instance. Each LXC container is assigned a private IP address and hostname in the format container.lxd on the internal bridge network (lxdbr0) that allows inter-container communication between LXC containers. For example if you use Redis to persist PHP sessions, you could use the IP or hostname of the Redis LXC container to set the session.save_path in php.ini.

A reverse proxy such as HAProxy or NGINX is required to route web traffic into the Mautic LXC containers. The reverse proxy can either run directly on the host machine, or itself within a LXC container. The LXC containers running Mautic should be set up as backends in haproxy.cfg with the subdomain specified on the server line. Traffic can also be load balanced between multiple LXC containers (replicas) for a single Mautic instance to assist with scaling. In this case, the webroot directory /var/www/html/ containing the Mautic files should be bind-mounted into each LXC container, by configuring a LXC disk device on the host, and setting the UID:GID of the folder and its contents to 100033 for www-data.

Finally, port 80 and 443 should be forwarded into the the HAProxy LXC container, by configuring a LXC proxy device on the host. This exposes port 80 and 443 in the container to the public IP address of the server, making it accessible over the Internet.

Hosting Mautic with Docker Containers 

Docker containers have become the dominant standard for app containers. Initially Docker was conceived as a frontend for managing the LXC runtime, but now uses its own runtime called RunC. The difference between an LXC/LXD container and a Docker container is that a Docker container should not be perceived as a lightweight VM, even though Docker containers share the host’s kernel through namespaces and cgroups – similar to LXC.

Instead of running a full operating system with a service manager like a LXC container, a Docker container stops as soon as the process specified in the CMD instruction of its Dockerfile is terminated. Generally a Docker container is associated with running a single service or app, in this case, Mautic.

Docker introduces an entire tooling around its ecosystem, at the center of it being the Dockerfile used to build container images. While a complete discussion of Docker is outside the scope of this article, the Dockerfile includes a base image (e.g. an OS image) and a series of instructions such as RUN and COPY defining what files should be copied to the container, and commands should be run when building the image.

The built image is pushed into a container registry such as the Docker Hub, which a Docker host then pulls from when it starts a container. A container is a running instance of a container image. All you really need to understand is that Docker provides you with a way to launch an application based on an “app template” with all of its dependencies, in a consistent manner.

Autoize can customize the Docker Mautic image for your company’s requirements including:

  • Rebuilding the image with more recent version of Mautic or PHP runtime
  • Optimizing performance of the Mautic container by tuning php.ini
  • Changing the execution interval of cron jobs, and maintenance jobs
  • Blocking update notifications from the Mautic dashboard
  • Adding custom themes or plugins into the container image
  • Whitelabeling tool to brand Mautic with custom branding, logos, and colors

In addition to customizing the Dockerfile and building a custom Mautic Docker image, we set up a highly available Docker Swarm with multiple manager (and worker) nodes, and customize the Docker stack files that you need for:

  • Health check containers for external load balancer
  • Traefik as edge proxy and for service discovery
  • Portainer and Portainer Agent for container management
  • phpMyAdmin for database management

Contact our team to discuss our multi-tenant Mautic hosting solutions.