---
title: "Choosing hosting for Magento 2"
description: "Adobe's cloud, managed Magento specialists, and your own AWS or Hetzner: who runs which layer, who keeps up with the platform's requirements, what the SLAs say, and what is published about pricing, checked against the vendors' own pages."
author: "Luboš Zápotočný"
published: "2026-08-04"
language: "en"
canonical: "https://zapolu.com/blog/magento-hosting/"
---

# 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](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements)
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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions)),
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](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/search-engine/overview)),
  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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/redis/redis-pg-cache)).
- **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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/configure-cron-jobs):
"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](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/message-queues/manage-message-queues);
keeping them healthy is the host's or the team's job. RabbitMQ is
[optional in general](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/message-brokers/rabbitmq)
and
[the default for the Bulk API](https://developer.adobe.com/commerce/webapi/rest/use-rest/bulk-endpoints/).
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](https://mage-os.org/get-started/system-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](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview)).
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](https://aws.amazon.com/compliance/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](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en),
adopted July 10, 2023; the EU General Court upheld it against the
Latombe challenge on September 3, 2025
([IAPP report](https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework/)),
and Latombe's
[further appeal](https://digitalpolicyalert.org/event/35459)
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](https://www.dataprivacyframework.gov/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](https://listings.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf)).
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](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/pro-architecture);
its
[security guide](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/security)
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](https://www.adobe.com/cc-shared/assets/pdf/legal/terms/enterprise/pdfs/unified-sla-actionabilityaddendum2025oct12.pdf)
(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](https://experienceleague.adobe.com/en/docs/commerce/user-guides/product-solutions)
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](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview):
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](https://business.adobe.com/blog/continued-investment-support-adobe-commerce-on-cloud)
(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](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/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](https://docs.hypernode.com/hypernode-platform/php/supported-php-versions-and-how-to-change-them-on-hypernode.html)),
and its changelog dates
[OpenSearch 3.3 to December 2025](https://changelog.hypernode.com/release-10641-opensearch-3-3-available-on-hypernode/)
and
[Valkey 8 to October 2025](https://changelog.hypernode.com/release-10564-valkey-8-now-available-at-hypernode/),
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](https://www.hypernode.com/en/plans-and-prices/) 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](https://docs.hypernode.com/about-hypernode/about-hypernode/which-cloud-providers-do-we-use.html)
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](https://docs.hypernode.com/about-hypernode/support/emergency-support-outside-office-hours.html),
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](https://www.hypernode-status.com/) is public with
visible incident history.

**maxcluster** (Paderborn, part of
[team.blue since 2023](https://press.team.blue/228140-maxcluster-becomes-part-of-team-blue/))
runs managed failover clusters in German data centers and
[names Mage-OS and Hyvä support explicitly](https://maxcluster.de/magento-hosting).
Its [SLA document](https://maxcluster.de/sla) 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](https://maxcluster.de/en/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](https://maxcluster.de/preise) 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](https://www.mgt-commerce.com/)). 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](https://www.mgt-commerce.com/magento-hosting/) 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](https://www.mgt-commerce.com/service-level-agreements)
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](https://jetrails.com/december-2025-autopilot-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](https://learn.jetrails.com/) 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](https://jetrails.com/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](https://jetrails.com/magento-hosting/)); exact quotes
require an account.
[Dedicated servers](https://jetrails.com/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](https://jetrails-status.com/) is public.

**Nexcess**, one of the longest-standing Magento hosts, now sells
through Liquid Web: the
[Magento plans](https://www.liquidweb.com/magento-hosting/) 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](https://www.liquidweb.com/magento/latest-magento-version/)
still called 2.4.8 the latest Magento version when we checked, the
one reachable
[docs page](https://docs.nexcess.com/hosting/control-panel/whm/php-management/using-the-cloudlinux-php-selector-in-cpanel-and-whm/)
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](https://www.liquidweb.com/policies/sla/) 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](https://status.nexcess.net/).
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](https://www.cloudways.com/en/support.php)
excludes the application: debugging custom code, application-level
security and module upgrades are out of scope. Its
[changelog](https://www.cloudways.com/en/changelog.php) 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](https://www.cloudways.com/en/support-sla.php)).
Data-center location is picked on the underlying provider; the
[Magento hosting page](https://www.cloudways.com/en/magento-hosting.php)
lists Amsterdam, Frankfurt and London among DigitalOcean's
locations.
[Pricing](https://www.cloudways.com/en/pricing.php) 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](https://vshosting.eu/about)) is, by its own account,
the managed-infrastructure provider Czech and Slovak e-commerce uses
most; that self-description
([on its own site](https://vshosting.cz/blog/vshosting-nejvetsi-e-commerce-infrastructure-provider))
and its client lists are the vendor's claims, with no independent
measurement we could find. What is documented: a
[published Magento reference](https://vshosting.eu/references/takoy)
for Takoy ("a hosting solution tailored to Magento"), its own Prague
data center plus local German data centers it uses, and
[managed-server pricing](https://vshosting.eu/services/managed-servers)
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](https://centuria.pl/en/magento-hosting/) 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](https://help.wedos.cz/otazka/hosting-magento-2/2697/)
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](https://www.websupport.sk/podpora/kb/instalacia-cms-magento-cez-webovu-konzolu/)
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](https://www.ovhcloud.com/pl/web-hosting/magento-hosting/)
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](https://docs.aws.amazon.com/whitepapers/latest/migrating-magento-open-source-adobe-commerce-to-aws/migrating-magento-open-source-adobe-commerce-to-aws.html)
carries the banner "This whitepaper is for historical reference
only", the
[Terraform module](https://github.com/aws-ia/terraform-adobe-magento)
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](https://github.com/amazon-archives/aws-refarch-magento)
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](https://aws.amazon.com/compute/sla/)). Eight
[European regions](https://docs.aws.amazon.com/general/latest/gr/rande.html)
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](https://community.hetzner.com/tutorials/install-magento-on-managed-server/)
(in German) for its Managed Server line and the
[docs page](https://docs.hetzner.com/konsoleh/account-management/managed-server-tutorials/magento/)
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](https://www.hetzner.com/cloud/); 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](https://www.hetzner.com/unternehmen/ddos-schutz/),
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](https://www.hetzner.com/legal/cloud-server/)). 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

| Option | Model | Uptime in the SLA | Current stack, as stated | EU locations | Public pricing |
| ------ | ----- | ----------------- | ------------------------ | ------------ | -------------- |
| Adobe cloud (PaaS) | First-party PaaS | 99.99% (SLA addendum) | First-party | AWS/Azure, customer-chosen | No |
| Hypernode | Managed | No SLA doc; 99.9–99.95% in docs | PHP 8.5, OpenSearch 3.3, Valkey 8 | BE; DE via AWS line | Yes |
| maxcluster | Managed | 99.99% yearly average | PHP 8.5 (roadmap), Valkey unversioned | DE | Yes (PDF) |
| MGT-Commerce | Fee + your AWS | 99.95%, no credit terms | PHP to 8.4 stated | AWS regions, not pinned | Fees yes, AWS metered |
| JetRails | Managed on AWS | No percentage in terms | OpenSearch 3.2; PHP-FPM to 8.3 in support docs | Not documented | Range only |
| Nexcess (Liquid Web) | Managed | 100% transit, 5% credits per 15 min | Not stated; cPanel docs reach PHP 8.3 | Amsterdam | Yes (USD) |
| Cloudways | Server-managed | Support-only SLA | PHP 8.4; OpenSearch 2.19 | Via chosen IaaS | Yes |
| vshosting~ | Managed | Not found | Not published | CZ, DE | Entry prices |
| Centuria | Managed | Not found | Names Redis, Elasticsearch | PL, DE | Indicative |
| AWS (self-managed) | IaaS | Per-service | Your job | 6 EU regions | Metered |
| Hetzner (self-managed) | IaaS | 99.9% efforts-based | Your job | DE, FI | Yes |

"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](/services/devops/) covers, and the same assessment
runs inside our [Magento work](/services/magento/): 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.