Skip to content

KISSmauticDKR 7.2.2 – Simplest Mautic 7 Docker Container.

Mautic as a one-docker-container-has-it-all (including the database) aiming at the simplest possible Mautic deployment, with just one run command. Now on Mautic 7.2.2, Debian 13, PHP 8.4 and MariaDB 11.8.

KISS-Mautic containers are an all-in-one, batteries-included, single-container implementation of a full Mautic server. One docker run, no compose file, no orchestration, no external database required.
The current version is based on:

– Debian 13 (Trixie)
– MariaDB 11.8 LTS
– Apache 2.4
– PHP 8.4-FPM
– Mautic 7.2.2
– Plus everything Mautic 7 wants: ~20 PHP extensions, ImageMagick, GraphicsMagick, cron, and the Mautic cron jobs already installed

What changed since 6.0.2

Debian 12 → 13. PHP 8.4 is the Debian 13 default, and both the Sury PHP repository and the MariaDB repository resolve their codename from lsb_release -sc, so the base image had to move for the rest to follow.

  • MariaDB 11.4 → 11.8. Not a preference. MariaDB 11.4 publishes no trixie repository at all — dlm.mariadb.com/.../11.4/repo/debian/dists/trixie/Release returns 404. 11.8 does, and Debian 13 ships 11.8.6 natively.
  • ntp is gone. Replaced with ntpsec.
  • software-properties-common is gone. No replacement needed.
  • libhashkit2 was renamed to libhashkit2t64 by Debian's 64-bit time_t transition. The old name has no install candidate on trixie.

A bare Debian 13 image also ships without curl, wget, gnupg or a CA certificate bundle. The Dockerfile installs those first, before it touches any third-party repository key — otherwise the repository TLS cannot be verified and every apt update afterwards fails.

The database is still pre-populated

The database is pre-populated with a user, a Mautic database and the Mautic DB schema, so you don’t have to go through Mautic’s installation wizard. That was the whole point of the KISS approach and it has not changed.

Note that Mautic 7.2.2 ships 119 database migrations, up from 65 in 6.0.2. That is a substantial schema jump, and it is why the 7.2.2 image ships its own dump rather than reusing the 6.0.2 one.

docker run -d --name KISSmauticDKR-722 -p 8080:80 martechws/mautic:7.2.2

Takes a few seconds to launch, then go to http://localhost:8080 and log in.

b) Clone from repo and build locally

Or download the components and build the image yourself, which also let's you modify it.

git clone https://github.com/Martech-WorkShop/KISSMauticDKR

docker build -f 7.2.2.Dockerfile . -t KISSmauticDKR:7.2.2

docker run -d --name KISSmauticDKR-722 -p 8080:80 KISSmauticDKR:7.2.2

Then open http://localhost:8080, and to get a shell inside:

docker exec -ti KISSmauticDKR-722 bash

Your default credentials

MAUTIC_DB_NAME=mautic_db
MAUTIC_DB_USER=mautic_user
MAUTIC_DB_PASSWORD= define it with -e at runtime
MAUTIC_LOGIN=
MAUTIC_LOGIN_PWD=

The Mautic login and password are set at build time and are not yet parametrized at runtime. If you want a different database name, user or password, pass them when you start the container:

docker run -d -e MAUTIC_DB_PASSWORD=my-mautic-password --name KISSmauticDKR-722 -p 8080:80 martechws/mautic:7.2.2

Why one container?

The official Mautic images are excellent for complex deployments and separate concerns properly, which is exactly what you want for Kubernetes. But for a developer or a geeky marketer who wants to give Mautic a quick spin, they are serious overkill: you first have to understand how the images operate, then prepare the infrastructure, before you see a login screen.

KISSmauticDKR deliberately breaks the one-service-per-container rule. That means the Dockerfile is more complex than it would otherwise be, and the image is heavier than it needs to be, and there are a great many comments in it. All of that is on purpose. Here, KISS means simple and easy for the person deploying it.

The Dockerfile and helper script are heavily commented so you can read what is happening and change it if you feel like it. This repository hosts them:
https://github.com/AI-Vectoring/KISSMauticDKR

Container or installer?

This container assumes certain infrastructure is available, like a proxy server with SSL termination and a docker capable host (for example with Kubernetes).

When you want the simplest possible way to run Mautic, there's an automated script that does not require docker or a proxy: AutoMautic.
It installs Mautic 7.2.2 on a fresh Debian 13 VPS in about four minutes and obtains an SSL certificate with Certbot.

Intended uses

  • A simple way to test Mautic, pull & play.
  • A live overview of Mautic 7.2.2’s requirements.
  • A starting point for Mautic code exploration and tinkering.
  • A way to play with Dockerization, Dockerfiles and image creation.

It is NOT meant as a production-ready image.

If you have ideas on how to make it clearer or simpler, post a comment below, send me an email, submit a PR or open an Issue.

Yosu Cadilla

Yosu Cadilla

My name is Yosu Cadilla, a Systems Analyst and Platform Engineer for mktg.dev I discovered Mautic in 2017 and since have specialized in: – Running Mautic for Marketing Agencies. – Running large Mautic instances, sometimes with millions of contacts. – Helping companies build and optimize their (usually Mautic) runtime infrastructure. If you are planning on deploying Mautic for your Marketing Agency, or you have a large Mautic Instance… Let's have a chat! [email protected]

Comments

Subscribe to mauteam.org

Join the newsletter and get the latest posts delivered straight to your inbox.

[email protected] Subscribe