Magento High Availability Setup for Enterprise Stores
[Updated: March 24, 2026]
A single server runs your Magento store until peak traffic takes it down. High availability eliminates that single point of failure.
This guide covers the complete Magento HA architecture with current 2.4.8 stack components, hardware sizing formulas from Adobe, and deployment strategies that keep your store online during updates.
Key Takeaways
- Build redundancy across all layers: web servers, databases, cache, search, and file storage
- Use Galera clustering with MariaDB 11.4 for multi-master database replication across 3 nodes
- Deploy across a minimum of 3 availability zones for geographic fault tolerance
- Size hardware with Adobe's formula: 1 CPU core serves about 2 Commerce requests
- Consider managed hosting or Adobe Commerce Cloud Pro to handle infrastructure complexity
What is a Magento High Availability Setup?
Magento high availability (HA) = An infrastructure architecture that eliminates single points of failure so your store stays online even when individual components break. You trade simplicity for resilience.
Perfect for: Enterprise stores with 99.9%+ uptime requirements, high-traffic catalogs, businesses where downtime means direct revenue loss
Not ideal for: Small stores under 1,000 daily visitors, development environments, stores with limited DevOps resources
A Magento high availability setup distributes every critical service across multiple servers and availability zones. When one component fails, another takes over without interrupting the shopping experience.
The core principle: no single server, database, or cache instance should be able to bring down your store. Every layer needs redundancy, automatic failover, and health monitoring.
Adobe Commerce 2.4.8 supports this architecture with updated components: PHP 8.3/8.4, MariaDB 11.4, OpenSearch 2.19, Redis 7.2 or Valkey 8, Varnish 7.6, and Nginx 1.26.
Infrastructure Layers of a Magento HA Setup
Load Balancing
The Application Load Balancer (ALB) sits at the front of your infrastructure. It distributes incoming requests across application servers based on server health, current load, and response times. No single web server gets overwhelmed.
Behind the ALB, Varnish 7.6 acts as an HTTP accelerator. It intercepts requests and serves cached pages without touching the application servers. For content that cannot be cached, Varnish forwards requests to the next healthy server in the pool.
A Content Delivery Network (CDN) like AWS CloudFront handles static assets at edge locations worldwide. This reduces latency for international visitors and offloads bandwidth from your origin servers.
Application Layer
Multiple Nginx 1.26 instances run PHP-FPM 8.4 workers across separate availability zones. Each instance operates independent of the others. If one zone goes down, the remaining zones absorb the traffic.
Auto-scaling groups monitor CPU, memory, and request queues in real time. When traffic spikes, new instances launch within minutes. When traffic drops, excess instances terminate to reduce cost.
Session management runs through Redis 7.2 or Valkey 8 clusters. These maintain user sessions across all application servers. A customer browsing on Server A can continue their checkout on Server B without losing their cart.
Database Layer
The Galera cluster forms the backbone of database redundancy. It runs MariaDB 11.4 in a multi-master configuration where every node accepts both reads and writes. Each node holds a complete copy of the database.
Replication is synchronous. When a transaction commits on one node, it replicates to all other nodes before confirming success. This guarantees data consistency across the cluster.
Auto-increment offsets prevent ID conflicts. Node 1 generates IDs 1, 4, 7. Node 2 generates 2, 5, 8. Node 3 generates 3, 6, 9. No two nodes create the same record ID.
For read-heavy workloads, Magento 2 supports master-replica configurations. The master handles all writes. Replicas handle read queries like catalog browsing, reducing load on the master node.
Caching and Search
Redis 7.2 handles object caching, full-page cache backend, and session storage. In an HA setup, Redis runs as a cluster with one active instance per application node and two replicas for failover.
Valkey 8 (the Redis fork maintained by the Linux Foundation) is now an official alternative in Adobe Commerce 2.4.8. It offers the same functionality with a different governance model.
OpenSearch 2.19 powers catalog search and layered navigation. Deploy it as a 3-node cluster for HA: one manager node and two data nodes at minimum. Adobe Commerce 2.4.8 has deprecated Elasticsearch in favor of OpenSearch for all new installations.
Storage Layer
GlusterFS creates a distributed file system across all application nodes. It presents a single mount point so every server accesses the same files. Four directories need dedicated mounts:
| Directory | Purpose | I/O Pattern |
|---|---|---|
pub/media |
Product images, uploaded content | High read, moderate write |
pub/static |
CSS, JavaScript, compiled assets | High read, low write |
var |
Cache files, logs, temporary data | High read/write |
generated |
Compiled code, dependency injection | Read after deploy |
Amazon S3 integration provides unlimited capacity for growing media libraries. It adds geographic redundancy and automatic versioning for disaster recovery.
Security Layer
Security groups function as virtual firewalls that control traffic flow between components. Database nodes accept connections from application servers and nothing else.
SSL/TLS encryption protects all data in transit between users, application servers, and backend services. Proper certificate management is non-negotiable for PCI compliance and customer trust.
AWS WAF or comparable web application firewalls block malicious requests before they reach your infrastructure. Rate limiting prevents brute force attempts and resource exhaustion attacks. DDoS protection filters volumetric attacks at the network edge.
Hardware Sizing for Magento HA
Adobe publishes official sizing guidance. Use these formulas as a starting point.
CPU: 1 core serves about 2 Commerce requests. Calculate needed cores with:
Cores = (Expected Requests / 2) + Cron Processes
Add capacity for peak periods. Auto-scaling handles spikes, but your baseline cluster needs enough headroom for normal operations.
Memory:
| Component | Recommendation |
|---|---|
| PHP per web node | 2 GB minimum for production |
| MySQL/MariaDB | Half the database size for effective indexing |
| Redis cache | Enough to hold all active caches (grows with SKU count x store views) |
| Varnish | Enough memory for your most visited pages |
| OpenSearch | 50% of index size per data node |
Network: Sufficient bandwidth between web nodes, database cluster, and cache servers is critical. Internal network latency above 1ms between components degrades performance.
Minimum HA cluster:
| Component | Nodes | Specification (typical) |
|---|---|---|
| Web/App servers | 3 | 4-8 cores, 16-32 GB RAM each |
| MariaDB Galera | 3 | 8-16 cores, 64-128 GB RAM each |
| Redis/Valkey | 3 | 2-4 cores, 16-32 GB RAM each |
| OpenSearch | 3 | 4-8 cores, 32-64 GB RAM each |
| Load balancer | 2 | Managed service or HAProxy pair |
These specs cover stores with up to 100,000 SKUs and moderate traffic. Scale up for larger catalogs or higher transaction volumes.
Zero-Downtime Deployment
High availability means nothing if deployments take your store offline. Two strategies prevent that.
Blue-green deployment: Maintain two identical environments (blue and green). Deploy new code to the inactive environment, run smoke tests, then switch the load balancer to the new environment. Rollback means switching back. Our zero-downtime deployment guide covers the full process.
Rolling updates: Update one server at a time while the remaining servers handle traffic. The load balancer removes the server being updated from the pool, deploys new code, verifies health, then adds it back. Slower than blue-green but requires less infrastructure.
Both strategies need database migrations that are backward compatible. Schema changes must work with both the old and new code versions during the transition window.
Monitoring and Failover
| Strategy | What It Does |
|---|---|
| Server health checks | Track CPU, memory, disk usage across all nodes |
| Application Performance Monitoring | New Relic or Datadog traces request latency and error rates |
| Database replication monitoring | Verify Galera cluster sync state and replication lag |
| Load balancer health probes | Remove unhealthy nodes from the pool within seconds |
| Auto-scaling triggers | Launch new instances when CPU exceeds 70% for 5 minutes |
| DNS failover | Route traffic to a secondary region during full zone outages |
| Backup verification | Test restore procedures on a schedule, not just backup creation |
| Log aggregation | Centralize logs from all nodes for correlation during incidents |
Set alerts for anomalies: response time above 3 seconds, error rate above 1%, database replication lag above 100ms. Catch problems before customers notice them.
Adobe Commerce Cloud Pro: Built-in HA
Adobe Commerce Cloud Pro offers a managed HA architecture out of the box. The production environment runs 3 virtual machines behind an Elastic Load Balancer with HAProxy on every VM.
Each VM includes:
- Nginx + PHP-FPM with multiple workers
- MariaDB in a Galera cluster (auto-increment offset of 3)
- Redis (1 active per VM, 2 replicas)
- OpenSearch for catalog search
- GlusterFS for shared file storage
- Fastly CDN for HTTP caching
The architecture spans 3 AWS or Azure availability zones with zero-downtime scaling. All three instances accept reads and writes.
For stores that want HA without managing the infrastructure, Adobe Commerce as a Cloud Service (ACaaS) launched in June 2025 as a managed SaaS option. It supports up to 250 million SKUs per instance and removes the need for server management.
Managed Magento hosting provides a similar level of infrastructure management for Magento Open Source stores that need HA without the Adobe Commerce license cost.
Pros and Cons of Self-Managed Magento HA
FAQ
What is the minimum number of servers for Magento high availability?
A minimum HA setup requires 3 application servers, 3 database nodes (Galera cluster), 3 cache nodes (Redis or Valkey), 3 search nodes (OpenSearch), and 2 load balancers. This totals 14 servers for a basic production HA cluster.
How much does a Magento high availability setup cost?
Self-managed HA on AWS or similar cloud providers runs a typical $3,000 to $8,000 per month for a mid-size store, depending on instance types, traffic volume, and whether you use reserved instances. Managed hosting providers bundle the infrastructure management for a predictable monthly fee.
Can Magento Open Source run in a high availability setup?
Yes. Magento Open Source supports all HA components: Galera clustering, Redis replication, OpenSearch clusters, and load balancing. The HA architecture is identical to Adobe Commerce for the infrastructure layer.
What database works best for Magento HA in 2026?
MariaDB 11.4 LTS with Galera cluster is the recommended choice for Adobe Commerce 2.4.8. It provides synchronous multi-master replication with automatic failover. MySQL 8.4 is also supported but lacks native multi-master capabilities without additional tools.
How does auto-scaling work in a Magento HA setup?
Auto-scaling monitors server metrics (CPU, memory, request queue depth) and launches new application instances when thresholds are exceeded. New instances register with the load balancer and start serving traffic within minutes. When traffic decreases, excess instances terminate.
What replaced Elasticsearch in Magento 2.4.8?
OpenSearch 2.19 is the recommended search engine for Adobe Commerce 2.4.8. Elasticsearch 7 and 8 are deprecated and labeled as such in the admin panel. Existing stores can still use Elasticsearch 8.17 but should plan migration to OpenSearch.
What is the difference between HA and disaster recovery?
High availability prevents downtime by running redundant components that fail over within seconds. Disaster recovery restores operations after a complete failure (data center outage, data corruption) and involves backup restoration, which can take minutes to hours.
Should I use Redis or Valkey for Magento caching?
Both work. Redis 7.2 is the established choice with broad ecosystem support. Valkey 8 (the Linux Foundation fork) now has official support in Adobe Commerce 2.4.8 and offers the same functionality under a different license. Choose based on your organization's preference for governance model and long-term support.
How do I test my Magento HA setup?
Run three types of tests. Load tests with Apache JMeter simulate peak traffic to find bottlenecks. Failover tests shut down individual nodes to verify automatic recovery. Monitoring validation confirms that alerts fire within acceptable time windows when components fail.
When does a Magento store need high availability?
Consider HA when your store generates over $1 million in annual revenue, serves international traffic across time zones, or runs flash sales that spike traffic 5x or more above baseline. The cost of downtime must exceed the cost of redundant infrastructure.
Summary
A Magento high availability setup distributes every critical service across multiple nodes and availability zones. The 2.4.8 stack runs on PHP 8.4, MariaDB 11.4, OpenSearch 2.19, Redis 7.2 or Valkey 8, and Varnish 7.6.
Build redundancy in every layer: load balancers distribute traffic, Galera clusters replicate data, Redis clusters cache sessions, and GlusterFS shares files. Add auto-scaling for traffic spikes and zero-downtime deployment for safe releases.
For stores that need HA without the infrastructure overhead, managed Magento hosting handles the full architecture so you can focus on selling.
