MAILWIZZ • VPS

How to Install MailWizz on Ubuntu VPS: Complete Guide

By Abhishek Sharma · Published 2026-08-21 · Last reviewed 2026-08-21

Abhishek SharmaEditor & email infrastructure writerView author profile →

Quick answer: Install MailWizz on a Linux VPS with PHP, MySQL/MariaDB, a web server, HTTPS and the scheduled jobs MailWizz needs for campaigns, bounces and maintenance. This guide focuses on the installation layer and deliberately separates application setup from email delivery, authentication and reputation.

Before you start

A VPS installation gives you more control than shared hosting, but it also makes you responsible for the operating system, PHP, database, web server, TLS, backups and scheduled jobs. The important distinction is that MailWizz is the application layer; it still needs a delivery server or provider and correct domain authentication before it becomes a production sending system.

Important: installation instructions can change between software releases. Use the version bundled with your license and compare the vendor's current requirements before copying commands into production. Where this article uses an adapted Caddy or Docker pattern, it is clearly labeled rather than presented as vendor certification.

What you need

A supported Linux VPS with root or sudo access.
A domain or subdomain pointing to the VPS.
A current MailWizz license and the installation package downloaded from the vendor.
PHP and required extensions matching the MailWizz release.
MySQL or MariaDB supported by that release.
Nginx or Apache; MailWizz publishes an Nginx/PHP-FPM example.
A delivery service such as an SMTP relay, Amazon SES, or your own properly configured MTA.

Architecture

Domain → Nginx/Apache → PHP → MailWizz → MySQL/MariaDB → SMTP or delivery service

Keeping these layers separate makes troubleshooting easier. If the web dashboard works but campaigns do not send, the problem may be in cron, the queue, the delivery server or the provider rather than in the web server. Conversely, a 502 or 500 error normally belongs to the web/PHP layer.

Step-by-step installation

1. Prepare DNS and the server

Create an A/AAAA record for a hostname such as mail.example.com and confirm it resolves to the VPS. Log in over SSH, patch the operating system, create a non-root administrative user and enable a firewall. Keep the public application hostname separate from any hostname used for SMTP or bounce infrastructure.

2. Install the web stack

Install the web server, PHP-FPM and the PHP extensions required by the exact MailWizz release. Do not copy an old PHP version from a tutorial just because it worked years ago. Check the package's current requirements first, then verify the active PHP version with php -v and the loaded modules with php -m.

3. Create the database

Create a dedicated MySQL/MariaDB database and application user. Grant that account access only to the MailWizz database rather than using the database root account from the application. Record the hostname, database name, username and password because the web installer will request them.

4. Upload and install MailWizz

Extract the vendor package and upload the contents of the appropriate application directory to the document root or a dedicated virtual host. MailWizz's official install notes say to point the browser at the install endpoint and remove the install directory after installation. Treat that cleanup step as mandatory.

5. Configure Nginx or Apache

If using Nginx, use the vendor's routing pattern rather than a generic PHP-site configuration. MailWizz has separate frontend, customer, backend and API application areas, so rewrite handling matters. Test the configuration before reloading Nginx. If you use Apache, confirm the supplied .htaccess/routing behavior is active.

6. Enable HTTPS

Use a publicly trusted certificate and force HTTP to HTTPS. Check that the application URL, tracking URL and any public subscription endpoints use the intended HTTPS hostname. Never leave the administration interface exposed over plain HTTP.

HTTPS reminder: Use a publicly trusted certificate and test redirects, assets, login and tracking URLs after enabling TLS.

7. Configure cron jobs

This is one of the most important steps. MailWizz's official documentation says cron jobs are essential for sending and maintenance. In the backend, open the Cron Jobs List and add the commands for your installation path. The current official list includes campaign sending, transactional sending, bounce handling, feedback-loop processing, log processing and hourly/daily maintenance tasks.

Cron reminder: Scheduled email applications are not complete when the dashboard loads. Confirm the scheduled jobs actually execute and produce expected logs before sending a real campaign.

8. Add delivery and bounce servers

After installation, configure delivery servers and bounce/feedback-loop handling. MailWizz's getting-started documentation explicitly places these tasks after cron configuration. Use a delivery provider or MTA that you control and authenticate your sending domains correctly.

9. Test before production

Create a small test list and send a controlled message. Confirm the message arrives, SPF/DKIM/DMARC behave as expected, tracking works, unsubscribe links work and scheduled jobs actually run. Test bounce processing separately instead of assuming that a successful test message proves the entire installation is healthy.

Post-install configuration

Once the installer finishes, resist the temptation to immediately import a large list and launch a campaign. First configure the sending layer, domain authentication, bounce handling and unsubscribe behavior. Your application can be perfectly healthy while the email infrastructure is not ready for production.

1. Configure the sending service

Use a delivery service or MTA that is appropriate for your sending volume and compliance requirements. Record the exact SMTP/API endpoint, credentials, region and encryption settings. Never publish credentials in screenshots, tutorials, public repositories or support tickets.

2. Authenticate the sending domain

Publish the SPF, DKIM and DMARC records required by your chosen delivery service. If the provider gives you DKIM CNAME records, use those exact values. Avoid creating multiple conflicting SPF records. Start DMARC in a monitoring mode when you are still mapping legitimate senders, then tighten the policy once authentication is verified.

3. Configure bounces and complaints

A campaign system should not keep treating permanently failing addresses as healthy subscribers. Configure the application's bounce/complaint workflow and monitor the resulting logs. If your provider exposes feedback-loop events, connect them where the application supports it.

4. Test with a small list

Send a controlled test to addresses you own at more than one mailbox provider. Check authentication results, rendering, unsubscribe behavior, tracking, bounce handling and queue processing. Only after the end-to-end workflow passes should you increase campaign volume.

Common mistakes to avoid

Installing a PHP version without checking the application's current compatibility requirements.
Using the database root account inside the application.
Making the entire application directory world-writable.
Putting passwords or AWS credentials into a public repository.
Assuming a successful login means scheduled jobs are working.
Sending a large campaign before SPF/DKIM/DMARC and bounce handling are verified.
Treating the application as the email delivery server when it actually relies on an external SMTP/API provider.
Skipping backups before upgrades.

Troubleshooting

404 errors on /backend or /customer

Check the web-server routing rules first. MailWizz's official Nginx example explicitly routes backend, customer and API requests to their respective PHP entry points.

502 Bad Gateway

Check PHP-FPM is running, verify the FastCGI socket or port in the web-server configuration and inspect the PHP-FPM log. A 502 usually indicates an upstream PHP process/socket problem rather than a MailWizz database problem.

Campaigns do not send

Check the MailWizz cron list and run the relevant command manually from the command line. Then inspect the delivery server configuration and queue. MailWizz's documentation makes clear that cron is essential for sending.

Bounce processing does not work

Confirm the bounce server credentials and that the bounce-handler cron job is actually executing. Also verify that the mailbox/provider is accessible from the VPS.

Slow dashboard or campaigns

Check CPU, RAM, SSD performance, database configuration and campaign queue settings. MailWizz's performance documentation specifically calls out server resources, storage, database tuning and queues.

Security checklist

Use SSH keys where possible and disable unnecessary remote access.
Keep the operating system, PHP runtime and application patched.
Use a dedicated database account.
Keep MySQL private unless remote access is explicitly required.
Use HTTPS for the administration interface.
Protect application configuration and secret files.
Back up the database and uploaded/application data.
Test restoring a backup rather than assuming it is usable.
Monitor disk, RAM, CPU, queue depth and application logs.

When should you choose this installation method?

Choose a VPS when you want direct control over PHP, the database, cron, filesystem permissions and the surrounding email infrastructure. It is a strong fit for operators who expect to tune the application or connect it to their own SMTP/MTA stack. The trade-off is operational responsibility: you must patch the OS, secure SSH, back up the database and monitor the server yourself.

Final checklist

☐ DNS resolves to the server
☐ Supported PHP/runtime is installed
☐ Database and dedicated user created
☐ Application installer completed
☐ Correct file permissions applied
☐ HTTPS works
☐ Cron/worker jobs execute
☐ Sending service connected
☐ SPF/DKIM/DMARC verified
☐ Bounce/complaint processing tested
☐ Unsubscribe tested
☐ Backup created and restore plan documented
☐ Small end-to-end test campaign completed

Related installation guides

Sources & references

This guide uses the following vendor or platform documentation. Where a deployment method is an adaptation rather than vendor documentation, that distinction is stated in the article.

Editorial note: This guide was reviewed on 13 August 2026 for structure, source alignment and internal consistency. Software vendors can change requirements, commands and supported versions; verify the current release documentation before production deployment.