VPS Architecture for Hosting Mautic and Listmonk

Self-hosting your email marketing stack with tools like Mautic and Listmonk gives you something SaaS platforms rarely do: full control over data, deliverability, and costs. But that control only pays off if the underlying VPS architecture is thoughtfully designed. CPU, RAM, disk IOPS, SMTP rate limits, DNS records, IP reputation, queues, and cron jobs all come together to determine whether your campaigns land in the inbox or quietly disappear into spam. In this article, we will walk through how we at dchost.com think about hosting Mautic and Listmonk on VPS infrastructure: from choosing the right server layout, to sizing for list growth, to building a deliverability-first SMTP setup. Whether you are sending a few thousand messages per week or planning multi-million campaigns, the same core principles apply. We will focus on real-world, repeatable patterns you can deploy on a single VPS, a small VPS cluster, or even on dedicated and colocation servers as you grow.

Mautic vs Listmonk: What Their Architectures Expect from Your VPS

Before drawing any VPS diagrams, it helps to understand what Mautic and Listmonk expect from the server underneath. Both can run comfortably on a single VPS, but their stacks are quite different.

Mautic: PHP, Database, Cron and Heavy Web Traffic

Mautic is a PHP-based application that typically runs behind a web server like Nginx or Apache with PHP-FPM. It relies on:

• A relational database (usually MySQL/MariaDB) for contacts, segments, campaigns and logs
• Cron jobs or background workers for campaigns, segment rebuilding, and scheduled sends
• An SMTP relay or local MTA (Postfix, Exim etc.) to actually deliver outbound email

In practice this means your VPS must handle:

• Many concurrent PHP requests (UI, API, tracking pixels, webhooks)
• Frequent read/write queries to a growing database
• Regular CPU spikes during campaign processing cron runs

As your list grows, PHP and database performance tend to be the first bottlenecks, not raw SMTP throughput.

Listmonk: Go, Single Binary and Send-Focused

Listmonk is written in Go and compiled down to a single binary. It is designed to be fast and efficient out of the box and usually runs with:

• PostgreSQL as its primary database
• A built-in queue and worker system for email sends
• Direct SMTP connections to one or more outbound mail servers or providers

The resource profile is slightly different from Mautic:

• Lower CPU overhead per web request compared to PHP
• Very efficient concurrent SMTP sending, which can saturate your IP reputation before CPU or RAM if not rate-limited correctly
• Database write load concentrated around imports and campaign sends

This architecture means Listmonk can push very high send volumes from a modest VPS, but it also puts more pressure on SMTP design, rate limiting, and IP warmup.

Running Both on the Same VPS vs Separate Servers

It is technically possible to run Mautic and Listmonk on a single VPS: separate Unix users, virtual hosts, databases, and maybe Docker containers. That can work for labs, small agencies, or internal marketing teams with limited volume. However, once you start handling serious subscriber counts (100k+ contacts) or multi-brand sending, we generally recommend:

• Separate VPS for marketing apps (Mautic/Listmonk UI, APIs, tracking) and SMTP roles
• Optional separate VPS or managed database instance for MySQL/PostgreSQL if your campaigns become analytics-heavy

This keeps noisy SMTP workloads from impacting UI responsiveness or database performance and makes scaling each layer independently much easier.

Core VPS Architecture Patterns for Self-Hosted Email Marketing

Let us look at concrete architecture patterns we regularly see work well, from smallest to more advanced. You can implement each of these on our VPS, dedicated or colocation infrastructure at dchost.com, depending on your scale.

Pattern 1: Single VPS for App + DB + SMTP (Small Lists)

This is the starting point for many teams evaluating self-hosted email marketing.

• Components on the same VPS: Mautic or Listmonk, database (MariaDB/PostgreSQL), local MTA (Postfix), Redis (optional), Nginx/Apache
• Suitable for: up to ~20k–50k subscribers and a few tens of thousands of emails per week, depending on how aggressively you tune things
• Advantages: simple to manage, low cost, minimal network latency between app and database
• Risks: if SMTP gets blocked or overloaded, it affects the whole VPS; scaling up means vertical scaling (more CPU/RAM) rather than adding nodes

On a single VPS pattern, good isolation practices still matter. Use separate Unix users for the web app, database and mail stack, lock down SSH, and follow a basic hardening checklist such as the one we described in our VPS security hardening checklist for sshd_config, Fail2ban and no-root SSH access.

Pattern 2: App VPS + SMTP VPS (Deliverability-First)

As soon as volume and reputation matter, it is smart to separate the web app from the outbound SMTP role:

• App VPS: runs Mautic/Listmonk, Nginx/Apache, PHP-FPM (for Mautic), and the database
• SMTP VPS: runs Postfix/Exim as an outbound relay, with its own dedicated IPs and rate limits

Benefits of this split:

• Compromised mail IP or abuse issue does not directly affect your app's IP
• You can attach multiple IPs to the SMTP VPS for warmup and pool management
• You can scale app performance (CPU/RAM) independently from SMTP throughput
• You can later migrate SMTP to a dedicated server without touching the app layer

From a configuration standpoint, Mautic and Listmonk simply point their SMTP settings to the SMTP VPS (authenticated or IP-based relay). This pattern also aligns well with using different sending domains and IP pools for transactional vs marketing emails, which we covered in detail in our article on using separate sending domains for transactional and marketing email.

Pattern 3: App VPS + DB VPS + SMTP VPS (High Growth)

Beyond a certain point, database writes and reads become the main bottleneck, especially for Mautic:

• Large segment rebuilds
• Frequent opens/clicks tracking
• Many campaigns running concurrently

In that scenario, you can add a dedicated database VPS:

• App VPS: Mautic/Listmonk, web server, PHP-FPM/Go binary
• DB VPS: MariaDB/MySQL (for Mautic) or PostgreSQL (for Listmonk)
• SMTP VPS: dedicated outbound mail server(s)

This layout is a good stepping stone toward future high-availability setups (database replication, SMTP failover, and potentially multiple app nodes behind a load balancer). If you are already familiar with database offloading from web workloads, the logic is similar to what we discussed in our guide on when to separate database and application servers for MySQL and PostgreSQL.

Sizing Your VPS for Mautic and Listmonk

Capacity planning for an email marketing stack has three main axes:

• Contact/list size
• Peak send rate (emails per hour)
• Data retention and reporting depth

Below are starting points from what we see in real projects. They assume reasonable tuning and a modern Linux distribution such as Ubuntu or Debian.

Baseline for Evaluation and Small Lists (up to ~20k contacts)

• vCPU: 2 vCPU
• RAM: 4 GB
• Disk: 60–80 GB SSD/NVMe
• Traffic: 1–2 TB/month is often plenty at this size

This is enough to evaluate Mautic or Listmonk, run small campaigns, and integrate basic web tracking. For Listmonk, the same spec can handle surprisingly high throughput if you strictly control SMTP concurrency and IP warmup.

Growing Lists (~50k–200k contacts)

• vCPU: 4 vCPU (app), 2–4 vCPU (SMTP VPS if separated)
• RAM: 8 GB on the app node
• Disk: 120–200 GB, preferably on NVMe for better IOPS

At this stage, tuning matters more than raw specs:

• Enable PHP OPcache and tune PHP-FPM pools for Mautic
• Use proper indexes and slow-query analysis for MariaDB/PostgreSQL
• Limit logging verbosity for high-volume tracking
• Schedule cron jobs so that heavy work is staggered instead of stacked

If you want deeper guidance on matching vCPU and RAM to workloads, our article on how many vCPUs and how much RAM you really need offers a framework that also translates nicely to Mautic and Listmonk.

Larger Deployments (200k+ contacts, multi-brand)

Beyond roughly 200k contacts, you should strongly consider separating roles:

• 4–8 vCPU, 8–16 GB RAM app VPS
• 4–8 vCPU, 16–32 GB RAM database VPS (especially for Mautic with heavy reporting)
• 2–4 vCPU SMTP VPS with multiple IPv4 addresses (and IPv6 if you plan to send over dual-stack)

At this point, scaling decisions depend more on business constraints (campaign windows, acceptable send duration) than pure technical limits. If you need to deliver a million emails in a 1–2 hour window, SMTP throughput and IP reputation become the primary design drivers.

Deliverability-First SMTP and DNS Design

Even a perfect VPS build will not help if ISPs do not trust your email. Mautic and Listmonk simply talk SMTP; the rest is on your DNS records, IP choices, and rate limits.

Separate Sending Domains and Subdomains

We strongly recommend sending bulk marketing traffic from a dedicated subdomain or domain, for example:

• news.example.com or mail.example.com for marketing campaigns
• example.com for your main website and critical transactional mail

This gives you freedom to tune DMARC and reputation without risking login/reset emails. For a deeper strategy, see our article on using separate sending domains for transactional vs marketing email.

SPF, DKIM, DMARC and PTR (rDNS)

There is no serious self-hosted email marketing without correct email authentication:

• SPF: Authorizes your SMTP VPS IPs and/or hostnames to send on behalf of the domain
• DKIM: Cryptographically signs messages, with DNS TXT records publishing your public keys
• DMARC: Defines what receivers should do when SPF/DKIM fail (monitor, quarantine, reject)
• PTR (reverse DNS): Maps IP address back to a hostname that aligns with your HELO/EHLO and SPF

If you are new to these, start with our step-by-step guide on SPF, DKIM and DMARC explained for cPanel and VPS email and our overview of what a PTR (reverse DNS) record is and how it affects email delivery.

Dedicated IPs and Warmup Strategy

While small volumes can start on shared IPs, serious self-hosted marketing stacks benefit from dedicated IPs:

• You control all sending from that IP, so your reputation is not affected by others
• You can map different brands or regions to different IPs and adjust send patterns
• You get clearer signals in blocklists and postmaster tools

The catch: new IPs must be warmed up. That means gradually increasing daily volume so major inbox providers can build trust. We describe concrete schedules and patterns in our article on dedicated IP warmup and email reputation management.

Rate Limiting, Queue Design and SMTP Server Settings

Listmonk can open many concurrent connections to your SMTP server, and Mautic can fire bursts of emails during campaign sends. Without careful rate limiting, that is the fastest route to throttling or blocks.

Designing Safe Send Rates

Two numbers matter most:

• Per-minute or per-hour send rate per IP (for example 1,000–2,000 emails/hour for a new IP, increasing over time)
• Per-domain limits (for example no more than 300–500 emails/hour to a single large provider during warmup)

Implement these limits in two places:

• Inside Mautic/Listmonk (batch size, concurrency, send windows)
• On your SMTP VPS (Postfix queue concurrency and destination limits)

Our guide on outbound email security and SMTP rate limit management on shared hosting and VPS includes practical Postfix parameters you can adapt directly to your Mautic/Listmonk mail relays.

SMTP Security and Abuse Controls

A self-hosted marketing SMTP server must be locked down as carefully as a payment system:

• Require strong authentication for app-to-SMTP connections (or strictly IP-based ACLs on a private network)
• Disable open relay completely and test it
• Set sensible limits on message size, recipients per message, and connection rate
• Use TLS and modern ciphers for outbound SMTP where possible

Combine this with OS-level protections (firewall rules, Fail2ban for repeated authentication failures, log-based alerting) to stop abuse before it affects your IP reputation.

Bounce Handling and Error Codes

Proper bounce handling is where many self-hosted stacks fail quietly. Mautic and Listmonk can both process bounce mailboxes, but your SMTP design must:

• Route bounces to a dedicated mailbox per sending domain or project
• Preserve original headers (Message-ID, List-ID) where possible
• Not silently discard 4xx/5xx SMTP errors in logs

Use SMTP logs and bounce parsing to distinguish between:

• Permanent errors (5xx) – invalid addresses, rejected by policy, blocklisted IPs
• Temporary errors (4xx) – greylisting, rate limits, transient DNS issues

If you want a quick refresher on what those codes actually mean, our article on understanding email bounce codes like 550, 554 and 421 is a handy companion when tuning your Listmonk or Mautic bounces.

Security, Backups and Monitoring for a Calm Operations Life

A reliable Mautic/Listmonk stack is not just about sending fast; it must also be secure, restorable, and observable.

VPS Security Hardening Basics

Every marketing VPS should implement a minimal baseline:

• Disable password-based SSH; use keys and, ideally, two-factor authentication
• Restrict SSH to specific IPs or VPN if possible
• Use a host-based firewall (ufw, firewalld, or nftables) to expose only HTTP/HTTPS and necessary SMTP ports
• Run services (Mautic, Listmonk, Postfix, database) under least-privilege system users
• Regularly apply security updates to the OS and runtime (PHP, Go, database)

Our detailed checklist in the VPS security hardening guide for sshd_config, Fail2ban and disabling root SSH is a good baseline to apply to any new marketing VPS at dchost.com.

Database and Configuration Backups

Your subscriber database and campaign history are business-critical assets. Protect them with:

• Regular logical backups (mysqldump/pg_dump) and/or hot snapshot tools
• Off-site copies, ideally to object storage or a separate data center
• Tested restore procedures for both Mautic and Listmonk

If you want a structured way to plan this, our article on the 3-2-1 backup strategy and automated backups on cPanel, Plesk and VPS shows how to design backup layers that survive ransomware, accidents and human error.

Monitoring Resource Usage and Send Health

For Mautic/Listmonk, monitoring should cover both server health and email deliverability:

• CPU, RAM, disk usage and I/O latency on each VPS
• Database connections, slow queries and table size growth
• SMTP queues length and delivery latency
• Key metrics from Mautic/Listmonk (opens, clicks, bounce and complaint rates)

Even simple tools (htop, iotop, logrotate plus a lightweight dashboard) can prevent many surprises. As you scale, you can adopt more advanced setups like Prometheus + Grafana, as outlined in our VPS monitoring and alerting playbook with Prometheus and Grafana.

When to Move Beyond a Single VPS

Self-hosted email marketing often starts on one VPS and gradually evolves. Here are practical triggers for upgrading your architecture:

• Frequent CPU saturation during sends: Move database or SMTP to a separate VPS
• Inconsistent UI performance during campaign windows: Add more vCPUs or split app and DB
• IP reputation issues tied to many brands on one IP: Introduce additional SMTP VPS nodes or IP pools
• 24/7 uptime requirements for tracking and webhooks: Consider two app VPS nodes behind a load balancer and database replication

At dchost.com, you can evolve from a single VPS up to larger VPS clusters, dedicated servers, or even colocation while keeping your domains and IP strategy under one roof. The key is to keep configuration reproducible: use Ansible or similar tools, store configs in Git, and document your rate limits and DNS records.

Bringing It All Together

Mautic and Listmonk are powerful tools, but they only shine when the infrastructure behind them is calm, predictable and deliverability-aware. A well-designed VPS architecture accounts for more than raw CPU and RAM: it treats SMTP as a first-class component, respects DNS and authentication best practices, and plans for backups and observability from day one. Start simple on a single VPS if you are experimenting, then gradually introduce an SMTP VPS and a dedicated database node as your lists grow and your campaigns become more time-sensitive.

At dchost.com we design our VPS, dedicated and colocation offerings with these email workloads in mind: stable IP allocations, reverse DNS control, modern Linux images, and the flexibility to scale out when you are ready. If you are planning to host Mautic, Listmonk, or both, and want a concrete architecture that balances cost, performance and inbox placement, our team can help you select the right VPS specs, sending domain strategy and SMTP layout. Build your self-hosted email marketing stack on solid ground now, and you will have the freedom to evolve quickly as your audience and campaigns grow.