LEMP stack configuration
MailWizz runs on standard LEMP: Linux (AlmaLinux 9 or
Ubuntu 24.04 LTS depending on customer preference),
nginx with PHP-FPM, MySQL 8.0 or MariaDB 10.11. Our
deployments use AlmaLinux 9 by default for the longer
stable lifecycle and selinux integration. PHP version
8.2 or 8.3 (MailWizz 2.7+ supports both); we deploy 8.2
for production stability and 8.3 only on request.
PHP-FPM tuning matters. Default Ubuntu installations
ship with conservative pool settings inappropriate for
MailWizz workloads. Our deployment configures
process-manager dynamic, pm.max_children sized to
available RAM, pm.start_servers and pm.min_spare_servers
tuned to handle concurrent operator load plus
background queue worker processes, opcache enabled with
MailWizz-specific memory_consumption (256 MB) and
interned_strings_buffer (32 MB). The opcache
configuration alone makes a measurable difference in
MailWizz dashboard responsiveness.
MySQL configuration tuned for MailWizz workload
characteristics: innodb_buffer_pool_size sized to ~70%
of available RAM (working set fits in RAM for most
operations), innodb_log_file_size 512MB or larger to
accommodate write-heavy campaign sending, query_cache
disabled (deprecated in MySQL 8.0; meaningless for
MailWizz workload anyway). We configure binary logging
for point-in-time recovery if backup is enabled.
Cron schedules and queue workers
MailWizz operations split between the user-facing PHP
requests (campaign editor, list management) and
background jobs (campaign sending, bounce processing,
FBL processing, list cleanup, statistics aggregation).
Background jobs run via cron and queue workers. The
standard cron schedule fires every minute for the
send-campaigns command, every 5 minutes for
process-bounces and process-feedback-loops, every hour
for hourly statistics, every day for daily statistics
and list hygiene tasks.
Queue workers handle the heavier campaign sending work.
Each worker process picks campaigns from the queue,
generates per-recipient personalised messages, submits
to the configured delivery server. The worker count is
tunable; default is 4 workers per VPS-2, 8 workers per
VPS-3, 16 workers per Iron-E5. Higher worker counts
parallelise sending across cores; the bottleneck shifts
from PHP processing to delivery server throughput at
some point, after which adding workers stops helping.
Database scaling considerations
MailWizz's database schema includes wide tables for
subscribers (custom fields per list mean schema-less
subscriber data lives in a JSON column for current
versions), tracking events (opens, clicks, bounces all
inserted as separate rows), and campaign metadata. At
subscriber counts above 1M, the tracking event tables
grow rapidly; pruning strategies become operationally
important.
Standard pruning configuration removes tracking events
older than 365 days, keeps aggregate campaign
statistics indefinitely. Aggressive operations prune
to 90 days for tracking events; reporting then loses
ability to drill into older campaigns but database
performance remains stable. We configure default
pruning at 365 days and document how to adjust during
handover. For very large operations (5M+ subscribers,
retention requirements above 365 days), partitioned
tables with monthly partition rotation become the
pattern; we deploy partitioned schemas on request.
Backup and disaster recovery
The standard plan does not include managed backups; if
you do not opt for the Managed addon, backup is your
responsibility. The Managed addon configures daily
encrypted database dumps to second-jurisdiction storage
(Bulgaria primary, Romania backup; or EU primary,
Singapore backup for non-EU operations) with 30-day
retention. Database dumps are mysqldump-format
compressed and encrypted with customer-controlled keys
(we generate the key at setup and provide it to you;
we cannot decrypt backups without it).
Application-level backup (the MailWizz files themselves,
email templates, customer-uploaded images) ships as
weekly full archives separate from database dumps.
Recovery testing on request: we can spin up a parallel
MailWizz instance from a recent backup to verify
restorability without disturbing production.
Update and version management
MailWizz issues version updates regularly (typically
monthly minor patches, quarterly feature releases).
Updates require database schema migrations on most
releases; the official update process includes the
migration. Without the Managed addon, you handle
updates on your schedule; with the Managed addon, we
apply updates within 7 days of upstream release after
internal testing.
The license you receive entitles you to upstream
updates within the major version. Upstream MailWizz
development has been stable: we have customers running
MailWizz versions from the 1.x line still receiving
patches in the 2.x line because the developer maintains
long support windows. Major version upgrades (1.x to
2.x) require explicit license renewal upstream; we
handle that as part of the Managed addon if applicable.
