Search intent: informational/decisional — developers and merchants provisioning or upgrading Magento infrastructure. We cover the required stack, PHP and database versions, supporting services, real-world sizing beyond the minimums, and how to verify compatibility. It pairs with our search engine, Redis and Varnish guides.

A production Magento 2.4 installation is a multi-service system. The table below sets out the Magento server requirements for a current 2.4.x deployment. Note that exact supported versions shift between patch releases — always confirm against Adobe’s system requirements page for your specific version before provisioning.

PHP is the component teams most often get wrong in Magento server requirements, in both directions. Running an unsupported older PHP means missing security fixes and real performance gains; running a newer PHP than your Magento version supports causes deprecation errors and third-party extension breakage. Magento is strict here — match the documented matrix for your exact version rather than assuming forward compatibility.

Beyond the version, PHP configuration matters. Magento needs a generous memory_limit — 2GB or more for Composer operations and setup:di:compile, even though runtime needs are lower — plus max_execution_time raised for CLI tasks, and PHP extensions including bcmath, ctype, curl, dom, gd (or imagick), intl, mbstring, openssl, pdo_mysql, soap, xsl, sockets and zip. OPcache should be enabled and sized generously in production; it is one of the cheapest performance wins in the entire Magento server requirements list.

On the database side, InnoDB configuration does most of the work. The innodb_buffer_pool_size should hold your working data set — on a dedicated database server, a large fraction of available RAM — because a buffer pool too small for the catalogue turns every query into disk I/O. As stores grow, moving MySQL to its own host is a standard step, so it stops competing with PHP-FPM for CPU and memory.

Adobe’s published minimums will install Magento; they will not run a busy shop. Practical Magento server requirements for a production store look rather different, and sizing depends on three things: catalogue size, concurrent traffic, and how much of that traffic is anonymous (and therefore cacheable by Varnish).

Rules of thumb we work to: give the application server enough RAM that PHP-FPM workers, OPcache and the OS never swap — swapping is catastrophic for Magento response times. Size PHP-FPM pm.max_children against available memory rather than optimistically, since over-provisioning workers causes memory exhaustion under load while under-provisioning queues requests. Give the search engine its own memory budget and, past modest traffic, its own host. Redis needs enough memory for the working set plus headroom so it is not constantly evicting. And Varnish wants enough memory to hold the hot page set — a Varnish cache too small to hold your popular category pages spends its time evicting and refetching.

The single most important sizing insight for Magento server requirements: separate services onto their own hosts in this order as you grow — database first, then search, then Redis. Co-locating everything on one box is fine for development and small stores, but under real traffic these services compete for exactly the same CPU and memory, and the resulting contention looks like an application problem when it is an infrastructure one. Our Magento team specs and provisions production infrastructure.

# PHP version + required extensions
php -v
php -m | grep -E "bcmath|ctype|curl|dom|gd|intl|mbstring|openssl|pdo_mysql|soap|xsl|sockets|zip"

# PHP limits that block Magento installs
php -i | grep -E "^memory_limit|^max_execution_time|opcache.enable"

# database, search, cache, queue reachable?
mysql --version
curl -s localhost:9200 | head -5        # OpenSearch / Elasticsearch
redis-cli ping                          # expect PONG
varnishd -V 2>&1 | head -1
composer --version