How to Install Mautic Step by Step

Installing Mautic step by step comes down to 6 practical jobs: verify the server requirements, prepare the web stack, create the database, run the installer, fix permissions, and configure scheduled tasks. That matters because Mautic is an open-source, self-hosted automation stack for email, forms, landing pages, and contact management, so a weak install usually turns into broken writes, stalled jobs, or an admin area that looks healthy but does not actually process anything.

1. Check the server requirements before you upload anything

The cleanest starting point is to confirm the supported PHP, database, web server, Composer, and writable-path requirements for Mautic 7 before you touch the installer. In practice, this is the step that saves the most time, because Mautic will surface missing PHP extensions, incompatible versions, or write-permission problems very early.

What to verify first

Before downloading Mautic, make sure your environment covers these basics:

• A supported PHP version with the required extensions enabled
• A supported database engine and version
• A compatible web server
• Composer, if you plan to install that way
• Write access for the directories Mautic uses for configuration, cache, logs, and uploaded files

A common issue is starting with a server that can run ordinary PHP pages but not the full dependency set Mautic expects. What typically happens is the browser installer opens, passes a few checks, and then stops at the first missing extension or permission error.

Why this step matters in real deployments

Mautic is more sensitive to environment mismatches than a simple brochure site. It needs the filesystem, database, and scheduled background tasks to work together. If one layer is off, the install may complete but normal platform behavior will still be unreliable.

2. Prepare the server stack and database

On Ubuntu, a practical reference setup uses the Apache, MariaDB, PHP, Composer, HTTPS, and cron-based deployment pattern shown for Ubuntu 20.04. Even if your exact hosting stack is different, the order is the same: build the web stack, create the database, configure the site, secure it, and only then open the installer.

A practical order that avoids rework

Use this sequence:

• Install the web server, database server, PHP, and Composer.
• Create a dedicated database and database user for Mautic.
• Configure the site or virtual host so requests go to the correct Mautic location.
• Add HTTPS if the instance is reachable from the internet using certbot
• DKIM, DMARX, SPF, postfix, dovecot
• Mautic admin configuration

Platform behavior differences to expect

The installation work changes depending on how much of the stack you control.

• On a VPS or cloud server, you usually manage the web server, PHP configuration, database access, and cron yourself.
• On more abstracted hosting, those layers may already exist, so the job becomes matching Mautic’s requirements to whatever the platform exposes.

What typically happens on restricted hosting is that the install stalls on something small but essential – scheduler access, file ownership, or unavailable PHP extensions.

3. Put Mautic on the server

Once the environment is ready, follow the standard installation flow for downloading Mautic and completing setup through the installer. The two practical paths are installing from packaged files or using Composer, and both end at the same point: a browser-based setup that checks the environment and collects the core configuration.

Package install vs Composer install

Both methods work, but they behave a little differently in practice.

Package install

This is usually the simpler path when you just need to place the application files on the server and get the instance running. It fits manual deployments and environments where you are working directly in the web root or application directory.

Composer install

This is usually the cleaner option when you prefer dependency management from the command line. In practice, Composer-based installs tend to fit teams that already manage PHP applications that way and want a more controlled deployment workflow.

What to do once the files are in place

After the files are uploaded or installed:

• Confirm the application files are in the location your web server is actually serving.
• Make sure the web server user can read the files and write where Mautic needs write access.
• Open the Mautic URL in a browser.
• Let the installer run its environment checks before moving to the next screen.

A common issue is assuming the file copy itself equals a completed installation. It does not. Until the installer finishes and the environment checks pass, Mautic is only partially in place.

4. Run the browser installer carefully

The browser installer is straightforward, but this is the stage where small setup mistakes become visible.

The usual installer flow

What typically happens is:

• The installer checks your environment first.
• You enter the database connection details.
• You create the first administrator account.
• Mautic writes the configuration and finishes the setup.

If the environment check fails, stop there and fix the underlying issue first. Trying to work around it usually creates a second problem later, especially with permissions or missing PHP modules.

Database details that commonly trip people up

A common issue is entering database credentials that look correct but do not match the actual privileges granted to the database user. When that happens, the installer may fail immediately or appear to move forward and then stop when it tries to write or validate the connection.

In practice, using a dedicated database and user makes this easier to troubleshoot because you know exactly which credentials Mautic should be using.

5. Fix ownership and permissions before first real use

This is the part many installs skip because the login screen already works. One limitation is that a successful login tells you very little about whether the full application can write what it needs to write.

Why a Mautic install can look healthy and still be broken

What typically happens on Linux servers is that the file copy is done by one user, while the web server runs as another. The result is predictable:

• Cache rebuilds fail
• Configuration changes do not persist cleanly
• Logs do not update as expected
• Uploaded files or generated assets do not write properly

In practice, ownership problems often show up only after the first settings change, asset upload, or background task. That is why it is worth checking file access immediately after installation instead of waiting for the first campaign build.

What to verify after login

Right after you can access the admin area, test a few write actions:

• Save a configuration change
• Check whether logs and cache are updating
• Confirm the application can write uploaded content where expected

If one of those fails, treat it as a filesystem issue first, not an application issue.

6. Configure cron jobs immediately after installation

Mautic is not just a web interface. It depends on scheduled background processing. In practice, this is where many first-time installs fall apart: the admin area loads, but the automation layer never actually runs.

What typically happens when cron is missing

Without scheduled tasks, Mautic may appear installed but not operational. Background work does not happen on its own, which means time-based or recurring processes will not execute when expected.

A common issue is thinking the install is complete because the dashboard opens. For Mautic, a usable installation includes the scheduler layer, not just the browser layer.

A safer post-install sequence

After the installer finishes:

• Add the scheduled tasks your deployment plan requires.
• Confirm they run under the correct system user.
• Watch the timestamps and logs after the first run.
• Only then start building production workflows or importing real data.

This is especially important on servers where the shell user and web server user are different, because the task may run successfully from one context and fail silently from the other.

7. Test the installation like an operator, not just an admin

A Mautic installation is only really usable once the database, filesystem, web server, and scheduler are all working together.

Minimum checks worth doing right away

Run a small post-install test set:

• Log in with the administrator account
• Save a setting that writes to the database
• Perform an action that touches the filesystem
• Confirm a scheduled task executes
• Reopen the admin area and make sure changes persist

In practice, this catches most installation problems while the setup is still fresh and easy to roll back.

8. Common issues during a Mautic installation

The installer stops at the environment check

This usually points to a missing PHP extension, an unsupported software version, or a permission problem. Start with the requirements, not with the Mautic files.

The database connection does not validate

What typically happens is one of three things: the database name is wrong, the user does not have the right privileges, or the host value is not the one the database service expects.

The admin area loads, but settings or uploads fail

This is usually a filesystem ownership or write-permission problem. A common issue is assigning the files correctly for deployment but not for runtime.

Automations do not run after installation

This is almost always a scheduler problem. If cron is missing, misconfigured, or running under the wrong user, the platform behaves like a static application instead of a marketing automation system.

Share With Others