Multi-server (cluster) mode, available since version 7.1, lets Mumara Campaigns run on several application servers behind a load balancer while keeping their configuration in sync automatically: a settings change saved on any one server reaches every server within a minute, with no manual step per machine. It is off by default and meant only for load-balanced deployments — on a single server leave it off.
Layout: every server ("node") runs its own copy of the application code, web server and cron, while the database, the storage/ directory (usually an NFS mount) and the .env file are shared. Keep one real .env on the shared storage and symlink each node's .env to it, otherwise settings that live in .env (queue driver, application URL and name, environment, debug mode) will not propagate. Each node's bootstrap/cache/ must stay local.
Enable it under Settings → App Settings → General → Multi-server (cluster) mode, or force it with CLUSTER_MODE=true in the shared .env. Every settings save bumps a shared counter; once a minute each node checks it and, if behind, rebuilds only its own configuration cache from the already-shared data — no per-request cost, no extra services.
Scheduled tasks are cluster-aware: once-per-cluster work (campaign preparation and sending, stuck-campaign recovery, suppression and segment processing, maintenance, statistics, update checks) runs on a single node per tick; node-local work (tracking spool files, exported-file cleanup, the sync itself) runs everywhere. For the once-per-cluster locks to work, set CACHE_STORE to redis or database — with the file driver and node-local cache directories every node runs those tasks, causing duplicate sends and notifications.
Symptoms: a setting that applies on one server only means cluster mode is off or cron is not running elsewhere; queue-driver or URL changes that do not propagate mean separate .env copies instead of symlinks; duplicate emails mean a node-local cache store.
