{"id":4521,"date":"2026-02-05T16:53:58","date_gmt":"2026-02-05T13:53:58","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/vps-architecture-for-hosting-mautic-and-listmonk\/"},"modified":"2026-02-05T16:53:58","modified_gmt":"2026-02-05T13:53:58","slug":"vps-architecture-for-hosting-mautic-and-listmonk","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/vps-architecture-for-hosting-mautic-and-listmonk\/","title":{"rendered":"VPS Architecture for Hosting Mautic and Listmonk"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>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 <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> 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.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Mautic_vs_Listmonk_What_Their_Architectures_Expect_from_Your_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> Mautic vs Listmonk: What Their Architectures Expect from Your VPS<\/a><ul><li><a href=\"#Mautic_PHP_Database_Cron_and_Heavy_Web_Traffic\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Mautic: PHP, Database, Cron and Heavy Web Traffic<\/a><\/li><li><a href=\"#Listmonk_Go_Single_Binary_and_Send-Focused\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Listmonk: Go, Single Binary and Send-Focused<\/a><\/li><li><a href=\"#Running_Both_on_the_Same_VPS_vs_Separate_Servers\"><span class=\"toc_number toc_depth_2\">1.3<\/span> Running Both on the Same VPS vs Separate Servers<\/a><\/li><\/ul><\/li><li><a href=\"#Core_VPS_Architecture_Patterns_for_Self-Hosted_Email_Marketing\"><span class=\"toc_number toc_depth_1\">2<\/span> Core VPS Architecture Patterns for Self-Hosted Email Marketing<\/a><ul><li><a href=\"#Pattern_1_Single_VPS_for_App_DB_SMTP_Small_Lists\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Pattern 1: Single VPS for App + DB + SMTP (Small Lists)<\/a><\/li><li><a href=\"#Pattern_2_App_VPS_SMTP_VPS_Deliverability-First\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Pattern 2: App VPS + SMTP VPS (Deliverability-First)<\/a><\/li><li><a href=\"#Pattern_3_App_VPS_DB_VPS_SMTP_VPS_High_Growth\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Pattern 3: App VPS + DB VPS + SMTP VPS (High Growth)<\/a><\/li><\/ul><\/li><li><a href=\"#Sizing_Your_VPS_for_Mautic_and_Listmonk\"><span class=\"toc_number toc_depth_1\">3<\/span> Sizing Your VPS for Mautic and Listmonk<\/a><ul><li><a href=\"#Baseline_for_Evaluation_and_Small_Lists_up_to_20k_contacts\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Baseline for Evaluation and Small Lists (up to ~20k contacts)<\/a><\/li><li><a href=\"#Growing_Lists_50k200k_contacts\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Growing Lists (~50k\u2013200k contacts)<\/a><\/li><li><a href=\"#Larger_Deployments_200k_contacts_multi-brand\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Larger Deployments (200k+ contacts, multi-brand)<\/a><\/li><\/ul><\/li><li><a href=\"#Deliverability-First_SMTP_and_DNS_Design\"><span class=\"toc_number toc_depth_1\">4<\/span> Deliverability-First SMTP and DNS Design<\/a><ul><li><a href=\"#Separate_Sending_Domains_and_Subdomains\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Separate Sending Domains and Subdomains<\/a><\/li><li><a href=\"#SPF_DKIM_DMARC_and_PTR_rDNS\"><span class=\"toc_number toc_depth_2\">4.2<\/span> SPF, DKIM, DMARC and PTR (rDNS)<\/a><\/li><li><a href=\"#Dedicated_IPs_and_Warmup_Strategy\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Dedicated IPs and Warmup Strategy<\/a><\/li><\/ul><\/li><li><a href=\"#Rate_Limiting_Queue_Design_and_SMTP_Server_Settings\"><span class=\"toc_number toc_depth_1\">5<\/span> Rate Limiting, Queue Design and SMTP Server Settings<\/a><ul><li><a href=\"#Designing_Safe_Send_Rates\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Designing Safe Send Rates<\/a><\/li><li><a href=\"#SMTP_Security_and_Abuse_Controls\"><span class=\"toc_number toc_depth_2\">5.2<\/span> SMTP Security and Abuse Controls<\/a><\/li><li><a href=\"#Bounce_Handling_and_Error_Codes\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Bounce Handling and Error Codes<\/a><\/li><\/ul><\/li><li><a href=\"#Security_Backups_and_Monitoring_for_a_Calm_Operations_Life\"><span class=\"toc_number toc_depth_1\">6<\/span> Security, Backups and Monitoring for a Calm Operations Life<\/a><ul><li><a href=\"#VPS_Security_Hardening_Basics\"><span class=\"toc_number toc_depth_2\">6.1<\/span> VPS Security Hardening Basics<\/a><\/li><li><a href=\"#Database_and_Configuration_Backups\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Database and Configuration Backups<\/a><\/li><li><a href=\"#Monitoring_Resource_Usage_and_Send_Health\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Monitoring Resource Usage and Send Health<\/a><\/li><\/ul><\/li><li><a href=\"#When_to_Move_Beyond_a_Single_VPS\"><span class=\"toc_number toc_depth_1\">7<\/span> When to Move Beyond a Single VPS<\/a><\/li><li><a href=\"#Bringing_It_All_Together\"><span class=\"toc_number toc_depth_1\">8<\/span> Bringing It All Together<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Mautic_vs_Listmonk_What_Their_Architectures_Expect_from_Your_VPS\">Mautic vs Listmonk: What Their Architectures Expect from Your VPS<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Mautic_PHP_Database_Cron_and_Heavy_Web_Traffic\">Mautic: PHP, Database, Cron and Heavy Web Traffic<\/span><\/h3>\n<p>Mautic is a PHP-based application that typically runs behind a web server like Nginx or Apache with PHP-FPM. It relies on:<\/p>\n<ul>\n<li>A relational database (usually MySQL\/MariaDB) for contacts, segments, campaigns and logs<\/li>\n<li>Cron jobs or background workers for campaigns, segment rebuilding, and scheduled sends<\/li>\n<li>An SMTP relay or local MTA (Postfix, Exim etc.) to actually deliver outbound email<\/li>\n<\/ul>\n<p>In practice this means your VPS must handle:<\/p>\n<ul>\n<li>Many concurrent PHP requests (UI, API, tracking pixels, webhooks)<\/li>\n<li>Frequent read\/write queries to a growing database<\/li>\n<li>Regular CPU spikes during campaign processing cron runs<\/li>\n<\/ul>\n<p>As your list grows, PHP and database performance tend to be the first bottlenecks, not raw SMTP throughput.<\/p>\n<h3><span id=\"Listmonk_Go_Single_Binary_and_Send-Focused\">Listmonk: Go, Single Binary and Send-Focused<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>PostgreSQL as its primary database<\/li>\n<li>A built-in queue and worker system for email sends<\/li>\n<li>Direct SMTP connections to one or more outbound mail servers or providers<\/li>\n<\/ul>\n<p>The resource profile is slightly different from Mautic:<\/p>\n<ul>\n<li>Lower CPU overhead per web request compared to PHP<\/li>\n<li>Very efficient concurrent SMTP sending, which can saturate your IP reputation before CPU or RAM if not rate-limited correctly<\/li>\n<li>Database write load concentrated around imports and campaign sends<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Running_Both_on_the_Same_VPS_vs_Separate_Servers\">Running Both on the Same VPS vs Separate Servers<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>Separate VPS for marketing apps (Mautic\/Listmonk UI, APIs, tracking) and SMTP roles<\/li>\n<li>Optional separate VPS or managed database instance for MySQL\/PostgreSQL if your campaigns become analytics-heavy<\/li>\n<\/ul>\n<p>This keeps noisy SMTP workloads from impacting UI responsiveness or database performance and makes scaling each layer independently much easier.<\/p>\n<h2><span id=\"Core_VPS_Architecture_Patterns_for_Self-Hosted_Email_Marketing\">Core VPS Architecture Patterns for Self-Hosted Email Marketing<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Pattern_1_Single_VPS_for_App_DB_SMTP_Small_Lists\">Pattern 1: Single VPS for App + DB + SMTP (Small Lists)<\/span><\/h3>\n<p>This is the starting point for many teams evaluating self-hosted email marketing.<\/p>\n<ul>\n<li><strong>Components on the same VPS:<\/strong> Mautic or Listmonk, database (MariaDB\/PostgreSQL), local MTA (Postfix), Redis (optional), Nginx\/Apache<\/li>\n<li><strong>Suitable for:<\/strong> up to ~20k\u201350k subscribers and a few tens of thousands of emails per week, depending on how aggressively you tune things<\/li>\n<li><strong>Advantages:<\/strong> simple to manage, low cost, minimal network latency between app and database<\/li>\n<li><strong>Risks:<\/strong> if SMTP gets blocked or overloaded, it affects the whole VPS; scaling up means vertical scaling (more CPU\/RAM) rather than adding nodes<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/'>VPS security hardening checklist for sshd_config, Fail2ban and no-root SSH access<\/a>.<\/p>\n<h3><span id=\"Pattern_2_App_VPS_SMTP_VPS_Deliverability-First\">Pattern 2: App VPS + SMTP VPS (Deliverability-First)<\/span><\/h3>\n<p>As soon as volume and reputation matter, it is smart to separate the web app from the outbound SMTP role:<\/p>\n<ul>\n<li><strong>App VPS:<\/strong> runs Mautic\/Listmonk, Nginx\/Apache, PHP-FPM (for Mautic), and the database<\/li>\n<li><strong>SMTP VPS:<\/strong> runs Postfix\/Exim as an outbound relay, with its own dedicated IPs and rate limits<\/li>\n<\/ul>\n<p>Benefits of this split:<\/p>\n<ul>\n<li>Compromised mail IP or abuse issue does not directly affect your app&apos;s IP<\/li>\n<li>You can attach multiple IPs to the SMTP VPS for warmup and pool management<\/li>\n<li>You can scale app performance (CPU\/RAM) independently from SMTP throughput<\/li>\n<li>You can later migrate SMTP to a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> without touching the app layer<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/e-posta-icin-ayri-gonderim-alan-adi-kullanmak-transactional-ve-pazarlama-e-postalari-icin-dogru-domain-ve-dns-stratejisi\/'>using separate sending domains for transactional and marketing email<\/a>.<\/p>\n<h3><span id=\"Pattern_3_App_VPS_DB_VPS_SMTP_VPS_High_Growth\">Pattern 3: App VPS + DB VPS + SMTP VPS (High Growth)<\/span><\/h3>\n<p>Beyond a certain point, database writes and reads become the main bottleneck, especially for Mautic:<\/p>\n<ul>\n<li>Large segment rebuilds<\/li>\n<li>Frequent opens\/clicks tracking<\/li>\n<li>Many campaigns running concurrently<\/li>\n<\/ul>\n<p>In that scenario, you can add a dedicated database VPS:<\/p>\n<ul>\n<li><strong>App VPS:<\/strong> Mautic\/Listmonk, web server, PHP-FPM\/Go binary<\/li>\n<li><strong>DB VPS:<\/strong> MariaDB\/MySQL (for Mautic) or PostgreSQL (for Listmonk)<\/li>\n<li><strong>SMTP VPS:<\/strong> dedicated outbound mail server(s)<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/veritabani-sunucusunu-uygulama-sunucusundan-ayirmak-ne-zaman-mantikli\/'>when to separate database and application servers for MySQL and PostgreSQL<\/a>.<\/p>\n<h2><span id=\"Sizing_Your_VPS_for_Mautic_and_Listmonk\">Sizing Your VPS for Mautic and Listmonk<\/span><\/h2>\n<p>Capacity planning for an email marketing stack has three main axes:<\/p>\n<ul>\n<li>Contact\/list size<\/li>\n<li>Peak send rate (emails per hour)<\/li>\n<li>Data retention and reporting depth<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Baseline_for_Evaluation_and_Small_Lists_up_to_20k_contacts\">Baseline for Evaluation and Small Lists (up to ~20k contacts)<\/span><\/h3>\n<ul>\n<li><strong>vCPU:<\/strong> 2 vCPU<\/li>\n<li><strong>RAM:<\/strong> 4 GB<\/li>\n<li><strong>Disk:<\/strong> 60\u201380 GB SSD\/NVMe<\/li>\n<li><strong>Traffic:<\/strong> 1\u20132 TB\/month is often plenty at this size<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Growing_Lists_50k200k_contacts\">Growing Lists (~50k\u2013200k contacts)<\/span><\/h3>\n<ul>\n<li><strong>vCPU:<\/strong> 4 vCPU (app), 2\u20134 vCPU (SMTP VPS if separated)<\/li>\n<li><strong>RAM:<\/strong> 8 GB on the app node<\/li>\n<li><strong>Disk:<\/strong> 120\u2013200 GB, preferably on NVMe for better IOPS<\/li>\n<\/ul>\n<p>At this stage, tuning matters more than raw specs:<\/p>\n<ul>\n<li>Enable PHP OPcache and tune PHP-FPM pools for Mautic<\/li>\n<li>Use proper indexes and slow-query analysis for MariaDB\/PostgreSQL<\/li>\n<li>Limit logging verbosity for high-volume tracking<\/li>\n<li>Schedule cron jobs so that heavy work is staggered instead of stacked<\/li>\n<\/ul>\n<p>If you want deeper guidance on matching vCPU and RAM to workloads, our article on <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-blog-woocommerce-ve-saas-icin-kac-cpu-ne-kadar-ram\/'>how many vCPUs and how much RAM you really need<\/a> offers a framework that also translates nicely to Mautic and Listmonk.<\/p>\n<h3><span id=\"Larger_Deployments_200k_contacts_multi-brand\">Larger Deployments (200k+ contacts, multi-brand)<\/span><\/h3>\n<p>Beyond roughly 200k contacts, you should strongly consider separating roles:<\/p>\n<ul>\n<li>4\u20138 vCPU, 8\u201316 GB RAM app VPS<\/li>\n<li>4\u20138 vCPU, 16\u201332 GB RAM database VPS (especially for Mautic with heavy reporting)<\/li>\n<li>2\u20134 vCPU SMTP VPS with multiple IPv4 addresses (and IPv6 if you plan to send over dual-stack)<\/li>\n<\/ul>\n<p>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\u20132 hour window, SMTP throughput and IP reputation become the primary design drivers.<\/p>\n<h2><span id=\"Deliverability-First_SMTP_and_DNS_Design\">Deliverability-First SMTP and DNS Design<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Separate_Sending_Domains_and_Subdomains\">Separate Sending Domains and Subdomains<\/span><\/h3>\n<p>We strongly recommend sending bulk marketing traffic from a dedicated subdomain or domain, for example:<\/p>\n<ul>\n<li><code>news.example.com<\/code> or <code>mail.example.com<\/code> for marketing campaigns<\/li>\n<li><code>example.com<\/code> for your main website and critical transactional mail<\/li>\n<\/ul>\n<p>This gives you freedom to tune DMARC and reputation without risking login\/reset emails. For a deeper strategy, see our article on <a href='https:\/\/www.dchost.com\/blog\/en\/e-posta-icin-ayri-gonderim-alan-adi-kullanmak-transactional-ve-pazarlama-e-postalari-icin-dogru-domain-ve-dns-stratejisi\/'>using separate sending domains for transactional vs marketing email<\/a>.<\/p>\n<h3><span id=\"SPF_DKIM_DMARC_and_PTR_rDNS\">SPF, DKIM, DMARC and PTR (rDNS)<\/span><\/h3>\n<p>There is no serious self-hosted email marketing without correct email authentication:<\/p>\n<ul>\n<li><strong>SPF:<\/strong> Authorizes your SMTP VPS IPs and\/or hostnames to send on behalf of the domain<\/li>\n<li><strong>DKIM:<\/strong> Cryptographically signs messages, with DNS TXT records publishing your public keys<\/li>\n<li><strong>DMARC:<\/strong> Defines what receivers should do when SPF\/DKIM fail (monitor, quarantine, reject)<\/li>\n<li><strong>PTR (reverse DNS):<\/strong> Maps IP address back to a hostname that aligns with your HELO\/EHLO and SPF<\/li>\n<\/ul>\n<p>If you are new to these, start with our step-by-step guide on <a href='https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/'>SPF, DKIM and DMARC explained for cPanel and VPS email<\/a> and our overview of <a href='https:\/\/www.dchost.com\/blog\/en\/ptr-reverse-dns-kaydi-vps-ipniz-icin-dogru-ayar-ve-e-posta-teslimine-etkisi\/'>what a PTR (reverse DNS) record is and how it affects email delivery<\/a>.<\/p>\n<h3><span id=\"Dedicated_IPs_and_Warmup_Strategy\">Dedicated IPs and Warmup Strategy<\/span><\/h3>\n<p>While small volumes can start on shared IPs, serious self-hosted marketing stacks benefit from dedicated IPs:<\/p>\n<ul>\n<li>You control all sending from that IP, so your reputation is not affected by others<\/li>\n<li>You can map different brands or regions to different IPs and adjust send patterns<\/li>\n<li>You get clearer signals in blocklists and postmaster tools<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/dedicated-ip-isitma-ve-e-posta-itibari-yonetimi\/'>dedicated IP warmup and email reputation management<\/a>.<\/p>\n<h2><span id=\"Rate_Limiting_Queue_Design_and_SMTP_Server_Settings\">Rate Limiting, Queue Design and SMTP Server Settings<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Designing_Safe_Send_Rates\">Designing Safe Send Rates<\/span><\/h3>\n<p>Two numbers matter most:<\/p>\n<ul>\n<li><strong>Per-minute or per-hour send rate per IP<\/strong> (for example 1,000\u20132,000 emails\/hour for a new IP, increasing over time)<\/li>\n<li><strong>Per-domain limits<\/strong> (for example no more than 300\u2013500 emails\/hour to a single large provider during warmup)<\/li>\n<\/ul>\n<p>Implement these limits in two places:<\/p>\n<ul>\n<li>Inside Mautic\/Listmonk (batch size, concurrency, send windows)<\/li>\n<li>On your SMTP VPS (Postfix queue concurrency and destination limits)<\/li>\n<\/ul>\n<p>Our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/paylasimli-hosting-ve-vpste-outbound-e-posta-guvenligi-ve-smtp-rate-limit-yonetimi\/'>outbound email security and SMTP rate limit management on shared hosting and VPS<\/a> includes practical Postfix parameters you can adapt directly to your Mautic\/Listmonk mail relays.<\/p>\n<h3><span id=\"SMTP_Security_and_Abuse_Controls\">SMTP Security and Abuse Controls<\/span><\/h3>\n<p>A self-hosted marketing SMTP server must be locked down as carefully as a payment system:<\/p>\n<ul>\n<li>Require strong authentication for app-to-SMTP connections (or strictly IP-based ACLs on a private network)<\/li>\n<li>Disable open relay completely and test it<\/li>\n<li>Set sensible limits on message size, recipients per message, and connection rate<\/li>\n<li>Use TLS and modern ciphers for outbound SMTP where possible<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Bounce_Handling_and_Error_Codes\">Bounce Handling and Error Codes<\/span><\/h3>\n<p>Proper bounce handling is where many self-hosted stacks fail quietly. Mautic and Listmonk can both process bounce mailboxes, but your SMTP design must:<\/p>\n<ul>\n<li>Route bounces to a dedicated mailbox per sending domain or project<\/li>\n<li>Preserve original headers (Message-ID, List-ID) where possible<\/li>\n<li>Not silently discard 4xx\/5xx SMTP errors in logs<\/li>\n<\/ul>\n<p>Use SMTP logs and bounce parsing to distinguish between:<\/p>\n<ul>\n<li>Permanent errors (5xx) \u2013 invalid addresses, rejected by policy, blocklisted IPs<\/li>\n<li>Temporary errors (4xx) \u2013 greylisting, rate limits, transient DNS issues<\/li>\n<\/ul>\n<p>If you want a quick refresher on what those codes actually mean, our article on <a href='https:\/\/www.dchost.com\/blog\/en\/e-posta-hata-kodlarini-anlamak-550-554-421-ve-bounce-mesajlarini-cozmek\/'>understanding email bounce codes like 550, 554 and 421<\/a> is a handy companion when tuning your Listmonk or Mautic bounces.<\/p>\n<h2><span id=\"Security_Backups_and_Monitoring_for_a_Calm_Operations_Life\">Security, Backups and Monitoring for a Calm Operations Life<\/span><\/h2>\n<p>A reliable Mautic\/Listmonk stack is not just about sending fast; it must also be secure, restorable, and observable.<\/p>\n<h3><span id=\"VPS_Security_Hardening_Basics\">VPS Security Hardening Basics<\/span><\/h3>\n<p>Every marketing VPS should implement a minimal baseline:<\/p>\n<ul>\n<li>Disable password-based SSH; use keys and, ideally, two-factor authentication<\/li>\n<li>Restrict SSH to specific IPs or VPN if possible<\/li>\n<li>Use a host-based firewall (ufw, firewalld, or nftables) to expose only HTTP\/HTTPS and necessary SMTP ports<\/li>\n<li>Run services (Mautic, Listmonk, Postfix, database) under least-privilege system users<\/li>\n<li>Regularly apply security updates to the OS and runtime (PHP, Go, database)<\/li>\n<\/ul>\n<p>Our detailed checklist in the <a href='https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/'>VPS security hardening guide for sshd_config, Fail2ban and disabling root SSH<\/a> is a good baseline to apply to any new marketing VPS at dchost.com.<\/p>\n<h3><span id=\"Database_and_Configuration_Backups\">Database and Configuration Backups<\/span><\/h3>\n<p>Your subscriber database and campaign history are business-critical assets. Protect them with:<\/p>\n<ul>\n<li>Regular logical backups (mysqldump\/pg_dump) and\/or hot snapshot tools<\/li>\n<li>Off-site copies, ideally to object storage or a separate data center<\/li>\n<li>Tested restore procedures for both Mautic and Listmonk<\/li>\n<\/ul>\n<p>If you want a structured way to plan this, our article on the <a href='https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/'>3-2-1 backup strategy and automated backups on cPanel, Plesk and VPS<\/a> shows how to design backup layers that survive ransomware, accidents and human error.<\/p>\n<h3><span id=\"Monitoring_Resource_Usage_and_Send_Health\">Monitoring Resource Usage and Send Health<\/span><\/h3>\n<p>For Mautic\/Listmonk, monitoring should cover both server health and email deliverability:<\/p>\n<ul>\n<li>CPU, RAM, disk usage and I\/O latency on each VPS<\/li>\n<li>Database connections, slow queries and table size growth<\/li>\n<li>SMTP queues length and delivery latency<\/li>\n<li>Key metrics from Mautic\/Listmonk (opens, clicks, bounce and complaint rates)<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-uyari-nasil-kurulur-prometheus-grafana-ve-node-exporter-ile-sessiz-alarmlari-konusturmak\/'>VPS monitoring and alerting playbook with Prometheus and Grafana<\/a>.<\/p>\n<h2><span id=\"When_to_Move_Beyond_a_Single_VPS\">When to Move Beyond a Single VPS<\/span><\/h2>\n<p>Self-hosted email marketing often starts on one VPS and gradually evolves. Here are practical triggers for upgrading your architecture:<\/p>\n<ul>\n<li><strong>Frequent CPU saturation during sends:<\/strong> Move database or SMTP to a separate VPS<\/li>\n<li><strong>Inconsistent UI performance during campaign windows:<\/strong> Add more vCPUs or split app and DB<\/li>\n<li><strong>IP reputation issues tied to many brands on one IP:<\/strong> Introduce additional SMTP VPS nodes or IP pools<\/li>\n<li><strong>24\/7 uptime requirements for tracking and webhooks:<\/strong> Consider two app VPS nodes behind a load balancer and database replication<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Bringing_It_All_Together\">Bringing It All Together<\/span><\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4522,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4521"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4521\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4522"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}