---
title: "Hosting für Magento 2 auswählen"
description: "Adobes Cloud, spezialisierte Managed-Anbieter oder eigenes AWS bzw. Hetzner: wer welche Schicht betreibt, wer mit den Anforderungen der Plattform Schritt hält, was tatsächlich im SLA steht und was zu den Preisen veröffentlicht ist, geprüft anhand der Anbieterseiten."
author: "Luboš Zápotočný"
published: "2026-08-04"
language: "de"
canonical: "https://zapolu.com/de/blog/hosting-fuer-magento/"
---

# Hosting für Magento 2 auswählen

Magento-Hosting wird als Paket mit Spezifikationen verkauft, doch
die eigentliche Entscheidung betrifft die Verantwortung. Jemand
muss das Betriebssystem patchen, OpenSearch aktualisieren, wenn
sich Adobes Anforderungen ändern, Cronjobs und die
Warteschlangen-Consumer am Laufen halten und reagieren, wenn der
Shop nicht erreichbar ist. Jede Hosting-Stufe beantwortet die
Frage nach dieser Verantwortung anders.

Dieser Beitrag legt dar, was Magento von der Infrastruktur
verlangt, liefert eine Checkliste zur Beurteilung eines
Hosting-Anbieters und wendet sie auf die drei Stufen an: Adobes
eigene Cloud, die spezialisierten Managed-Magento-Anbieter
(einschließlich der tschechischen und polnischen Anbieter, die in
dieser Region verfügbar sind) und selbstverwaltete Infrastruktur
auf AWS oder Hetzner. Jede Angabe zu den Anbietern wurde am
3. August 2026 anhand der verlinkten Quelle geprüft; wo etwas
nicht verifiziert werden konnte, wird das so vermerkt.

## Was Magento von einem Server verlangt

Adobe veröffentlicht pro Versionslinie eine
[Tabelle geprüfter Systemkombinationen](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements)
und macht deren Geltungsbereich ausdrücklich klar: „Adobe
unterstützt nur die in den folgenden Tabellen aufgeführten
Systemkombinationen.“ Für Magento 2.4.9 (veröffentlicht am
12. Mai 2026, laut der
[Seite mit den veröffentlichten Versionen](https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions))
listet die Tabelle für On-Premises-Installationen OpenSearch 3,
MariaDB 12.3, MySQL 8.4, PHP 8.5, RabbitMQ 4.3, Valkey 9,
Varnish 8 und nginx 1.30 auf. Die Tabelle für 2.4.8-p5 bleibt einen
Schritt zurück: PHP 8.4 und 8.3, wobei Elasticsearch 8 noch neben
OpenSearch 3 aufgeführt ist, dazu Valkey 8.1. Drei Verschiebungen
in diesen Tabellen entscheiden darüber, ob ein Host aktuell ist:

- **OpenSearch ist Pflicht; Elasticsearch verschwindet aus der
  Tabelle der geprüften Systeme.** „Ab Adobe Commerce 2.4 müssen
  alle Installationen so konfiguriert sein, dass Elasticsearch oder
  OpenSearch als Suchlösung für den Katalog verwendet wird“
  ([Voraussetzungen für die Suchmaschine](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/search-engine/overview)),
  und die Tabelle für 2.4.9 listet nur noch OpenSearch 3 auf, eine
  Zeile für Elasticsearch fehlt ganz. Elasticsearch 7.17 erreichte
  laut Adobes Seite zu den Systemanforderungen am 15. Januar 2026
  das Supportende.
- **Valkey hat Redis abgelöst.** Die Tabellen für 2.4.9 und
  2.4.8-p5 enthalten überhaupt keine Redis-Zeile mehr, die
  jüngsten Patches der Versionslinien 2.4.5 bis 2.4.7 kennzeichnen
  Redis als „nicht unterstützt“ und führen stattdessen Valkey auf,
  und Adobes Cache-Dokumentation hält fest: „Ab Adobe Commerce
  2.4.9 hat Valkey Redis in den CLI-Tools offiziell abgelöst“
  ([Dokumentation zum Redis-Seiten-Cache](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/redis/redis-pg-cache)).
- **MySQL 8.0 erreichte am 30. April 2026 das Supportende**, und
  Adobes Seite zu den Systemanforderungen empfiehlt den betroffenen
  Versionslinien den Umstieg auf MariaDB.

Neben der Tabelle schließen zwei betriebliche Anforderungen
generisches Shared Hosting aus.
[Cron ist zwingend erforderlich](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/configure-cron-jobs):
„Commerce ist für viele wichtige Systemfunktionen, einschließlich
der Indizierung, auf eine korrekt konfigurierte Cron-Aufgabe
angewiesen. Wird sie nicht richtig eingerichtet, funktioniert
Commerce nicht wie vorgesehen“, und zu den von Cron abhängigen
Funktionen zählen sämtliche Transaktions-E-Mails.
Queue-Consumer sind Worker-Prozesse, die Cron standardmäßig
[in Batches neu startet](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/message-queues/manage-message-queues);
dafür zu sorgen, dass sie laufen, ist Aufgabe des Hosts oder des
Teams. RabbitMQ ist
[im Allgemeinen optional](https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/prerequisites/message-brokers/rabbitmq)
und
[Standard für die Bulk API](https://developer.adobe.com/commerce/webapi/rest/use-rest/bulk-endpoints/).
Ein Host, der PHP und MySQL anbietet, aber weder OpenSearch noch
einen Valkey-gestützten Cache noch Varnish noch mehrere
Worker-Prozesse betreiben kann, kann Magento nicht so betreiben, wie Adobe es
testet, unabhängig davon, was auf der Tarifseite steht. Mage-OS veröffentlicht
[eigene Anforderungen](https://mage-os.org/get-started/system-requirements)
mit niedrigeren Mindestwerten (PHP 8.3 aufwärts, OpenSearch 2
aufwärts, wobei Elasticsearch und Redis weiterhin aufgeführt
sind), doch die Grundstruktur des Stacks bleibt gleich: Eine
Suchmaschine, Cron und Worker-Prozesse bleiben Pflicht, unabhängig
davon, welche Distribution eingesetzt wird.

## Die Checkliste: wer betreibt was, und was ist schriftlich festgehalten

**Wer betreibt welche Schicht.** Die drei Stufen teilen die
Arbeit unterschiedlich auf. Bei Adobes PaaS betreibt Adobe die
Infrastruktur, und der Händler verwaltet weiterhin „den
Anwendungscode, Upgrades, Patches und die
Infrastrukturkonfiguration innerhalb der von Adobe gehosteten
Umgebung“
([Adobes Migrationsleitfaden](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview)).
Bei einem spezialisierten Managed-Anbieter betreibt der Host den
Stack, und das Team oder die Agentur des Händlers betreibt Magento
selbst. Bei selbstverwalteter Infrastruktur ist AWS'
[Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/)
eindeutig: Kunden, die EC2 einsetzen, „sind für die Verwaltung des
Gastbetriebssystems (einschließlich Updates und
Sicherheitspatches)“ und für alles darüber verantwortlich.
Arbeiten auf Anwendungsebene, Magento-Upgrades, Erweiterungen,
eigener Code, gehen auf keiner Stufe je an einen Host über. Es
stellt sich nur die Frage, wo darunter die Grenze verläuft.

**Ob der Host mit der Plattform Schritt hält.** Die oben genannten
Anforderungen ändern sich mit jedem Release-Zyklus, und Hosts
hinken ihnen um dokumentierte, überprüfbare Beträge hinterher.
Vergleichen Sie die veröffentlichten Komponentenversionen des
Hosts (PHP, OpenSearch, Valkey) mit Adobes aktueller Tabelle; die
Profile weiter unten halten fest, was jeder Anbieter angibt, und
eine fehlende Versionsangabe ist ein Grund, vor Vertragsabschluss
nachzufragen. Der Rückstand wiegt am schwersten, wenn Sie neu
aufsetzen oder auf die neueste Versionslinie aktualisieren; ein
Host, der den geprüften Kombinationen der von Ihnen verwendeten
Versionslinie entspricht, bleibt bis zu deren Supportende
unterstützt.

**Was das SLA-Dokument selbst aussagt.** Mehrere Anbieter werben
mit Verfügbarkeitswerten, die auf ihren eigenen rechtlichen Seiten
gar nicht stehen; die Abweichungen, die wir gefunden haben, sind in
den Profilen vermerkt. Prüfen Sie, wie das Gutschriftsystem
aussieht, wer einen Ausfall verifiziert und bis zu welcher Frist
ein Anspruch eingereicht werden muss. Die strukturelle Grenze gilt
überall gleich: Der Anbieter selbst meldet den Ausfall, kündigt
seine eigene Wartung an, und seine eigenen Protokolle entscheiden
über den Anspruch. Gutschriften sind gedeckelt, in den von uns
gelesenen Bedingungen auf eine Monatsgebühr oder weniger; jede
gefundene Deckelung ist unten vermerkt. Eine öffentliche
Statusseite mit einsehbarer Vorfallshistorie lohnt sich trotzdem,
und jede, die wir gefunden haben, ist verlinkt.

**Der Betrieb hinter der Tarifseite.** Vier Fragen unterscheiden
einen Magento-Spezialisten von einem generischen Managed-Host, und
keiner der im Folgenden vorgestellten Anbieter veröffentlicht
vollständige Antworten darauf. Wie geht der Tarif mit einer Verkaufsspitze um:
Vorlaufzeit für eine Größenänderung, Autoscaling, und welche
Kapazitätsplanung für die Hochsaison ist enthalten. Wie lange
dauert eine Wiederherstellung bei einem Datensatz in
Produktionsgröße, und erfolgt die Datenbankwiederherstellung
zeitpunktgenau oder nur per Snapshot; der Backup-Zeitplan ist der
einfache Teil davon. Was macht ein Deploy mit dem laufenden Shop:
Wartungsfenster oder atomarer Wechsel, und entspricht die
Staging-Umgebung der Produktionsumgebung? Und bei
Multi-Server-Tarifen: Welcher Knoten übernimmt Cron und die
Queue-Consumer, und wie werden sie vom Webtraffic ferngehalten?
Stellen Sie alle vier Fragen; die Antworten sind selten öffentlich.

**Datenstandort und Rechtsgrundlage für US-Anbieter.**
EU-US-Datentransfers stützen sich derzeit auf das
[EU-US Data Privacy Framework](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/eu-us-data-transfers_en),
angenommen am 10. Juli 2023; das Gericht der Europäischen Union
wies die Klage von Latombe am 3. September 2025 zurück und bestätigte den Rahmen damit
([IAPP-Bericht](https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework/)),
und Latombes
[weiterer Rechtsbehelf](https://digitalpolicyalert.org/event/35459)
beim Gerichtshof der Europäischen Union (Rechtssache C-703/25 P,
eingereicht am 31. Oktober 2025) war bei unserer Prüfung im
August 2026 noch anhängig. Die Teilnahme eines Hosts in
US-Besitz lässt sich anhand der
[offiziellen DPF-Liste](https://www.dataprivacyframework.gov/list)
überprüfen. Die praktische Prüfung ist einfacher: Dokumentiert der
Anbieter schriftlich, in welchem Rechenzentrum Ihr Shop läuft? Die
Profile halten fest, wer das tut.

**Die PCI-Aufteilung.** Ein Hosting-Anbieter ist ein Drittanbieter
(Third-Party Service Provider) im Sinne von PCI DSS, und der
Zusatz des Councils von 2016 zur Absicherung durch Drittanbieter
ist unmissverständlich: „Die Nutzung eines TPSP entbindet das
Unternehmen jedoch nicht von der letztendlichen Verantwortung für
seine eigene PCI-DSS-Konformität …“
([PCI-SSC-Zusatz](https://listings.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf)).
Verlangen Sie vom Host dessen Attestation of Compliance als
Service Provider und bewahren Sie die Matrix auf, welche
Anforderungen er abdeckt; der Anteil des Händlers an dieser
Aufteilung bleibt bei Ihnen.

**Wie jede Stufe die Preise gestaltet.** Spezialisierte
Managed-Anbieter verkaufen feste Tarife, nutzungsabhängig
abgerechnete Konfigurationen (JetRails) oder, bei MGT-Commerce,
eine Verwaltungsgebühr zuzüglich der eigenen Cloud-Rechnung;
selbstverwaltete Infrastruktur wird verbrauchsabhängig
abgerechnet; Adobe nennt Preise nur im Direktvertrieb. Alle
folgenden Zahlen verstehen sich netto ohne Mehrwertsteuer, die
EU-Unternehmen ohnehin per Reverse-Charge-Verfahren abführen; die
in USD abrechnenden Anbieter bringen zusätzlich Wechselkurskosten
und Währungsrisiko mit, die bei den in EUR abrechnenden nicht
anfallen. Die Profile geben veröffentlichte Zahlen wörtlich
wieder; wo ein Anbieter keine veröffentlicht, wird das vermerkt,
und wir schätzen keine Gesamtsummen für verbrauchsabhängige
Setups.

## Adobes Cloud: die First-Party-Stufe

Adobe Commerce auf Cloud-Infrastruktur ist die PaaS-Lösung des
Plattformanbieters selbst, die laut
[Pro-Architekturdokumentation](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/pro-architecture)
auf AWS läuft, bei Pro auf Azure; der
[Sicherheitsleitfaden](https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/architecture/security)
dokumentiert das gebündelte Fastly-CDN mit DDoS-Schutz und WAF,
stündliche Produktions-Backups, und dass Produktionsinstanzen in
den meisten AWS-Regionen laufen können, wobei der Kunde festlegt,
wo die Produktion liegt. Adobes einheitlicher
[SLA-Zusatz](https://www.adobe.com/cc-shared/assets/pdf/legal/terms/enterprise/pdfs/unified-sla-actionabilityaddendum2025oct12.pdf)
(gültig seit dem 12. Oktober 2025) definiert die Zusage als „99,99 % für die von Adobe gehostete
Infrastruktur der Produktionsumgebung“. Für diese Stufe gelten zwei
Einschränkungen.
Lizenzierung: Es handelt sich um ein Adobe-Commerce-Produkt, und
Adobes
[Seite zu den Produktlösungen](https://experienceleague.adobe.com/en/docs/commerce/user-guides/product-solutions)
stuft Open-Source-Installationen als kundenverwaltet und
selbstgehostet ein; auch Mage-OS, das in Adobes Dokumentation gar
nicht erwähnt wird, hat keinen Zugang zu dieser Stufe. Preise:
nirgends öffentlich; im Netz kursierende Zahlen sind Schätzungen
Dritter, die wir hier nicht wiederholen.

Adobe verändert zudem den Charakter dieser Stufe. 2025 wurde Adobe
Commerce as a Cloud Service (SaaS) eingeführt, und Adobe
veröffentlicht einen
[Migrationsleitfaden](https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview):
Die SaaS-Variante sperrt den Kernanwendungscode und verlagert
Anpassungen auf APIs und den App Builder, und der von Adobe
favorisierte Storefront läuft auf Edge Delivery Services, für
Luma-Shops verpflichtend, während bestehende PWA- und
Headless-Storefronts beibehalten werden können. Für einen
Luma-Shop ist der Wechsel eher eine Neuarchitektur als eine
einfache Migration. Adobes eigener Blog
[erklärt, dass für die PaaS kein Supportende geplant ist](https://business.adobe.com/blog/continued-investment-support-adobe-commerce-on-cloud)
(die Seite ließ sich bei uns nicht laden; die Aussage stammt aus
dem indexierten Text). Entscheidend ist ein anderes, festes Datum: Ab
dem 1. Juni 2027 erlaubt Adobes
[Lifecycle-Policy](https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy)
Adobe, Versions-Upgrades in Cloud-Umgebungen durchzusetzen und
Instanzen mit nicht mehr unterstützten Versionen stillzulegen.
Händler, die sich wegen der Stabilität für die PaaS entschieden
haben, sollten diese Richtlinie vor einer Vertragsverlängerung
abwägen.

## Die spezialisierten Managed-Anbieter

**Hypernode** (Amsterdam, Teil von team.blue) ist die aktuellste
Managed-Plattform, die wir geprüft haben. Die Dokumentation nennt PHP 8.5 als
vollständig unterstützt
([Dokumentation zu PHP-Versionen](https://docs.hypernode.com/hypernode-platform/php/supported-php-versions-and-how-to-change-them-on-hypernode.html)),
und das Changelog nennt
[Dezember 2025 für OpenSearch 3.3](https://changelog.hypernode.com/release-10641-opensearch-3-3-available-on-hypernode/)
und
[Oktober 2025 für Valkey 8](https://changelog.hypernode.com/release-10564-valkey-8-now-available-at-hypernode/),
eine Angabe zu Valkey 9 fehlt bislang. Die Magento-Werkzeuge sind
nativ: `hypernode-deploy` mit einer Magento-2-Vorlage, Staging über
Brancher auf den Falcon-Tarifen. Die veröffentlichten
[Preise](https://www.hypernode.com/en/plans-and-prices/) reichen
von 129 EUR pro Monat für den kleinsten Falcon-Produktionsknoten
bis 3.462 EUR für den größten, exklusive Mehrwertsteuer; die
AWS-basierte Eagle-Linie reicht von 672 EUR bis 33.409 EUR. Die
Einschränkungen betreffen den Betrieb. Ein öffentliches
SLA-Dokument mit einer Verfügbarkeitsangabe wurde nicht gefunden;
die vorhandenen Zahlen stehen auf einer
[Dokumentationsseite](https://docs.hypernode.com/about-hypernode/about-hypernode/which-cloud-providers-do-we-use.html)
und werden den Infrastrukturanbietern zugeschrieben, 99,9 % für
die Falcon-Linie und 99,95 % für die AWS-Infrastruktur hinter
Eagle. Der kostenlose Support läuft während der Geschäftszeiten
(9:00 bis 18:00 Uhr MEZ/MESZ); laut der
[Dokumentation zum Notfallsupport](https://docs.hypernode.com/about-hypernode/support/emergency-support-outside-office-hours.html)
ist Hilfe außerhalb der Geschäftszeiten kostenlos, wenn die
Ursache ein Ausfall bei Hypernode ist, andernfalls werden je nach
SLA-Stufe für die erste Stunde 100 bis 200 EUR berechnet, danach
stündlich zum gleichen Satz. Die Falcon-Linie läuft in Belgien;
für Frankfurt ist die Eagle-Linie erforderlich. Die
[Statusseite](https://www.hypernode-status.com/) ist öffentlich
zugänglich und zeigt die Vorfallshistorie.

**maxcluster** (Paderborn, seit
[2023 Teil von team.blue](https://press.team.blue/228140-maxcluster-becomes-part-of-team-blue/))
betreibt Managed-Failover-Cluster in deutschen Rechenzentren und
[nennt Unterstützung für Mage-OS und Hyvä ausdrücklich](https://maxcluster.de/magento-hosting).
Das [SLA-Dokument](https://maxcluster.de/sla) garantiert „99,99 %
Verfügbarkeit“ von Hardware und Netzwerk im Jahresmittel (höchstens
52 Minuten Ausfall pro Jahr) und sichert eine erste Reaktion
innerhalb von 30 Minuten rund um die Uhr über die
Notfall-Hotline zu. Regulärer Support und Servicearbeiten laufen
während der Geschäftszeiten. Die
[öffentliche Roadmap](https://maxcluster.de/en/roadmap) nennt
Dezember 2025 für PHP 8.5 und November 2025 für Valkey, ohne
Versionsnummer; eine ausdrückliche Aussage zu OpenSearch 3 wurde
nicht gefunden. Die Preise sind öffentlich, stehen aber in einer
[deutschsprachigen PDF-Preisliste](https://maxcluster.de/preise)
vom 12. Januar 2026. Cluster sind ab 19 EUR pro Monat für das
kleinste Failover-Paar erhältlich, wobei dieser Einstiegscluster (1 CPU,
2 GB RAM) unter dem liegt, was ein Magento-2.4-Stack braucht, und
ein für Magento passend dimensionierter Cluster deutlich darüber
kostet, dazu eine Managed-SLA-Stufe, die bis zu 350 EUR im Monat
kostet (Enterprise). Laut derselben Preisliste wird zusätzliche Unterstützung über die SLA hinaus
verbrauchsabhängig abgerechnet
(Entwicklersupport 30 EUR pro 15 Minuten während der
Geschäftszeiten, 50 EUR außerhalb davon), und der automatische
Malware-Scan wird für die unteren Stufen ab dem 1. Januar 2027 zu
einem kostenpflichtigen Zusatz.

**MGT-Commerce** (Berlin) verkauft ein anderes Modell: eine
Verwaltungsgebühr zusätzlich zur AWS-Infrastruktur, die im
eigenen AWS-Konto läuft, „zur vollen Transparenz separat über
Ihr eigenes AWS-Konto abgerechnet“
([Startseite](https://www.mgt-commerce.com/)). Diese Struktur
bedeutet echte Kostentransparenz und Portabilität, und sie
bedeutet zwei Rechnungen. Der Stack umfasst Varnish, Valkey oder
Redis, OpenSearch oder Elasticsearch und RabbitMQ; die
[Hosting-Seite](https://www.mgt-commerce.com/magento-hosting/)
nennt PHP 8.1 bis 8.4, eine Angabe zur Plattform PHP 8.5 fehlt
bislang, obwohl der eigene Blog die Anforderungen von 2.4.9
behandelt. Die Verwaltungsgebühren sind veröffentlicht (ab
149 EUR pro Monat für einen Einzelserver, 1.499 EUR für
Auto-Scaling), wobei sich Tarifnamen und Zahlen zwischen der
Startseite und den Tarif-Unterseiten unterscheiden. Bei der
Verfügbarkeit wirbt die Startseite gleichzeitig mit 99,99 % und
99,95 %, und die
[SLA-Übersichtsseite](https://www.mgt-commerce.com/service-level-agreements)
nennt eine „99,95 % Netzwerkverfügbarkeitsgarantie“ ohne
Gutschriftregelung, Ausschlüsse oder Anspruchsverfahren; eine
öffentliche Statusseite wurde nicht gefunden. Die Angabe „15 Min
Response Time“ ist der vom Anbieter beworbene Durchschnittswert;
die SLA-Seite sichert unter 24 Stunden für allgemeine Anfragen zu
sowie Notfallreaktionen von unter 8 Stunden im Einstiegstarif bis
unter 30 Minuten im höchsten Auto-Scaling-Tarif.

**JetRails** (Illinois) ist auf Magento fokussiert und stellt
Single-Tenant-AWS-Umgebungen über sein AutoPilot-Portal bereit,
mit Root-Zugriff und stundenweiser Abrechnung; das
[Changelog](https://jetrails.com/december-2025-autopilot-changelog/)
vom Dezember 2025 nennt OpenSearch 3.2 und als Standard-Vorgabe
für Magento „v2.4.8.2“. Auf den Marketingseiten oder in den
Changelogs findet sich keine PHP-Supportmatrix; ein Artikel im
[Support-Portal](https://learn.jetrails.com/) dokumentiert
umschaltbare PHP-FPM-Versionen bis 8.3. JetRails wirbt mit 99,99 %
Verfügbarkeit (in den Snippets der eigenen Suchergebnisse), eine
Zahl, die die
[Nutzungsbedingungen](https://jetrails.com/terms-of-service/) nie
nennen: Die Bedingungen versprechen „wirtschaftlich angemessene
Bemühungen“, mit Gutschriften, die nach dem Recht von Illinois auf
zwei Wochen pro Monat gedeckelt sind. Die öffentlichen Preise
sind eine Spanne („Unsere üblichen Konfigurationen liegen
zwischen 100 und 2.500 USD pro Monat“ auf der
[Magento-Seite](https://jetrails.com/magento-hosting/)); für
genaue Angebote ist ein Konto erforderlich.
[Dedicated Servers](https://jetrails.com/dedicated-servers/)
werden als US-Rechenzentren angegeben, und keine Marketingseite
dokumentiert wählbare EU-Regionen (eine JetRails-Cloud-FAQ nennt
Multi-Region-Setups als unterstützt, ohne Regionen zu benennen),
weshalb der EU-Datenstandort vor Vertragsabschluss schriftlich
geklärt werden sollte. Die
[Statusseite](https://jetrails-status.com/) ist öffentlich.

**Nexcess**, einer der am längsten bestehenden Magento-Hosts,
verkauft nun über Liquid Web: Die
[Magento-Tarife](https://www.liquidweb.com/magento-hosting/)
laufen auf Nexcess-Infrastruktur, ab 74 USD pro Monat zum
Listenpreis für den kleinsten Tarif (zuerst wird der
Aktionspreis angezeigt), ausschließlich in USD. Jeder Tarif
umfasst Varnish, Redis und einen dedizierten OpenSearch-Container;
die Plattform bietet Staging, SSH und Git. Die Lücke liegt darin,
wie aktuell der Stack ist und wie klar das angegeben wird: Die
[Referenzseite](https://www.liquidweb.com/magento/latest-magento-version/)
des Anbieters selbst bezeichnete bei unserer Prüfung noch 2.4.8
als aktuellste Magento-Version, die einzig erreichbare
[Dokumentationsseite](https://docs.nexcess.com/hosting/control-panel/whm/php-management/using-the-cloudlinux-php-selector-in-cpanel-and-whm/),
die PHP-Versionen auflistet (für die cPanel-Linie), endet bei
8.3, und für die Magento-Tarife selbst wurde keine Angabe zu PHP,
OpenSearch oder Valkey gefunden. Die Marketingseite wirbt mit
„99,99 % garantierter Verfügbarkeit“, während die
[SLA-Seite](https://www.liquidweb.com/policies/sla/) keine solche
Zahl enthält. Der Nexcess-Bereich, auf den die Infrastruktur der
Tarife verweist (bei Vertragsabschluss prüfen, welche Regelung
gilt), verspricht 100 % unterbrechungsfreie Übertragung, mit
Gutschriften von 5 % der Monatsgebühr für je 15 Minuten
nachgewiesenen Ausfalls über die ersten 15 Minuten eines Monats
hinaus, gedeckelt auf eine Monatsgebühr, Ansprüche innerhalb von
sieben Tagen, verifiziert anhand der eigenen Protokolle des
Anbieters. Die Präsenz auf dem EU-Festland beschränkt sich auf
einen Standort, Amsterdam, laut
[Statusseite](https://status.nexcess.net/). Fast zwei Jahrzehnte
Magento-Geschichte und der Markenwechsel seit der Fusion mit
Liquid Web sind auf den Seiten deutlich sichtbar.

**Cloudways** (Teil von DigitalOcean) ist die günstige
Managed-Option, für die sich kleinere Shops entscheiden, und die
überprüfbaren Fakten mahnen zur Vorsicht. Der Anbieter verwaltet
den Server, und sein
[Support-Umfang](https://www.cloudways.com/en/support.php)
schließt die Anwendung aus: Debugging von eigenem Code,
Sicherheit auf Anwendungsebene und Modul-Upgrades sind nicht
enthalten. Das
[Changelog](https://www.cloudways.com/en/changelog.php) nennt
Juli 2025 für die Unterstützung von Magento 2.4.8 und
September 2025 für PHP 8.4, und listet verfügbare
Suchmaschinenversionen, die bei OpenSearch 2.19 enden, während
Adobes geprüfte Kombinationen für 2.4.8-p5 und 2.4.9 nur
OpenSearch 3 nennen. Ein Infrastruktur-SLA gibt es überhaupt
nicht; das einzige veröffentlichte SLA deckt die Support-Konsole
ab und besagt ausdrücklich, dass es nicht für die Verfügbarkeit
der Cloud-Anbieter gilt
([Support-SLA](https://www.cloudways.com/en/support-sla.php)).
Der Rechenzentrumsstandort wird beim jeweiligen zugrunde liegenden
Anbieter gewählt; die
[Magento-Hosting-Seite](https://www.cloudways.com/en/magento-hosting.php)
nennt Amsterdam, Frankfurt und London unter den
DigitalOcean-Standorten.
[Die Preise](https://www.cloudways.com/en/pricing.php) sind
veröffentlicht und tatsächlich niedrig, ab 11 USD pro Monat bei
DigitalOcean. Für einen Shop, der auf einen Server passt, und ein
Team, das Magento selbst betreut, kann das auf der aktuell
genutzten Versionslinie funktionieren; solange Cloudways
OpenSearch 3 nicht anbietet, verlässt ein Upgrade auf 2.4.8-p5
oder 2.4.9 Adobes geprüfte Kombinationen. Die Spezialisierung
reicht nicht über die Bereitstellung hinaus.

## Die tschechischen und polnischen Optionen

**vshosting~** (Prag, laut
[Über-uns-Seite](https://vshosting.eu/about) Teil der
Contabo-Gruppe) ist nach eigener Aussage der meistgenutzte
Anbieter für Managed-Infrastruktur im tschechischen und
slowakischen E-Commerce; diese Selbstbeschreibung
([auf der eigenen Website](https://vshosting.cz/blog/vshosting-nejvetsi-e-commerce-infrastructure-provider))
und die Kundenlisten sind Angaben des Anbieters, ohne dass wir
eine unabhängige Messung finden konnten. Dokumentiert ist: eine
[veröffentlichte Magento-Referenz](https://vshosting.eu/references/takoy)
für Takoy („eine auf Magento zugeschnittene Hosting-Lösung“), das
eigene Prager Rechenzentrum sowie lokale deutsche
Rechenzentren, die genutzt werden, und
[Preise für Managed Server](https://vshosting.eu/services/managed-servers)
ab 217 EUR pro Server und Monat, wobei im Kleingedruckten steht,
dass die Einstiegspreise zehn oder mehr Server bei 36-monatiger
Vertragslaufzeit voraussetzen; „Administrator-Reaktion innerhalb
von 60 Sekunden“ per Telefon und 24/7-Monitoring sind die
Formulierungen des Anbieters. Keine Magento-Paketpreise pro Tarif
sind veröffentlicht, und die von uns geprüften Seiten nennen
weder eine SLA-Prozentzahl noch Stack-Versionen.

**Centuria** (Poznań) ist der klarste polnische
Managed-Magento-Spezialist, den wir gefunden haben: eine eigene
[Magento-Hosting-Seite](https://centuria.pl/en/magento-hosting/)
mit 24/7-Service-Desk, benannten Rechenzentren (Equinix
Frankfurt, Beyond und Talex in Poznań) und Referenzen von
Castorama und dem Shop von CD PROJEKT RED (vom Anbieter
veröffentlicht). Der angegebene Stack nennt Varnish, Redis und
Elasticsearch; Elasticsearch 8 liegt noch innerhalb von Adobes
geprüften Kombinationen für 2.4.8-p5, Redis nicht, weshalb die
Komponentenliste der Seite eine direkte Nachfrage wert ist. Die
Preise sind nur Richtwerte: laufende Wartung ab rund 1.500 bis
2.000 PLN pro Monat, laut eigener Seite.

Die Recherche hat auch geklärt, welche Anbieter auszuschließen
sind. WEDOS, dessen Hosting inzwischen unter dem Namen VEDOS
firmiert, antwortete 2019 in seiner
[Wissensdatenbank](https://help.wedos.cz/otazka/hosting-magento-2/2697/),
dass für Magento ein VPS empfohlen werde und der Betrieb auf dem
eigenen Webhosting problematisch sei; neuere Magento-Hinweise
fanden wir dort nicht. Websupport
[dokumentiert](https://www.websupport.sk/podpora/kb/instalacia-cms-magento-cez-webovu-konzolu/)
lediglich, dass Magento trotz Einschränkungen auf Shared Hosting
installiert werden kann, und weder bei Forpsi, Master Internet
noch bei cyber_Folks fand sich eine Seite zu Magento-Hosting.
Einen in der Slowakei ansässigen Managed-Magento-Spezialisten
fanden wir überhaupt nicht; slowakische Shops dieser Stufe kaufen
bei den hier genannten tschechischen, polnischen, deutschen oder
internationalen Anbietern. Die polnische
[Magento-Seite](https://www.ovhcloud.com/pl/web-hosting/magento-hosting/)
von OVHcloud existiert, empfiehlt aber selbstverwaltete VPS oder
dedizierte Server, womit sie zu den selbstverwalteten Optionen
zählt.

## Selbstverwaltet: AWS und Hetzner

Magento direkt auf Cloud-Infrastruktur zu betreiben ist eine echte
Option mit einem einfachen Preis: Das eigene Team wird zum
Managed Host. Bei **AWS** bilden die Managed Services einen Teil
des Stacks ab (Aurora für die Datenbank, OpenSearch Service,
ElastiCache, Amazon MQ), und Adobes Anforderungstabelle enthält
AWS-spezifische Zeilen für genau diese, dazu S3; Adobes
ElastiCache-Zeile nennt „ElastiCache 7.1 for Redis OSS
(enhanced). Valkey 8 is available.“ als geprüfte Kombination, und
CloudFront deckt das CDN außerhalb der Tabelle ab. Varnish,
PHP-FPM, Cron und die Queue-Worker bleiben auf EC2, das Sie selbst
verwalten, und eine Multi-AZ-Konfiguration bringt eigene
Magento-spezifische Aufgaben mit sich: gemeinsamen Medienspeicher,
gemeinsame Sessions und Cache, Datenbank-Failover und eine
einzige verantwortliche Instanz für Cron und die Consumer. Was
AWS nicht bietet, ist ein produktionsreifer, herstellereigener Weg zu
Magento: Das 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)
trägt den Hinweis „This whitepaper is for historical reference
only“, das verlinkte
[Terraform-Modul](https://github.com/aws-ia/terraform-adobe-magento)
ist als Beta gekennzeichnet und nicht für den Produktiveinsatz
empfohlen (letzter Commit August 2025), die ursprüngliche
Magento-Quick-Start-Seite existiert nicht mehr, und das
[Referenz-Architektur-Repository](https://github.com/amazon-archives/aws-refarch-magento)
wurde seit April 2018 nicht mehr angefasst und liegt archiviert
vor. SLAs gelten pro Dienst und ausschließlich als Gutschrift:
99,99 % für EC2 setzen eine Multi-AZ-Bereitstellung voraus, eine
Einzelinstanz kommt auf 99,5 %
([Compute-SLA](https://aws.amazon.com/compute/sla/)). Acht
[europäische Regionen](https://docs.aws.amazon.com/general/latest/gr/rande.html)
stehen zur Verfügung, sechs davon in EU-Mitgliedstaaten,
darunter Frankfurt. Die Kosten verteilen sich auf viele
Einzelposten; wir nennen keine Gesamtsummen, weil eine
realistische Summe die Modellierung des eigenen Traffics
erfordert.

**Hetzner** ist der günstigste Vergleichsmaßstab in der EU und dokumentiert so gut wie
nichts zu Magento: keine Produktseite, keine One-Click-App, keine
Versionsmatrix. Am ehesten vergleichbar sind ein
[von der Community verfasstes Tutorial](https://community.hetzner.com/tutorials/install-magento-on-managed-server/)
(auf Deutsch) für die Managed-Server-Linie und die
[Dokumentationsseite](https://docs.hetzner.com/konsoleh/account-management/managed-server-tutorials/magento/),
die darauf verweist; das Tutorial dokumentiert den Aufwand selbst,
ein selbst installiertes OpenSearch, das einen vom Support
freigegebenen Java-Prozess braucht, ohne dokumentiertes RabbitMQ.
Auf der Managed-Server-Linie bleibt Magento ein selbst
installierter Notbehelf ohne Produktsupport dahinter. Was Hetzner
verkauft, ist leistungsfähige, preiswerte Infrastruktur, aber sonst
nichts: Cloud-Instanzen ab 5,99 EUR pro Monat mit
einer IPv4-Adresse für 2 vCPU und 4 GB
([Cloud-Seite](https://www.hetzner.com/cloud/); Preise werden
clientseitig gerendert), dedizierte Server darüber hinaus,
EU-Rechenzentren in Deutschland und Finnland (Standorte in den
USA und Singapur gibt es ebenfalls), kostenloser
[DDoS-Schutz auf Netzwerkebene](https://www.hetzner.com/unternehmen/ddos-schutz/)
und ein Cloud-SLA mit „wirtschaftlich angemessenen Bemühungen, um
eine monatliche Verfügbarkeit von 99,9 % sicherzustellen“, mit
Gutschriften, die in Cloud Credits ausgezahlt werden, gedeckelt
auf die Monatsrechnung des jeweiligen Servers und innerhalb von
14 Tagen geltend zu machen
([Cloud-Bedingungen](https://www.hetzner.com/legal/cloud-server/)).
Bei Hetzner liegen der gesamte Magento-Stack und die
Rufbereitschaft bei Ihnen selbst. Ein Shop auf einem der oben
genannten Managed-Tarife, ab 129 EUR pro Monat bei Hypernode oder
149 EUR bei MGT-Commerce, bezahlt teilweise für die
Betriebsarbeit, die dieser Abschnitt beschreibt.

## Im Vergleich

| Option | Modell | Verfügbarkeit im SLA | Aktueller Stack, laut Angabe | EU-Standorte | Öffentliche Preise |
| ------ | ----- | ----------------- | ------------------------ | ------------ | -------------- |
| Adobe Cloud (PaaS) | First-Party-PaaS | 99,99 % (SLA-Zusatz) | First-Party | AWS/Azure, vom Kunden gewählt | Nein |
| Hypernode | Managed | Kein SLA-Dokument; 99,9–99,95 % laut Dokumentation | PHP 8.5, OpenSearch 3.3, Valkey 8 | BE; DE über AWS-Linie | Ja |
| maxcluster | Managed | 99,99 % im Jahresmittel | PHP 8.5 (Roadmap), Valkey ohne Version | DE | Ja (PDF) |
| MGT-Commerce | Gebühr + eigenes AWS | 99,95 %, keine Gutschriftregelung | PHP bis 8.4 angegeben | AWS-Regionen, nicht festgelegt | Gebühren ja, AWS verbrauchsabhängig |
| JetRails | Managed auf AWS | Keine Prozentzahl in den Bedingungen | OpenSearch 3.2; PHP-FPM bis 8.3 in Support-Doku | Nicht dokumentiert | Nur Spanne |
| Nexcess (Liquid Web) | Managed | 100 % Transit, 5 % Gutschrift je 15 Min. | Nicht angegeben; cPanel-Doku reicht bis PHP 8.3 | Amsterdam | Ja (USD) |
| Cloudways | Serververwaltet | Nur Support-SLA | PHP 8.4; OpenSearch 2.19 | Über gewählte IaaS | Ja |
| vshosting~ | Managed | Nicht gefunden | Nicht veröffentlicht | CZ, DE | Einstiegspreise |
| Centuria | Managed | Nicht gefunden | Nennt Redis, Elasticsearch | PL, DE | Richtwert |
| AWS (selbstverwaltet) | IaaS | Pro Dienst | Ihre Aufgabe | 6 EU-Regionen | Verbrauchsabhängig |
| Hetzner (selbstverwaltet) | IaaS | 99,9 % auf Bemühensbasis | Ihre Aufgabe | DE, FI | Ja |

„Nicht gefunden“, „nicht angegeben“, „nicht veröffentlicht“ und
„nicht dokumentiert“ bezeichnen jeweils unsere eigene Recherche
auf den verlinkten Seiten; „Ihre Aufgabe“ bedeutet, dass der
Händler den Stack installiert und überwacht. „Aktueller Stack“
vergleicht die veröffentlichten Komponentenversionen jedes
Anbieters mit Adobes Tabellen für 2.4.8-p5/2.4.9 (PHP 8.3–8.5 je
nach Versionslinie, OpenSearch 3 oder, nur bei 2.4.8-p5,
Elasticsearch 8, Valkey). Alle Angaben mit Stand
3. August 2026.

## Die Wahl zwischen den Stufen

Beginnen Sie bei der Lizenz. Magento-Open-Source- und
Mage-OS-Shops können Adobes Cloud nicht kaufen, für sie besteht
die Wahl zwischen einem spezialisierten Managed-Anbieter und
eigener Infrastruktur. Eine Adobe-Commerce-Lizenz öffnet alle
drei Stufen: Die First-Party-Cloud mit ihrem SLA und ihrer
2027er-Richtlinie zum verpflichtenden Upgrade ist eine weitere
Option neben den spezialisierten Anbietern, von denen mehrere
ebenfalls Adobe Commerce hosten.

Zwischen einem spezialisierten Anbieter und der eigenen Cloud
entscheidet vor allem das eigene Team. Ein Managed-Spezialist
lohnt sich, wenn niemand im Team OpenSearch-Versionen im Blick
behalten oder Rufbereitschaft übernehmen sollte; der Vergleich
oben verengt sich dann auf die Frage, wer aktuell ist, wer sein
SLA schriftlich fixiert und wer das eigene Rechenzentrum
dokumentiert. Nach den veröffentlichten Belegen ist Hypernode bei den
Plattformanforderungen am aktuellsten, maxcluster und JetRails sind
bei Teilen des Stacks aktuell und machen zum Rest keine Angaben; maxcluster
dokumentiert deutsche Rechenzentren und vshosting den eigenen
Prager Standort, während die Daten bei MGT-Commerce in der AWS-Region
liegen, die Sie für Ihren Shop wählen. Selbstverwaltetes AWS oder Hetzner ist die bessere Wahl,
wenn bereits ein fähiges Team vorhanden ist und der Shop entweder Skaleneffekte oder eine Topologie
braucht, die kein Tarif bietet; es kostet dauerhaft einen Teil der
Aufmerksamkeit des Teams, und diese Kosten stehen auf keiner
Rechnung.

Wie der Vergleich auch ausfällt: Ein Umzug ist ein eigenes Projekt
mit eigenen Kosten: Medien im Umfang des Katalogs
synchronisieren, die Suche auf dem neuen Stack neu indizieren,
Cron- und Queue-Zustand übernehmen, Umstellung von TLS und DNS,
und ein Sperrfenster, das die Verkaufsspitze aussparen muss.
Planen Sie die Migration ein, bevor Sie Tarifpreise vergleichen;
ein günstigerer Tarif plus Migration kann teurer kommen als die
Verlängerung beim bisherigen Anbieter.

Speziell für den tschechischen, slowakischen und polnischen Markt
liegen die lokalen Managed-Anbieter bei Sprache und Datenstandort
vorn, veröffentlichen aber weniger: keine festen Magento-Tarife,
Richt- oder bedingte Preise, keine SLA-Prozentzahlen auf den von
uns geprüften Seiten und keine Stack-Versionen zum Vergleich.
Verlangen Sie SLA, Preis, Vertragslaufzeit und Kündigungsfrist
schriftlich; ein Rabatt, der an eine 36-monatige Laufzeit
gebunden ist, wie bei vshostings Einstiegspreisen, ist Teil des
Preises. Unter den internationalen Anbietern veröffentlichen
maxcluster und Nexcess vertragliche SLA-Bedingungen zusammen mit
ihren Preisen, und die meisten veröffentlichen zumindest Preise;
einen lokalen Anbieter können Sie bitten, dasselbe schriftlich
zuzusichern.

Hosting ist eine der drei Säulen, die unser
[DevOps-Service](/de/services/devops/) abdeckt, und
dieselbe Beurteilung läuft in unserer
[Magento-Arbeit](/de/services/magento/) mit: welche Stufe passt,
ob der aktuelle Host noch Adobes Anforderungstabelle entspricht,
und was die Migration kosten würde, falls nicht. Wer auch immer
Sie hostet, diese Tabelle im Blick zu behalten, ist eine Aufgabe,
die jemand übernehmen muss.