Choosing hosting for Magento 2

Magento hosting is sold as plans and specs, but the decision underneath is about responsibility. Somebody has to patch the operating system, upgrade OpenSearch when Adobe’s requirements move, keep cron and the queue consumers running, and answer when the store is down. Every hosting tier is a different answer to who that somebody is.

This post lays out what Magento demands from infrastructure, gives a checklist for judging a host, and applies it to the three tiers: Adobe’s own cloud, the managed Magento specialists (including the Czech and Polish providers your region offers), and self-managed infrastructure on AWS or Hetzner. Every vendor fact was checked against the linked source on August 3, 2026; where something could not be verified, we say so.

What Magento demands from a server

Adobe publishes a tested-combinations table per release line and is explicit about its scope: “Adobe supports only the system requirement combinations listed in the following tables.” For Magento 2.4.9 (released May 12, 2026, per the released-versions page), the on-premises table lists OpenSearch 3, MariaDB 12.3, MySQL 8.4, PHP 8.5, RabbitMQ 4.3, Valkey 9, Varnish 8 and nginx 1.30. The table for 2.4.8-p5 stays one step behind: PHP 8.4 and 8.3, with Elasticsearch 8 still listed beside OpenSearch 3, and Valkey 8.1. Three shifts in those tables decide whether a host is current:

• OpenSearch is required; Elasticsearch is being removed from the tested table. “As of Adobe Commerce 2.4, all installations must be configured to use Elasticsearch or OpenSearch as the catalog search solution” (search engine prerequisites), and the 2.4.9 table lists only OpenSearch 3, with no Elasticsearch row at all. Elasticsearch 7.17 reached end of support on January 15, 2026, per Adobe’s system-requirements page.
• Valkey replaced Redis. The 2.4.9 and 2.4.8-p5 tables carry no Redis row at all, the latest patches of the 2.4.5 through 2.4.7 lines mark Redis “Not supported” with Valkey listed instead, and Adobe’s cache documentation states: “Starting with Adobe Commerce 2.4.9, Valkey officially replaced Redis in CLI tooling” (Redis page cache doc).
• MySQL 8.0 reached end of support on April 30, 2026, and Adobe’s system-requirements page advises the affected release lines to move to MariaDB.

Beyond the table, two operational requirements rule out generic shared hosting. Cron is mandatory: “Commerce depends on proper cron job configuration for many important system functions, including indexing. Failure to set it up properly means that Commerce will not function as expected,” and the list of cron-dependent functions includes all transactional email. Queue consumers are worker processes that cron restarts in batches by default; keeping them healthy is the host’s or the team’s job. RabbitMQ is optional in general and the default for the Bulk API. A host that offers PHP and MySQL but cannot run OpenSearch, a Valkey-backed cache, Varnish and several worker processes cannot run Magento the way Adobe tests it, whatever the plan page says. Mage-OS publishes its own requirements with looser minimums (PHP 8.3 and up, OpenSearch 2 and up, with Elasticsearch and Redis still listed), but the shape of the stack is the same: a search engine, cron and worker processes stay mandatory whichever distribution you run.

The checklist: who runs what, and what is in writing

Who runs which layer. The three tiers split the work differently. On Adobe’s PaaS, Adobe runs the infrastructure and the merchant still “manages application code, upgrades, patching, infrastructure configuration within Adobe’s hosted environment” (Adobe’s migration guide). On a managed specialist, the host runs the stack and the merchant’s team or agency runs Magento itself. On self-managed infrastructure, AWS’s shared responsibility model is explicit: customers deploying EC2 “are responsible for management of the guest operating system (including updates and security patches)”, and everything above it. Application-level work, Magento upgrades, extensions, custom code, never transfers to any host on any tier. The question is only where the line below it sits.

Whether the host keeps up with the platform. The requirements above move with every release cycle, and hosts lag them by documented, checkable amounts. Compare the host’s published component versions (PHP, OpenSearch, Valkey) against Adobe’s current table; the profiles below record what each vendor states, and an absent version statement is a reason to ask before signing. The lag matters most when you are building new or upgrading to the newest line; a host matching the tested combinations of the release line you are on remains supported until that line’s end of support.

What the SLA document itself says. Several vendors advertise uptime figures their own legal pages do not contain; the mismatches we found are noted in the profiles. Read what the credit scheme is, who verifies an outage, and on what deadline a claim must be filed. The structural limit everywhere: the provider itself reports the outage, announces its own maintenance, and its own logs decide the claim. Credits are capped, at a month’s fees or less in the terms we read; each cap we found is noted below. A public status page with visible incident history is still worth reading, and each one we found is linked.

The operations behind the plan page. Four questions separate a Magento specialist from a generic managed host, and no vendor profiled below publishes full answers to them. How does the plan handle a sales peak: resize lead time, autoscaling, and what peak-season capacity planning is included. How long does a restore take on a production-sized dataset, and is database recovery point-in-time or snapshot-only; the backup schedule is the easy half. What does a deploy do to the live store: maintenance window or atomic switch, and does staging match production. And on multi-server plans, which node owns cron and the queue consumers, and how are they kept away from web traffic. Ask all four; the answers are rarely public.

Data location and the legal basis for US providers. EU-to-US transfers currently rest on the EU-US Data Privacy Framework, adopted July 10, 2023; the EU General Court upheld it against the Latombe challenge on September 3, 2025 (IAPP report), and Latombe’s further appeal to the Court of Justice (Case C-703/25 P, filed October 31, 2025) was still pending when we checked in August 2026. A US-owned host’s participation can be verified on the official DPF list. The practical check is simpler: does the vendor document, in writing, which data center your store runs in? The profiles record who does.

The PCI split. A hosting provider is a third-party service provider under PCI DSS, and the Council’s 2016 third-party assurance supplement is blunt: “The use of a TPSP, however, does not relieve the entity of ultimate responsibility for its own PCI DSS compliance …” (PCI SSC supplement). Ask the host for its service-provider Attestation of Compliance and keep the matrix of which requirements it covers; the merchant side of that split stays with you.

How each tier prices. Managed specialists sell fixed plans, usage-billed configurations (JetRails), or, at MGT-Commerce, a management fee plus your own cloud bill; self-managed infrastructure is metered; Adobe is sales-only. All figures below are net of VAT, which EU businesses reverse-charge either way; the USD-billed vendors add exchange costs and currency exposure that the EUR-billed ones do not. The profiles quote published figures verbatim; where a vendor publishes none, that is stated, and we do not estimate totals for metered setups.

Adobe’s cloud: the first-party tier

Adobe Commerce on cloud infrastructure is the platform vendor’s PaaS, running on AWS or, for Pro, Azure, per its Pro architecture doc; its security guide documents the bundled Fastly CDN with DDoS protection and WAF, hourly production backups, and that production instances can run in most AWS regions, with the customer specifying where production resides. Adobe’s unified SLA addendum (effective October 12, 2025) defines the commitment as “99.99% for the Adobe-hosted infrastructure of the Production Environment”. Two constraints bound the tier. Licensing: it is an Adobe Commerce product, and Adobe’s product-solutions page classes open-source deployments as customer-managed and self-hosted; Mage-OS, which Adobe’s documentation does not mention, has no path onto it either. Pricing: not public anywhere; figures circulating online are third-party estimates and we do not repeat them.

Adobe is also changing what this tier is. It introduced Adobe Commerce as a Cloud Service (SaaS) in 2025 and publishes a migration guide: the SaaS locks the core application code and moves customization to APIs and App Builder, and its promoted storefront runs on Edge Delivery Services, mandatory for Luma stores while existing PWA and headless storefronts can be kept. For a Luma store the move is a re-architecture rather than a straight migration. Adobe’s own blog states the PaaS has no end-of-support plans (the page would not load for us; the statement comes from its indexed text). The hard date sits elsewhere: from June 1, 2027, Adobe’s lifecycle policy lets it enforce version upgrades on cloud environments and decommission instances on unsupported releases. Merchants who chose the PaaS for stability should weigh that policy before renewing.

The managed specialists

Hypernode (Amsterdam, part of team.blue) is the most current managed platform we checked. Its docs list PHP 8.5 as fully supported (PHP versions doc), and its changelog dates OpenSearch 3.3 to December 2025 and Valkey 8 to October 2025, with no Valkey 9 statement yet. Magento tooling is native: hypernode-deploy with a Magento 2 template, staging via Brancher on the Falcon plans. Published pricing runs from EUR 129 per month for the smallest Falcon production node to EUR 3,462 for the largest, excluding VAT; the AWS-based Eagle line runs from EUR 672 to EUR 33,409. The caveats are operational. No public SLA document with an uptime percentage was found; the figures that exist sit in a docs page attributed to the infrastructure providers, 99.9% for the Falcon line and 99.95% for the AWS infrastructure behind Eagle. Free support runs office hours (9:00 to 18:00 CET/CEST); per its emergency-support doc, out-of-hours help is free when the cause is a Hypernode outage and otherwise billed EUR 100 to 200 by SLA level for the first hour, then hourly at the same rate. The Falcon line runs in Belgium; Frankfurt requires the Eagle line. The status page is public with visible incident history.

maxcluster (Paderborn, part of team.blue since 2023) runs managed failover clusters in German data centers and names Mage-OS and Hyvä support explicitly. Its SLA document guarantees “99,99% Verfügbarkeit” of hardware and network as a yearly average (at most 52 minutes down a year) and commits to a first response within 30 minutes, around the clock, via its emergency line. Routine support and services work run office hours. Its public roadmap dates PHP 8.5 to December 2025 and Valkey to November 2025, without a version number; an explicit OpenSearch 3 statement was not found. Pricing is public but lives in a German-language PDF price list dated January 12, 2026. Clusters start at EUR 19 per month for the smallest failover pair, though that entry cluster (1 CPU, 2 GB RAM) is below what a Magento 2.4 stack needs, and a Magento-sized cluster prices well above it, plus a managed-SLA tier that runs up to EUR 350 per month (Enterprise). Per the same price list, hands-on work beyond the SLA is metered (developer support EUR 30 per 15 minutes in office hours, EUR 50 outside them), and the automatic malware scan becomes a paid add-on for the lower tiers from January 1, 2027.

MGT-Commerce (Berlin) sells a different shape: a management fee on top of AWS infrastructure that runs in your own AWS account, “billed separately to your own AWS account for full transparency” (homepage). That structure means real cost transparency and portability, and it means two bills. The stack covers Varnish, Valkey or Redis, OpenSearch or Elasticsearch and RabbitMQ; the hosting page states PHP 8.1 to 8.4, with no PHP 8.5 platform statement yet even though its own blog covers 2.4.9’s requirements. Management fees are published (from EUR 149 per month for a single server, EUR 1,499 for auto-scaling), though tier names and figures differ between the homepage and the plan sub-pages. On availability, the homepage advertises 99.99% and 99.95% at once, and the SLA overview page states a “99.95% network uptime guarantee” with no credit scheme, exclusions or claim procedure; no public status page was found. The “15 Min Response Time” line is the vendor’s marketing average; the SLA page commits to under 24 hours for general guidance and emergency responses from under 8 hours on the entry tier to under 30 minutes on the top auto-scaling tier.

JetRails (Illinois) is Magento-centric and provisions single-tenant AWS environments through its AutoPilot portal, with root access and hourly billing; its December 2025 changelog records OpenSearch 3.2 and default Magento provisioning at “v2.4.8.2”. No PHP support matrix exists on its marketing pages or changelogs; an article on its support portal documents switchable PHP-FPM versions to 8.3. JetRails’ marketing claims 99.99% uptime (in its pages’ search snippets), a figure its terms of service never state: the terms promise “commercially reasonable efforts”, with credits capped at two weeks per month, under Illinois law. Public pricing is a range (“Our regular configurations range between $100-$2,500 per month” on the Magento page); exact quotes require an account. Dedicated servers are stated as US data centers, and no marketing page documents selectable EU regions (a JetRails Cloud FAQ says multi-region setups are supported, without naming regions), which makes EU data residency a question to settle in writing before signing. The status page is public.

Nexcess, one of the longest-standing Magento hosts, now sells through Liquid Web: the Magento plans run on Nexcess infrastructure, from $74 per month at list for the smallest plan (promotional pricing shown first), USD only. Every plan carries Varnish, Redis and a dedicated OpenSearch container; the platform provides staging, SSH and Git. The gap is in how current the stack is and how clearly it is stated: the vendor’s own reference page still called 2.4.8 the latest Magento version when we checked, the one reachable docs page that enumerates PHP versions (for its cPanel line) stops at 8.3, and no PHP, OpenSearch or Valkey statement was found for the Magento plans themselves. The marketing page advertises “99.99% uptime guaranteed” while the SLA page contains no such figure. Its Nexcess section, which the plans’ infrastructure points to (confirm at signing which scheme applies), promises 100% uninterrupted transit, with credits of 5% of monthly fees for every 15 minutes of verified outage beyond the first 15 minutes in a month, capped at a month’s fees, claims within seven days, verified against the vendor’s own logs. EU-mainland presence is one location, Amsterdam, per the status page. Nearly two decades of Magento history and the brand churn since the Liquid Web merger are both visible in its pages.

Cloudways (part of DigitalOcean) is the budget managed option smaller stores choose, and the checkable facts warrant caution. It manages the server, and its scope of support excludes the application: debugging custom code, application-level security and module upgrades are out of scope. Its changelog dates Magento 2.4.8 support to July 2025 and PHP 8.4 to September 2025, and lists available search-engine versions topping out at OpenSearch 2.19, while Adobe’s tested combinations for 2.4.8-p5 and 2.4.9 list only OpenSearch 3. There is no infrastructure SLA at all; the only published SLA covers the support console and states it does not apply to the cloud providers’ availability (support SLA). Data-center location is picked on the underlying provider; the Magento hosting page lists Amsterdam, Frankfurt and London among DigitalOcean’s locations. Pricing is published and genuinely low, from $11 per month on DigitalOcean. For a store that fits inside one server and a team that owns Magento itself, it can work on the release line you are on; until Cloudways ships OpenSearch 3, an upgrade to 2.4.8-p5 or 2.4.9 leaves Adobe’s tested combinations. The specialization does not extend past provisioning.

The Czech and Polish options

vshosting~ (Prague, part of the Contabo Group per its about page) is, by its own account, the managed-infrastructure provider Czech and Slovak e-commerce uses most; that self-description (on its own site) and its client lists are the vendor’s claims, with no independent measurement we could find. What is documented: a published Magento reference for Takoy (“a hosting solution tailored to Magento”), its own Prague data center plus local German data centers it uses, and managed-server pricing from EUR 217 per server per month, with the fine print that the starting prices assume ten or more servers on 36-month contracts; “Administrator Response Within 60 Seconds” by phone and 24/7 monitoring are the vendor’s wording. No per-plan Magento package pricing is published, and the pages we checked state no SLA percentage or stack versions.

Centuria (Poznań) is the clearest Polish managed-Magento specialist we found: a dedicated Magento hosting page with 24/7 service desk, named data centers (Equinix Frankfurt, Beyond and Talex in Poznań) and testimonials from Castorama and CD PROJEKT RED’s store (vendor-published). Its published stack names Varnish, Redis and Elasticsearch; Elasticsearch 8 is still within Adobe’s tested combinations for 2.4.8-p5, Redis is not, so the page’s component list is worth a direct question. Pricing is indicative only: monthly maintenance from about PLN 1,500 to 2,000 per its own page.

The search also settled which providers to rule out. WEDOS, whose hosting now trades as VEDOS, answered in its knowledge base in 2019 that it recommends a VPS for Magento and calls running it on their webhosting problematic, and we found no newer Magento guidance there. Websupport documents only that Magento can be installed on shared hosting despite limitations, and no Magento hosting page was found at Forpsi, Master Internet or cyber_Folks. We found no Slovak-domiciled managed-Magento specialist at all; Slovak stores in this tier buy from the Czech, Polish, German or international providers here. OVHcloud’s Polish Magento page exists but recommends self-managed VPS or dedicated servers, which places it with the self-managed options.

Self-managed: AWS and Hetzner

Running Magento on raw cloud is a real option with a plain price: your team becomes the managed host. On AWS, the managed services map onto part of the stack (Aurora for the database, OpenSearch Service, ElastiCache, Amazon MQ), and Adobe’s requirements table carries AWS-specific rows for exactly these, plus S3; Adobe’s ElastiCache row lists “ElastiCache 7.1 for Redis OSS (enhanced). Valkey 8 is available.” as the tested combination, and CloudFront covers the CDN outside the table. Varnish, PHP-FPM, cron and the queue workers stay on EC2 you administer, and a multi-AZ setup adds Magento-specific work of its own: shared media storage, shared sessions and cache, database failover, and a single owner for cron and the consumers. What AWS does not have is a production-ready first-party Magento path: its Magento whitepaper carries the banner “This whitepaper is for historical reference only”, the Terraform module it links is labeled beta and not recommended for production (last commit August 2025), the original Magento Quick Start page no longer exists, and the reference architecture repository has not been touched since April 2018 and sits archived. SLAs are per-service and credit-only: 99.99% for EC2 requires a multi-AZ deployment, and a single instance carries 99.5% (compute SLA). Eight European regions are available, six of them in EU member states, including Frankfurt. The cost is metered across many line items; we quote no totals, because a realistic total requires modeling your own traffic.

Hetzner is the EU cost baseline, and it documents almost nothing about Magento: no product page, no one-click app, no version matrix. The closest things are a community-written tutorial (in German) for its Managed Server line and the docs page that links it; the tutorial documents the friction itself, a self-installed OpenSearch that needs a support-approved Java process, with no RabbitMQ documented. On the Managed Server line, Magento remains a self-installed workaround with no product support behind it. What Hetzner sells is capable, well-priced infrastructure and nothing above it: cloud instances from EUR 5.99 per month with an IPv4 address for 2 vCPU and 4 GB (cloud page; prices render client-side), dedicated servers beyond, EU data centers in Germany and Finland (US and Singapore locations exist too), free network-level DDoS protection, and a cloud SLA of “commercially reasonable efforts to ensure a monthly availability of 99.9%”, with credits paid in Cloud Credits, capped at that server’s monthly invoice and claimed within 14 days (cloud terms). On Hetzner, the entire Magento stack, and the on-call duty, is yours. A store on one of the managed plans above, from EUR 129 per month at Hypernode or EUR 149 at MGT-Commerce, is partly paying for the operational work this section describes.

Side by side

“Not found”, “not stated”, “not published” and “not documented” all record our own searches of the linked pages; “your job” means the merchant installs and tracks the stack. “Current stack” compares each vendor’s published component versions against Adobe’s 2.4.8-p5/2.4.9 tables (PHP 8.3–8.5 depending on the line, OpenSearch 3 or, on 2.4.8-p5 only, Elasticsearch 8, Valkey). All as of August 3, 2026.

Choosing between the tiers

Start with the license. Magento Open Source and Mage-OS stores cannot buy Adobe’s cloud, and their choice is between a managed specialist and their own infrastructure. An Adobe Commerce license opens all three tiers: the first-party cloud, with its SLA and its 2027 forced-upgrade policy, is one more option beside the specialists, several of which host Adobe Commerce too.

Between a specialist and your own cloud, the deciding variable is your team. A managed specialist is worth its price when nobody on staff should be tracking OpenSearch versions or holding the on-call duty; the comparison above then narrows to who is current, who writes their SLA down, and who documents your data center. On the published evidence, Hypernode tracks the platform closest, with maxcluster and JetRails current on parts of the stack and silent on the rest; maxcluster documents German data centers and vshosting its own Prague site, while on MGT-Commerce the data sits in whichever AWS region you run. Self-managed AWS or Hetzner wins when a capable team already exists and the store needs either scale economics or a topology no plan offers; it costs part of the team’s attention permanently, and that cost appears on no invoice.

Whichever way the comparison points, moving is its own project with its own bill: syncing media at catalog scale, reindexing search on the new stack, carrying over cron and queue state, TLS and DNS cutover, and a freeze window that must miss the sales peak. Budget the migration before comparing plan prices; a cheaper plan plus a migration can cost more than the incumbent’s renewal.

For the Czech, Slovak and Polish market specifically, the local managed providers are ahead on language and data location, but they publish less: no fixed Magento plans, indicative or conditional pricing, no SLA percentages on the pages we checked, and no stack versions to compare. Ask for the SLA, the price, the contract term and the notice period in writing; a discount bound to a 36-month term, as in vshosting’s entry pricing, is part of the price. Among the internationals, maxcluster and Nexcess publish contractual SLA terms with their prices, and most publish at least prices; a local provider can be asked to match that in writing.

Hosting is one of the three columns this practice’s DevOps service covers, and the same assessment runs inside our Magento work: which tier fits, whether the current host still matches Adobe’s requirements table, and what the migration would cost if not. Whoever hosts you, tracking that table is a task someone must own.