Self-Hosting Mautic with Docker

Q: Which Docker tag should I use?

Pin a tested tag. This guide uses mautic/mautic:6.0.9-apache because it reached a working login page locally. The current 7.x source and image line should be tested carefully before production use.

Q: Where are uploads and generated assets stored?

In the mounted media/ volume, mapped to /var/www/html/docroot/media in the container.

Mautic is what you reach for when a newsletter tool is no longer enough.

It gives you contacts, segments, forms, landing pages, email campaigns, marketing automation workflows, tracking, reports, webhooks, integrations, and a plugin system in one self-hosted application.

That power comes with a more serious deployment shape than a small single-container app. Mautic needs a database, persistent media and config, cron jobs, and sometimes queue workers. Treat it like a real application stack, not a toy dashboard.

What is Mautic?

Mautic is an open source marketing automation platform. The current source tree is a PHP/Symfony monorepo-style distribution with domain bundles for contacts, campaigns, email, forms, pages, reports, webhooks, users, API access, marketplace plugins, and integrations.

The 7.x branch I analyzed contains 29 first-party bundles under app/bundles, bundled plugins under plugins, built-in themes under themes, Doctrine migrations, Symfony config, Twig templates, frontend assets, DDEV config, and devcontainer support.

Docker Compose

This compose file is pinned to the Mautic 6 image I verified locally to a working login page. Mautic 7 is the current source branch, but the 7.1.3-apache image trial on this host installed through the CLI and then hit a post-install login render error. See the trial notes below before changing the image tags.


services:
  mautic:
    image: mautic/mautic:5-apache
    container_name: mautic
    ports:
      - "8059:80"
    environment:
      - MAUTIC_DB_HOST=db
      - MAUTIC_DB_USER=mauticuser
      - MAUTIC_DB_PASSWORD=your_secure_password
      - MAUTIC_DB_NAME=mauticdb
      - MAUTIC_RUN_CRON_JOBS=true
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped
    volumes:
      - mautic_data:/var/www/html

  db:
    image: mysql:8
    container_name: mautic-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_root_password
      - MYSQL_DATABASE=mauticdb
      - MYSQL_USER=mauticuser
      - MYSQL_PASSWORD=your_secure_password
      - MYSQL_USER_HOST=%
    volumes:
      - mautic_db_data:/var/lib/mysql
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p${MYSQL_ROOT_PASSWORD}"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  mautic_data:
  mautic_db_data:

Create folders and an .env file:

mkdir -p db config logs media

cat > .env <<'EOF'
MAUTIC_HTTP_PORT=8080
MARIADB_ROOT_PASSWORD=change-me-root-password
MAUTIC_DB_DATABASE=mautic
MAUTIC_DB_USER=mautic
MAUTIC_DB_PASSWORD=change-me-db-password
TZ=Europe/Madrid
PHP_MEMORY_LIMIT=512M
EOF

Start the stack:

docker compose up -d

Open the web UI:

http://localhost:8080

On first boot, complete the installer in the browser or install from the CLI:

docker compose exec --user www-data --workdir /var/www/html mautic_web \
  php ./bin/console mautic:install http://localhost:8080 \
  --force \
  --db_driver=pdo_mysql \
  --db_host=db \
  --db_port=3306 \
  --db_name=mautic \
  --db_user=mautic \
  --db_password=change-me-db-password \
  --admin_firstname=Admin \
  --admin_lastname=Mautic \
  --admin_username=admin \
  --admin_email=[email protected] \
  --admin_password='change-me-admin-password'

Why the cron and worker containers matter

Mautic is not just request/response PHP.

Campaign timing, segment rebuilds, queued email sends, webhook processing, imports, monitored email, report exports, and maintenance work are console-command driven. If you only run the web container, the UI can load while automation silently does very little.

The official Docker image supports roles:

mautic_web serves the UI and public endpoints.
mautic_cron runs scheduled Mautic tasks.
mautic_worker consumes queues when workers are configured.

For a small lab instance, web plus cron may be enough. For heavier tracking or email workloads, workers become important.

Local Docker trial

I tested two image lines.

The current Mautic 7 stable image trial used mautic/mautic:7.1.3-apache with mariadb:11.4 on port 8086. The web container started and redirected to the installer. The CLI installer created the database schema, loaded fixtures, and created the admin user. The CLI reported:

Mautic 7.1.3 - app/prod

After install, /s/login returned HTTP 500. The Mautic log showed:

OverrideIncludeExtension::includeWithEvent(): Return value must be of type string, Twig\Markup returned

I then tested mautic/mautic:6.0.9-apache with mariadb:10.11 on port 8087. The CLI install completed, the CLI reported:

Mautic 6.0.9 - app/prod

and /s/login returned HTTP 200 with the login form. That is the working demo currently left running on this machine.

Persistent data

Back up these paths:

db/ for MariaDB data.
config/ for Mautic local config.
media/ for uploaded and generated media.
logs/ for application logs.

For production, use database dumps as well as filesystem backups. A raw database directory copy is not a replacement for a clean backup strategy.

Operational checklist

Put Mautic behind HTTPS.
Set the correct site URL during install.
Configure mail delivery with a real SMTP/API provider.
Keep cron jobs running.
Add queue workers when using async Messenger transports.
Keep plugins under control and update them carefully.
Monitor logs and failed jobs.
Back up the database and media volume.
Track Mautic’s supported release branches before upgrading major versions.

Useful CLI commands:

docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console --version
docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console cache:clear
docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console mautic:segments:update
docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console mautic:campaigns:update
docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console mautic:campaigns:trigger
docker compose exec --user www-data --workdir /var/www/html mautic_web php ./bin/console mautic:webhooks:process

Project links

Conclusion

Mautic is a serious self-hosted alternative to closed marketing automation suites. It gives you ownership of the database, campaign logic, forms, contacts, and tracking infrastructure, with enough extension points to adapt it to unusual workflows.

The tradeoff is operational weight. You need a database, HTTPS, mail delivery, cron, workers for larger installs, and a real upgrade plan. Start with a pinned image, verify the login and CLI, then only move to newer major versions after testing the exact image/database combination you intend to run.

Pair it with EMQX only if you are also building event-driven pipelines, Chatwoot for customer conversations, and n8n for glue automation around form submissions and lead routing.

FAQ

No. Email is a major part of Mautic, but the application also handles contacts, segmentation, forms, landing pages, campaigns, tracking, reports, webhooks, plugins, and API integrations.

Can I run only the web container?

You can for a quick look, but it is not enough for a useful deployment. Cron jobs and workers are part of the normal Mautic operating model.

Which Docker tag should I use?

Pin a tested tag. This guide uses mautic/mautic:6.0.9-apache because it reached a working login page locally. The current 7.x source and image line should be tested carefully before production use.

How do I log in the first time?

For the local Docker trial from this post, open:

http://localhost:8087/s/login

and use:

username: admin
password: Maut1cR0cks!

That password is only for the local demo. Use your own admin password for any real deployment.

Does Mautic need HTTPS?

Yes for any real deployment. The installer itself warns that HTTP breaks modern secure-cookie behavior for tracking use cases.

Where are uploads and generated assets stored?

In the mounted media/ volume, mapped to /var/www/html/docroot/media in the container.