Operating Systems (64-bit)
H2Linux (Recommended): CentOS/AlmaLinux 8/9, Ubuntu 22.04, Debian 11+
Windows Server 2019+
macOS 12+ (for development/testing only)
Why Linux?
• Better package management and long-term LTS kernels
• Native support for common mail components (Postfix, Exim)
• Lower resource overhead compared to Windows/macOS
Apache 2.4+ or Nginx 1.18+ (with PHP-FPM)
Cron scheduler support (for automations, campaigns, and queue workers)
PHP 8.3 or later (8.3 recommended)
Mumara requires the following core extensions:
PDO, curl, gd2, json, xml, iconv,
mbstring, openssl, fileinfo, imap,
tokenizer, ctype, ssh2, dom, zip
memory_limit ≥ 1024M (Suggested: 4GB to start with)
Enabled functions
allow_url_fopen, url_include,
exec, shell_execTip: Disable any unused PHP functions (e.g. exec) if you’re not using shell-based imports, backup/restore, for extra security.
Engine: MySQL 8.0+ or MariaDB 10.2+
Configuration:
innodb_buffer_pool_size ≈ 25–50% of total RAM
Enable slow-query log for segment & trigger tuning
(Optional) Master–Replica setup to offload reads
Every use case is unique. The table below summarizes three tiers based on list size and daily send volume:
Tier | Contacts | Daily Sends | vCPUs | RAM | Storage |
Minimum | ≤ 20 K | ≤ 2 K | 2 cores | 4 GB | 20 GB SSD |
Production | ≤ 100 K | ≤ 10 K | 4 cores | 8 GB | 50 GB NVMe (IOPS ≥ 5 000) |
Enterprise | > 500 K | > 50 K | 8+ cores | 16–32 GB | 100 GB+ RAID 1 NVMe |
Minimum tier is best for trials or light use—expect slower segment builds once you exceed ~15 K contacts.
Production tier supports routine workloads with room for moderate growth.
Enterprise tier is aimed at high-throughput environments; consider dedicated queue workers and read replicas.
Note: Keep resizing as your grow, or calculate as per your own usability.
Disk Type: NVMe SSD recommended for transactional I/O (segment queries, campaign logs)
Provisioned IOPS: ≥ 5 000 for production; ≥ 20 000 for enterprise
Filesystem: XFS or EXT4 with barrier support
Backups: Regular snapshots or logical dumps; store off-site
Bandwidth: ≥ 100 Mbps dedicated for production; ≥ 1 Gbps for enterprise
Latency: < 50 ms to your SMTP relays
Firewall:
Open ports 80/443 (web) and 25/587/465 (SMTP)
Whitelist licensing/update IPs if behind strict ACLs
Update Server: 103.181.98.8
Licensing Server: 103.181.98.69
Caching & Queues: Redis or Memcached for job queues, session storage
SMTP Relay Management:
Integrated Postfix/Exim or external (PowerMTA, Mumara ONE, SendGrid, Amazon SES, Mailgun, etc)
Dedicated IP pools per campaign for reputation control
Worker Processes:
Supervisord
Regardless of the recommendations above, every environment behaves differently—so it’s essential that you continuously evaluate your own usage patterns and scale accordingly. Monitor metrics such as CPU utilization, memory usage, disk I/O, queue backlog, and query response times during peak campaigns. If you notice sustained resource saturation (e.g., CPU > 80 % during sends, memory swapping, or slow segment builds), increase your vCPU count, add more RAM, or introduce additional worker nodes. Conversely, if your current infrastructure consistently shows healthy headroom, you may opt for a slightly lower tier to optimize costs. Your real‐world performance data should always be the guiding factor in right‐sizing and scaling your Mumara Campaigns deployment.