Magento Hosting Vergleich

Hier findest du keine „Testsieger“ und keine Rangliste. Ich zeige dir, worauf es für Magento 2 technisch ankommt, welche Optionen sich in typischen Shop-Szenarien bewähren und wie du Kosten realistisch planst. Die eigentliche Auswahl der Tarife passiert im Listing mit Filtern – dort grenzt du nach Ressourcen, Support und Features ein.

Für wen ist was geeignet? (3 Szenarien)

Neustart kleiner Shop (≈ bis 50 Bestellungen/Tag)

Ein managed vServer oder eine kleine Cloud-VM mit garantiertem vCPU-Kontingent und 8–16 GB RAM reicht oft. Wichtig ist eine PHP-Version, die zu deiner Magento-Version passt, Redis für Sessions/FPC und OpenSearch als Suchdienst. Eine externe WAF/CDN schadet nicht – auch bei kleinem Traffic. Staging kann zunächst ressourcenschlank laufen.

So prüfst du das: php -v gegen deine Zielversion halten und die Magento-Release-Notes checken; für 2.4.7 ist PHP 8.2/8.3 freigegeben, 2.4.8 setzt PHP 8.3 voraus (auf Cloud ist auch PHP 8.4 verfügbar).

Wachsender Shop (≈ 50–500 Bestellungen/Tag)

Setze auf dediziertere Cloud-Ressourcen (mind. 4–8 vCPU, 16–32 GB RAM), OpenSearch 2.x/3 je nach Release-Linie, Redis 7.x, RabbitMQ für asynchrone Jobs/Queues und saubere Cron-/Worker-Prozesse. Plane Staging als echte Klonumgebung, Rollback via Snapshots und Monitoring (z. B. New Relic).

Achtung: I/O limitiert Shops oft früher als CPU. Achte auf NVMe-Storage, genügend RAM pro PHP-Worker und ein Cache-Setup mit OPcache + Redis FPC und optional Varnish.

Etablierter Shop / Peak-Traffic (> 500/Tag)

Trenne Rollen: Web/PHP, Datenbank, OpenSearch, Queues. Nutze Zero-Downtime-Deployments und ein sauberes Blue/Green-Cutover. Plane WAF/CDN, RUM/APM-Monitoring, Log-Retention und klar definierte Restore-Pfade. Auf Cloud-Infrastruktur lässt sich Downtime durch passende Deploy-Strategien praktisch eliminieren.

Technische Anforderungen

Stand 16. 09. 2025. Prüfe immer die für deine Minor-Version gültigen Anforderungen.

PHP:
Magento 2.4.7 unterstützt PHP 8.2/8.3; Magento 2.4.8 erfordert 8.3 (auf Commerce Cloud zusätzlich 8.4 gelistet).

OpenSearch:
2.4.7: OpenSearch 2.x; 2.4.8 (Cloud): OpenSearch 3. Konfiguration als externer Dienst empfohlen.

Datenbank:
On-prem: MySQL 8.0 ist Standard; ab 2.4.8 besteht Support für MySQL 8.4 LTS. Alternativ MariaDB 10.6/10.11 (2.4.7) bzw. 11.4 LTS (2.4.8 Cloud). Achte auf utf8mb4-Collation.

Redis/Valkey:
Redis 7.x ist die gängige Zielversion; 2.4.7 listet 7.2, 2.4.8 (Cloud) nennt Valkey 8 als Alternative.

RabbitMQ (Queues):
Für Bulk/Async-Jobs üblich; 2.4.7/2.4.8 nennen RabbitMQ 3.13–4.1 je Patch-Stand.

Composer:
Je nach Release-Linie 2.7–2.8; prüfe die Tabelle zu deinem Patch-Level.

So prüfst du das:
Versionsmatrix gegen System Requirements und Release Notes halten; Suche/Engine in der Doku bestätigt sowohl OpenSearch als auch – je nach Deployment – Elasticsearch-Altpfade.

Performance in der Praxis

Ein Magento-Stack lebt von Caching, I/O-Durchsatz und stabilen Workern.

Cache-Stack: OPcache für PHP, Redis für Default/Session/FPC; Varnish als HTTP-FPC vor dem Origin ist im Shop-Alltag Standard. Adobe beschreibt Einrichtung und Tuning in der Doku, inkl. Redis-Separation nach Cache-Typ.

HTTP-Protokolle: HTTP/2 bringt Multiplexing-Vorteile und ersetzt oft JS-Bundling-Tricks; HTTP/3/QUIC lässt sich z. B. bei Fastly aktivieren.

Queues & Cron: Indexer, E-Mails, Imports und Asynchrones gehören in Cron/Worker bzw. RabbitMQ. Plane Consumers und deren Überwachung explizit ein.

So prüfst du das:
Antworte mit curl -I und lies age, x-served-by, via, x-cache-Header (Varnish/CDN); kontrolliere alt-svc (HTTP/3); redis-cli info gegen die Instanzen; bin/magento queue:consumers:list für Worker-Sicht.

Achtung: „Mehr CPU“ heilt keine langsamen Queries oder fehlkonfigurierten Cache. Miss zuerst, dann skalieren – nicht umgekehrt.

Sicherheit & Compliance

Hoster-seitig: DDoS-Basis, WAF/CDN, Panel-2FA und belastbare Backup-Policies (Aufbewahrung, Restore-Kosten) reduzieren Risikooberfläche. Fastly/Cloud-WAF und Commerce-Cloud-Leitfäden decken das ab.

Shop-seitig: Halte Patch-Kadenz, aktiviere Admin-2FA, beschränke Rechte („Least Privilege“) und manage Secrets sauber. Adobe priorisiert genau diese Basics in den Security-Best-Practices.

PCI-DSS 4.0: Nimmst du Kartendaten selbst an, gilt PCI-DSS 4.x. Die Version 4.0.1 präzisiert Anforderungen, ohne neue Controls einzuführen; neue Controls werden ab 31. März 2025 wirksam. Viele Shops reduzieren den Scope, indem sie gehostete Zahlseiten nutzen.

So prüfst du das:
Admin-2FA im Backend aktivieren und erzwungen testen; für PCI die verantwortlichen Datenflüsse dokumentieren und gegen den 12-Punkte-Katalog mappen.

Achtung: Backups sind erst dann „sicher“, wenn Restore-Zeit & -Kosten geklärt sind.

Kosten & TCO

Annahmen: ca. 200 000 Seitenaufrufe/Monat, 150 Bestellungen/Tag, 50 GB Shop-Daten, 30 Tage Backup-Retention. Ziel: stabiles, skalierbares Setup ohne Overkill. (Preise sind grobe Marktpreise, exkl. MwSt; reale Kosten schwanken je Anbieter.)

Migration & Betrieb

Staging/Preview: Arbeite mit vollwertigem Staging (DB-Kopie, identische Dienste). Snapshots dienen als Rückfallebene vor jedem Release.

Zero-Downtime-Deploy: Auf Commerce-Cloud lässt sich Deploy-Downtime durch verschobene Static-Content-Phasen und Verbindungspuffer minimieren; Ziel ist ein Zero-Downtime-Effekt.

Rollback: Nutze Snapshots/Backups mit klarer Wiederherstellungsanleitung; definiere, wann ein Rollback statt Hotfix greift.

So prüfst du das:
Vor Produktiv-Merge: Snapshot erstellen, Deploy-Haken/Worker prüfen, Live-Cutover in Staging durchspielen, Monitoring-Baseline setzen.

Aktuelle Sicherheits-Info

9. September 2025: Adobe meldet kritische Lücken in Adobe Commerce/Magento Open Source (Security Bulletin APSB25-88). Installiere die bereitgestellten Sicherheits-Patches zeitnah und plane einen Regressionstest.