Best Magento Hosting in 2026: Your Host's Stack Is Probably Unsupported
Check your stack before you check your host. Here is what Adobe’s own system requirements table lists for current Commerce releases, read on 18 August 2026:
| Dependency | 2.4.9 | 2.4.8-p5 | 2.4.7-p10 |
|---|---|---|---|
| Search | OpenSearch 3 | OpenSearch 3 | OpenSearch 2, 3 |
| Database | MariaDB 12.3 (rec), 11.8 | MariaDB 11.4, 11.8 | MariaDB 10.11, 11.8 |
| Cache/session | Valkey 9 | Valkey 8.1 | Valkey 8.1 |
| Redis | (not listed) | (not listed) | “Not supported” |
| PHP | 8.5 | 8.4, 8.3 | 8.3, 8.2 |
| nginx | 1.30 | 1.30 | 1.30 |
| Composer | 2.10 | 2.10 | 2.10 |
| RabbitMQ | 4.3 | 4.3 | 4.3 |
Read the rows that aren’t there. Across all three current release lines there is no Elasticsearch row and no MySQL row — and on the latest 2.4.7 patch, Redis is listed explicitly as “Not supported”, where the previous patch listed Redis 7.2.
Three of the four major dependencies have been replaced: Elasticsearch by OpenSearch, MySQL by MariaDB, Redis by Valkey.
Why this matters more than any host comparison
Adobe states the consequence directly:
“Adobe supports only the system requirement combinations listed in the following tables. Adobe does not validate or support configurations that do not match a listed combination.”
So a “Magento-optimised” plan built on Elasticsearch, MySQL and Redis is a configuration Adobe does not validate or support. That’s not our characterisation — it’s the requirements page.
And these are formal end-of-support events with dates, both from the same page:
- MySQL 8.0 reached End of Support on 30 April 2026. Adobe “will not validate or provide support for newer MySQL major versions”, and on-premises customers on 2.4.7, 2.4.6, 2.4.5 and 2.4.4 are “strongly advised to migrate their database servers to a compatible MariaDB version.”
- Elasticsearch 7.17 reached End of Support on 15 January 2026. Customers on 2.4.6, 2.4.5 and 2.4.4 are “strongly advised to migrate their search infrastructure to a compatible OpenSearch version.”
If your store was provisioned more than a year ago, you are very likely running at least one unsupported dependency right now. That’s the actual finding of this article, and it applies whether you switch host or not.
What to ask a host before you buy
Because the compliance question is now specific, so are the questions. Ask for versions, not names:
- “Which OpenSearch version do you provision?” If the answer is Elasticsearch, it doesn’t match a supported combination.
- “MariaDB or MySQL, and which version?” MariaDB 11.8 covers all three current lines; 12.3 is recommended for 2.4.9.
- “Valkey or Redis?” If Redis, note it’s marked Not supported on 2.4.7-p10.
- “Which PHP version?” 2.4.9 needs PHP 8.5 — very new, and a genuine differentiator between hosts right now.
- “Do you provision RabbitMQ and Varnish, or is that on me?”
A host that answers all five with version numbers is running a real Magento platform. A host that answers with adjectives isn’t.
The other reason Magento is expensive to host
It is the heaviest mainstream PHP application there is, and the requirement list above is why: a compliant install is five or six services, not one. Search, database, cache, message queue, full-page cache and PHP — each with its own memory.
The deploy step is its own problem. setup:di:compile and setup:static-content:deploy are memory-hungry, and a build that works fine on a developer laptop can fail on a small VPS. Size for your deploy, not your steady state — this is the most common cause of “it worked locally”.
And full-page cache isn’t optional at scale. Varnish in front of Magento is the difference between a workable store and an unworkable one. We did not benchmark this — see below — but the architecture is not controversial.
The hosts
Nexcess — genuine Magento heritage, with the platform as a first-class product rather than a one-click installer bolted onto shared hosting. The first place we’d ask the five questions above, because it’s the most likely to answer them with version numbers.
Liquid Web — names Magento explicitly among its managed applications, alongside WordPress and WooCommerce, and publishes the clearest support-scope matrix of any host we’ve examined — stating exactly which tier stops troubleshooting your server. For a store carrying revenue, a documented boundary is worth more than a vague promise.
Cloudways — managed hosting on DigitalOcean or AWS with published SLA tiers. Read its exclusions before relying on it for a store: debugging custom code and application-level security issues are out of scope on every tier, and on a Magento install that covers your extensions and themes.
ScalaHosting — managed VPS with its own SPanel instead of cPanel, removing a licence cost. Viable if you’ll manage the Magento stack yourself and want the infrastructure handled.
Hosting.com (formerly A2 Hosting) — long-standing PHP hosting with Magento among its supported applications. Confirm the actual provisioned versions rather than the marketing list — we have not verified its current stack.
Hetzner — by far the most RAM and cores per euro, which matters when you’re running six services plus a memory-hungry deploy step. You build the entire stack yourself, which given the version churn above is arguably an advantage: you control which OpenSearch and Valkey versions you’re on. Note availability limits since June and that backups exclude attached Volumes — critical when your database is on one.
What we’d do
If you have a store on revenue: managed, from a host that answers the five questions with numbers. The cost difference is small against a day of downtime on a catalogue.
If you have the skills: a large Hetzner box you build yourself. The requirement churn — Elasticsearch out, MySQL out, Redis out, all within about eighteen months — is a strong argument for controlling your own versions rather than inheriting a host’s defaults.
Either way, audit what you’re running this week. Django and Laravel apps are tiny and forgiving; Magento is neither — and Moodle sits in the same category, where the next LTS raises the PHP and database floor before you’ve moved.
How we checked this
Every version, quote and date above is from Adobe’s official system requirements page on Experience League, read on 18 August 2026. The dependency table was parsed directly from that page’s markup for Commerce 2.4.9, 2.4.8-p5 and 2.4.7-p10. The “Not supported” value against Redis on 2.4.7-p10 is the literal cell content, with the adjacent 2.4.7-p9 column showing Redis 7.2 — we checked that specifically because it’s a strong claim.
“Not listed” means exactly that. For 2.4.9 and 2.4.8-p5 we found no Redis row, no MySQL row and no Elasticsearch row in the requirements tables. We are not claiming Adobe has announced their removal in those words — we’re reporting what the supported-combinations table contains, alongside Adobe’s own statement that it does not validate configurations outside those combinations. If you depend on this, read the page yourself before acting; it’s the authoritative source and it changes.
The end-of-support dates and migration advice — MySQL 8.0 on 30 April 2026, Elasticsearch 7.17 on 15 January 2026, and the “strongly advised to migrate” wording for affected on-premises versions — are quoted from that same page.
The big gap: there is no per-host compliance grid here, and the brief asked for one. Auditing each of six hosts against Adobe’s list would require knowing the exact OpenSearch, MariaDB, Valkey and PHP versions each provisions today. We could not verify those for any of the six, and a compliance grid with guessed cells would be actively harmful — it would tell you a host is compliant when we hadn’t checked. So we’ve published Adobe’s requirements, which is the citable half, and turned the audit into five questions you can ask. That’s a weaker article than the brief wanted and an honest one.
We also did not benchmark anything. The brief asked for TTFB on a seeded catalogue store with and without full-page cache. We have no Magento installation, no seeded catalogue and no host accounts, so there are no performance figures in this article. The claim that Varnish matters at scale is architectural reasoning, not a measurement we took.
On the hosts: Liquid Web’s managed-application list and support-tier matrix, and Cloudways’ published SLA tiers and out-of-scope list, were verified earlier in this series. Nexcess’s and ScalaHosting’s positioning is from their published product categories, and we have not verified Hosting.com’s current Magento stack at all. None of the six has been tested by us running Magento.
What we did not do: install Magento or Adobe Commerce, hold an account with any host here, run a deploy, or measure memory, TTFB or cache behaviour.
The host links above are affiliate links. The article’s most useful advice — audit the versions you’re already running — costs nothing and may well tell you not to move at all.
FAQ
What are Adobe Commerce’s system requirements in 2026?
For 2.4.9: OpenSearch 3, MariaDB 12.3 (recommended) or 11.8, Valkey 9, PHP 8.5, nginx 1.30, Composer 2.10 and RabbitMQ 4.3. Earlier supported lines use older versions of the same components.
Does Magento still use Redis?
Adobe’s requirements list Valkey rather than Redis, and on 2.4.7-p10 Redis is marked “Not supported” where the previous patch listed Redis 7.2. Check the current requirements page before assuming your host’s Redis is fine.
Can I run Magento on MySQL?
Adobe’s current requirement tables list MariaDB, not MySQL, and MySQL 8.0 reached End of Support on 30 April 2026. On-premises customers are strongly advised to migrate to a compatible MariaDB version.
Is Elasticsearch still supported for Magento?
Elasticsearch 7.17 reached End of Support on 15 January 2026, and Adobe won’t validate versions after Elasticsearch 7. The supported search engine in current requirements is OpenSearch.
What should I ask a Magento host?
Five questions, all wanting version numbers: which OpenSearch, MariaDB or MySQL and which version, Valkey or Redis, which PHP, and whether they provision RabbitMQ and Varnish.
Why is Magento hosting so expensive?
A compliant install is five or six separate services, and the deploy step is memory-hungry enough to fail on small servers even when the running store would fit.
Do I need Varnish?
For any store with a real catalogue and real traffic, full-page caching is what makes it workable. We haven’t benchmarked it, but it isn’t an optional component at scale.
