Why prerequisites matter for performance and security
Magento 2 is a complex application with strict runtime dependencies. Running on the wrong PHP version, an unsupported database, or without a search engine will either prevent installation or create silent performance problems that surface under load.
For UK-based stores, getting prerequisites right before going live — or before migrating from an older host — avoids downtime, failed upgrades, and security exposure. Each component below is a hard requirement, not an optional enhancement.
This checklist covers Magento Open Source and Adobe Commerce 2.4.6 and 2.4.7 (the actively supported lines as of 2026). If you are running 2.4.5 or earlier, these prerequisites also apply but you should plan your upgrade path now — older versions no longer receive security patches.
PHP version requirements
Adobe enforces strict PHP version compatibility. Running an unsupported PHP version is not just a best-practice concern — Magento will refuse to install or upgrade, and older PHP versions no longer receive security patches from the PHP project itself.
Magento 2.4.6
Requires PHP 8.1 or 8.2. PHP 8.0 and earlier are not supported.
Magento 2.4.7
Requires PHP 8.2 or 8.3. PHP 8.1 support was dropped.
Key PHP extensions required: bcmath, ctype, curl, dom, gd (or ImageMagick), intl, mbstring, openssl, pdo_mysql, simplexml, soap, sodium, xsl, zip. Missing any of these will cause Composer to reject the installation. OPcache should also be enabled and properly sized — without it, PHP recompiles every script on each request, which significantly increases response time.
On EveryHost managed hosting, all required PHP extensions are pre-installed and OPcache is tuned for Magento workloads.
Database: MySQL or MariaDB
Magento 2.4.6+ supports MySQL 8.0 and MariaDB 10.6. Earlier database versions (MySQL 5.7, MariaDB 10.4) are no longer supported and will fail during setup:upgrade.
ROW_FORMAT = DYNAMIC
Magento creates large composite indexes that exceed the 767-byte limit of the older COMPACT row format. Set innodb_default_row_format = dynamic globally before installation. Without this, you will see "Specified key was too long" errors during schema creation.
Triggers, views, and privileges
Your database user needs TRIGGER and CREATE VIEW privileges. Standard cPanel-style shared hosts often restrict these, which causes Magento's indexers and declarative schema system to fail silently. On dedicated servers, you have full control over database privileges.
InnoDB buffer pool sizing
The InnoDB buffer pool should typically be set to 50–70% of available RAM on a dedicated server. Under-sizing this is the single most common cause of slow catalogue and checkout queries on Magento stores, because the database is forced to read from disk instead of memory.
Search engine: OpenSearch (mandatory)
MySQL catalogue search was removed in 2.4
Magento 2.4 requires a dedicated search engine service. Without one, the storefront search, layered navigation, and catalogue browsing will not function at all. This is not optional.
OpenSearch 2.x is the recommended search engine for current Magento builds. Adobe originally supported Elasticsearch, but has shifted its recommendation to OpenSearch (which is API-compatible). Elasticsearch 7.x still works with 2.4.6, but OpenSearch is the forward-looking choice.
Heap sizing: allocate at least 512 MB of JVM heap to OpenSearch. For stores with large catalogues (10,000+ SKUs), 1–2 GB is more appropriate. Under-provisioned heap causes out-of-memory errors during full catalogue reindexing, which typically runs overnight or after product imports.
On EveryHost managed Magento hosting, OpenSearch is included, pre-configured, and monitored as part of the stack.
Redis: cache and session storage
Redis is the recommended backend for both Magento's cache storage and session management. While not strictly mandatory (file-based alternatives exist), using files for sessions on any production store will cause I/O bottlenecks and session locking under concurrent traffic — especially during checkout.
Session storage
Use persistent Redis connections for sessions. Disable background saves (save "") on the session instance to avoid unnecessary disk I/O. Each session typically uses 2–10 KB, so memory requirements scale linearly with concurrent users.
Cache backend
Set maxmemory-policy allkeys-lru on the cache instance so old entries are evicted automatically when memory fills. Use a separate Redis instance (or at minimum a separate database number) from sessions to prevent cache flushes from destroying active user sessions.
On EveryHost dedicated servers, Redis is pre-installed with separate instances for sessions and cache, correctly sized and monitored.
Varnish and Nginx stack readiness
Magento ships with a built-in Varnish VCL configuration generator. For production use, Varnish should sit in front of your web server and handle full-page caching. A properly configured Varnish layer can serve 90%+ of storefront requests from memory, dramatically reducing PHP and database load.
Nginx as the web server: Apache with mod_php is supported but not recommended for performance-sensitive stores. Nginx with PHP-FPM provides better concurrency handling and lower memory overhead per request.
Document root must be pub/: Your web server root must point to the pub/ directory, not the Magento project root. This is a critical security requirement — without it, files like app/etc/env.php (which contains database credentials and encryption keys) are potentially accessible via HTTP.
All EveryHost Magento hosting plans include Varnish and Nginx pre-configured with the correct document root and VCL.
Cron configuration and operational readiness
Magento relies heavily on cron for indexing, email queues, sitemap generation, currency updates, and dozens of other background tasks. Without a working cron, your store will appear to function but will gradually degrade — prices won't update, search results will become stale, and order processing may stall.
Recommended schedule: Run the Magento cron every minute (* * * * *). Magento's internal scheduler handles task frequency — the system cron just needs to trigger the runner frequently enough.
Stuck cron detection: Cron jobs can hang, especially during large reindex operations or if database locks occur. Your hosting environment should monitor for stuck processes and alert or terminate them before they cascade into site-wide issues. Our Sentinel Suite includes CronWatch, which monitors cron health and alerts on stuck or failed jobs automatically.
Filesystem permissions and open file limits
Ownership and permissions
Files should be owned by the Magento filesystem user (not root or www-data). Recommended permissions: files 644, directories 755. The var/, generated/, pub/static/, and pub/media/ directories need to be writable by the web server user. Over-permissive settings (e.g., 777) are a security risk and should never be used in production.
Open file limits
Magento and its stack (PHP-FPM, Redis, OpenSearch, MySQL) can open thousands of file descriptors simultaneously. The default Linux ulimit of 1024 is too low for production. Set nofile to at least 65536 for the web server and database users to prevent "too many open files" errors under load.
Composer 2.x
Magento 2.4 requires Composer 2. Composer 1 is no longer supported and will fail to resolve dependencies. Ensure your deployment process uses Composer 2 and that auth.json contains valid Adobe Commerce repository credentials if you're using the commercial edition.
Migration safety: why moving protects your store
If your current host doesn't meet these prerequisites, migrating isn't just about performance — it's about protection. Stores running on outdated PHP, unsupported database versions, or without a search engine are exposed to known vulnerabilities that Adobe has already patched in newer versions.
Stability gains: Moving to a properly configured environment eliminates an entire class of intermittent issues: session losses from file-based storage, search failures from missing OpenSearch, slow queries from untuned databases, and cron failures from restricted hosting environments.
Upgrade path: A host that meets current prerequisites today also gives you a clear path to future Magento versions. Adobe typically tightens requirements with each release — what's optional today often becomes mandatory in the next version.
Our managed Magento hosting and dedicated servers are built from the ground up to meet every prerequisite on this page, with monitoring and alerting via Sentinel Suite to keep your store safe after migration.
Sentinel Suite: protection after you're set up
Meeting prerequisites is the foundation. Sentinel Suite adds active monitoring and protection on top:
Monitors OpenSearch health and blocks bots that abuse catalogue search, protecting both performance and server resources.
Detects stuck or failed cron jobs before they cascade into indexing failures, stale prices, or queue backlogs.
Filters genuine threats from upgrade noise, so you're alerted to real security events without false positives.