Why Enterprises Choose Mautic Kubernetes (K8s)

With our recent publication of the mautic-k8s helm charts and distribution, I think it's important to address the elephant in the room:

Why are enterprises choosing Mautic K8s?

It's simple. Usually by the time customers come to us they already:

• Have already seen the value of Kubernetes.
• Have a Kubernetes cluster they're using for production and management of other applications.
• Have plans to migrate their applications to Kubernetes.
• Have tried to run Mautic on Kubernetes themselves (hint: it's not easy from a fresh start in mautic/mautic or docker-mautic).

For those who are just getting started with K8s for the first time, it can be quite daunting. We don't necessarily recommend starting with Mautic—instead we recommend standardizing all of your infrastructure around one convention, Kubernetes or another.

The more important question is why should you deploy on Kubernetes?

If you've already built a case for it—meaning you understand the value of containerization, high availability management, failover redundancy, persistence, etc—then Mautic is just another application to reap the benefits of K8s.

Why Enterprises Choose Mautic

If you haven't made up your mind about Mautic yet, then here are some of the reasons why enterprises we know are choosing Mautic.

1. Cost per contact is astronomically less expensive. But there are caveats to your server's run rate depending on tracking pixel traffic, email throughput, and utilization of Mautic features which cannot be cached. I would never venture a statement to say "it is cheap". Just that running your own marketing automation "can be more economical". It's a business decision first, and a technology qualification second.
2. You own the data. In a world of AI/ML — some organizations are becoming extremely protective of where their data is hosted, how it is processed, and there are key concerns regarding country-specific data custody laws.
3. Deep technical integration capabilities. Possibilities with Mautic are not limited to pre-defined APIs. Ability to develop and deploy custom Mautic (Symfony) plugins offers a great amount of freedom. While I wouldn't say that the open source plugin community is burgeoning—there is a strong development community for deep integrations into custom platforms.
4. Ability to deploy federated Mautic instances. Separate instances per-brand and maintaining a central toolset seems critical to some Mautic customers. The business case for it is typically brand-oriented, federated by departments such as in higher education, or white-label services.
5. The organization has a focus on open source technologies. Drupal / WordPress, Matomo, and Mautic often go hand-in-hand. I am now beginning to see Unomi open source CDP as a piece of the conversation as well, as there are a handful of companies working on this already (message us to find out more!).

As with any investment into open source software, sufficient technical capabilities requires an investment into the team. Both to maintain the technologies, and to contribute towards its ongoing success. A case for Kubernetes is usually independent of Mautic, but with the complexity of scaling Mautic 2 and Mautic 3 — the value of collaborating around infrastructure as code is all the more enticing.

Read more about Facet's Mautic Development & Managed Services and submit the form, leave a comment, or DM us in the Mautic Slack community in #kubernetes to get in touch.