Magento Cloud vs. Self Hosted: die Entscheidungshilfe

1. Warum die Betriebsmodell-Frage heute schwieriger ist

Die Entscheidung Magento Cloud vs. Self Hosted war früher relativ einfach: Wer sich Adobe Commerce leisten konnte, bekam die Cloud-Infrastruktur automatisch dazu, alle anderen betrieben ihre Instanz selbst. 2026 ist das Bild differenzierter. Managed-Hosting-Anbieter für Magento Open Source haben aufgeholt, Kubernetes-basierte Self-Hosted-Setups sind reifer geworden, und Adobe hat die Cloud-Konditionen für kleinere Shops angepasst. Die Frage Magento Cloud vs. Self Hosted lässt sich deshalb nicht mehr pauschal beantworten, sondern erfordert eine strukturierte Bewertung des eigenen Betriebskontexts.

Besonders relevant wird diese Entscheidung bei Vertragsverlängerungen, internationalen Rollouts oder wenn ein Team aus einer Agentur-Betreuung in den eigenen Betrieb wechseln will. In jedem dieser Fälle wiegt die Wahl zwischen Magento Cloud und Self Hosted Infrastrukturkosten gegen Kontrolle, Skalierungsgeschwindigkeit gegen Konfigurationsfreiheit und Betriebssicherheit gegen Abhängigkeit vom Anbieter ab. Die folgenden Abschnitte liefern die Kriterien, mit denen sich diese Abwägung nachvollziehbar dokumentieren lässt, statt sie einer einzelnen Person als Bauchentscheidung zu überlassen.

2. Die drei Betriebsmodelle im Überblick

In der Praxis lassen sich für Magento drei grundsätzliche Betriebsmodelle unterscheiden. Erstens die verwaltete Magento Cloud-Infrastruktur von Adobe, die Staging-, Integration- und Produktions-Umgebungen inklusive Fastly-CDN und einer vorgegebenen Git-Deployment-Pipeline bereitstellt. Zweitens Self Hosted im engeren Sinne: eine Instanz, die vollständig auf eigener oder gemieteter Infrastruktur läuft, meist mit Docker- oder Kubernetes-Orchestrierung und eigenverantwortlicher CI/CD-Pipeline. Drittens eine Zwischenform, bei der eine spezialisierte Agentur oder ein Managed-Hosting-Anbieter die Infrastrukturverantwortung übernimmt, ohne dass Adobe direkt involviert ist.

Diese dritte Variante wird häufig unterschätzt, obwohl sie für viele mittelgroße Shops den besten Kompromiss darstellt: Man behält die Flexibilität von Self Hosted bei Serverkonfiguration und Kostenstruktur, überträgt aber Patching, Monitoring und Notfall-Reaktion an einen spezialisierten Partner. Wer die Frage Magento Cloud vs. Self Hosted stellt, sollte diese dritte Option nicht vorschnell ausklammern, denn sie verschiebt die Entscheidung von einem binären Entweder-Oder zu einer Frage nach dem passenden Grad an Eigenverantwortung.

# .magento.app.yaml: Auszug einer typischen Adobe Commerce Cloud Konfiguration
name: app
type: 'php:8.3'
build:
  flavor: none
dependencies:
  php:
    composer/composer: '^2'
disk: 5120
mounts:
  'var': { source: local, source_path: var }
  'pub/media': { source: local, source_path: media }
  'pub/static': { source: local, source_path: static }
hooks:
  build: |
    set -e
    php ./vendor/bin/ece-tools run scenario/build/generate.xml
  deploy: |
    set -e
    php ./vendor/bin/ece-tools run scenario/deploy.xml

3. Total Cost of Ownership korrekt berechnen

Der Kostenvergleich zwischen Magento Cloud und Self Hosted wird oft auf die reine Infrastrukturrechnung reduziert, was systematisch zu falschen Schlüssen führt. Ein realistischer TCO-Vergleich muss vier Kostenblöcke einbeziehen: die reine Hosting-Rechnung (Cloud-Plan versus Server-Miete), die Personalkosten für DevOps-Betrieb (bei Self Hosted deutlich höher), die Lizenzkosten der gewählten Magento Edition und die Kosten für ungeplante Ausfallzeiten, die je nach Betriebsmodell unterschiedlich wahrscheinlich sind.

Bei Magento Cloud ist die Hosting-Rechnung meist höher als bei einem vergleichbaren Self Hosted-Setup auf reiner Server-Basis, dafür entfällt ein erheblicher Teil der DevOps-Personalkosten, weil Skalierung, Patching der Infrastruktur-Ebene und Backup-Management vom Anbieter übernommen werden. Bei Self Hosted kippt dieses Verhältnis: niedrigere Infrastrukturkosten, aber ein bis zwei zusätzliche DevOps-Vollzeitstellen oder ein entsprechendes Agenturbudget, das über die Projektlaufzeit eingerechnet werden muss. Wer nur die Serverrechnung vergleicht, unterschätzt bei Self Hosted systematisch die tatsächlichen Betriebskosten.

#!/usr/bin/env bash
# tco-vergleich.sh: grobe TCO-Gegenueberstellung als Entscheidungsgrundlage
set -euo pipefail

# Cloud-Betrieb (Beispielwerte pro Monat, in Euro)
CLOUD_HOSTING=3500
CLOUD_DEVOPS_ANTEIL=800      # geringer, da Infrastruktur verwaltet wird
CLOUD_LIZENZ=0                # bereits in Cloud-Vertrag enthalten

# Self Hosted Betrieb (Beispielwerte pro Monat, in Euro)
SELF_HOSTING=1400
SELF_DEVOPS_ANTEIL=6500       # 1-2 DevOps-Teilzeitstellen oder Agentur
SELF_LIZENZ=0                 # Open Source, keine Lizenzgebuehr

cloud_total=$((CLOUD_HOSTING + CLOUD_DEVOPS_ANTEIL + CLOUD_LIZENZ))
self_total=$((SELF_HOSTING + SELF_DEVOPS_ANTEIL + SELF_LIZENZ))

echo "Magento Cloud TCO/Monat:   ${cloud_total} EUR"
echo "Self Hosted TCO/Monat:     ${self_total} EUR"
echo "Differenz:                 $((self_total - cloud_total)) EUR"

4. Skalierung und Traffic-Spitzen

Bei Traffic-Spitzen, etwa durch saisonale Sales-Events, zeigt sich der wohl deutlichste praktische Unterschied zwischen Magento Cloud und Self Hosted. Die verwaltete Cloud-Infrastruktur skaliert innerhalb definierter Grenzen automatisch und nutzt Fastly als Edge-Cache-Schicht, die einen Großteil der Lastspitze abfängt, bevor sie überhaupt die Applikationsserver erreicht. Bei Self Hosted muss diese Skalierungslogik selbst konfiguriert werden, etwa über horizontale Pod-Autoscaling-Regeln in Kubernetes oder durch manuelles Vorhalten zusätzlicher Kapazität vor bekannten Spitzenereignissen.

Der Vorteil von Self Hosted liegt hier in der vollständigen Kontrolle über die Skalierungsstrategie: Ein Team mit ausreichender Kubernetes-Erfahrung kann eigene Autoscaling-Regeln definieren, die exakt auf das Traffic-Muster des eigenen Shops zugeschnitten sind, statt sich auf die generischen Grenzen eines Cloud-Plans zu verlassen. Wer allerdings kein etabliertes Kapazitätsplanungsverfahren hat, geht bei Self Hosted ein reales Risiko ein: Eine unterschätzte Spitze kann zum vollständigen Ausfall führen, während die Magento Cloud-Infrastruktur zumindest innerhalb der vertraglich vereinbarten Grenzen automatisch reagiert.

5. Deployment-Pipeline und Entwickler-Workflow

Magento Cloud gibt eine feste Deployment-Pipeline vor, die auf Git-Branches basiert: Ein Push auf einen bestimmten Branch löst automatisch Build und Deploy in der zugeordneten Umgebung aus, gesteuert über ece-tools. Diese Struktur reduziert die initiale Einrichtungszeit erheblich, schränkt aber auch ein, wie stark das Deployment an projektspezifische Anforderungen angepasst werden kann. Bei Self Hosted entwirft das Team die komplette Pipeline selbst, meist mit GitLab CI oder GitHub Actions, was mehr Aufwand beim initialen Aufbau bedeutet, aber volle Kontrolle über Build-Schritte, Testintegration und Rollback-Verhalten gibt.

Für Teams mit bereits etablierten CI/CD-Standards aus anderen Projekten ist Self Hosted oft die konsistentere Wahl, weil sich Magento in bestehende Pipeline-Muster einfügen lässt, statt eine Sonderlösung nur für dieses eine Projekt zu pflegen. Teams ohne diese Vorerfahrung profitieren dagegen von der vorgegebenen Struktur der Magento Cloud-Pipeline, die zwar weniger flexibel ist, dafür aber von Anfang an nach bewährten Praktiken funktioniert, ohne dass ein eigenes Pipeline-Design entworfen werden muss.

#!/usr/bin/env bash
# Self-Hosted CI-Pipeline Ausschnitt (GitLab CI Runner-Skript)
set -euo pipefail

echo "[BUILD] Composer install und Static Content Deploy"
composer install --no-dev --optimize-autoloader
bin/magento setup:di:compile
bin/magento setup:static-content:deploy de_DE en_US -f

echo "[TEST] Statische Tests vor Deployment"
vendor/bin/phpcs --standard=Magento2 app/code
vendor/bin/phpstan analyse app/code --level=5

echo "[DEPLOY] Blue-Green Switch nach erfolgreichem Health-Check"
kubectl rollout status deployment/magento-app --timeout=300s

6. Sicherheit, Patching und Compliance

Bei Magento Cloud übernimmt Adobe das Patching der Infrastruktur-Ebene, also Betriebssystem, Webserver und Datenbankmotor, während die Verantwortung für Applikations-Patches (Magento-Sicherheitsupdates, Composer-Abhängigkeiten) weiterhin beim Betreiberteam liegt. Diese geteilte Verantwortung reduziert die Angriffsfläche auf der Infrastrukturseite erheblich, weil Adobe bekannte Schwachstellen typischerweise schneller schließt als ein einzelnes internes Team es leisten könnte. Bei Self Hosted liegt die vollständige Patch-Verantwortung beim eigenen Team, von der Kernel-Version bis zur PHP-Runtime.

Für Unternehmen mit strengen Compliance-Anforderungen, etwa im Finanz- oder Gesundheitssektor, kann Self Hosted allerdings auch Vorteile bieten: Die vollständige Kontrolle über den Serverstandort, die Datenverschlüsselung und die Audit-Protokollierung lässt sich exakt auf regulatorische Vorgaben zuschneiden, ohne von den Standardkonfigurationen eines Cloud-Anbieters abhängig zu sein. Wer beispielsweise strenge Datenresidenz-Anforderungen für einen bestimmten Mitgliedsstaat hat, sollte prüfen, ob die verfügbaren Magento Cloud-Regionen diese Anforderung erfüllen, bevor die Entscheidung fällt.

# Patch-Verantwortung pruefen: welche Ebene liegt bei wem
bin/magento setup:db:status                 # Applikationsseitig, immer eigene Verantwortung
composer audit                              # Composer-Abhaengigkeiten auf bekannte CVEs pruefen

# Bei Self Hosted zusaetzlich: Infrastruktur-Patches selbst tracken
apt list --upgradable 2>/dev/null | grep -i security
docker image ls --format '{{.Repository}}:{{.Tag}}' | xargs -I{} trivy image {}

7. Monitoring, Incident-Response und Ausfallzeiten

Beim Monitoring liefert Magento Cloud ein integriertes New-Relic-Dashboard sowie Zugriff auf zentrale Logs über die Cloud-CLI, was für viele Teams ausreicht, ohne eigene Observability-Infrastruktur aufbauen zu müssen. Für tiefere Einblicke, etwa detailliertes Application Performance Monitoring auf Query-Ebene oder Custom-Metriken aus eigenen Modulen, stößt die integrierte Lösung aber an Grenzen. Bei Self Hosted kann ein Team ein beliebiges Monitoring-Stack aus Prometheus, Grafana und eigenen Alerting-Regeln aufbauen, das exakt auf die eigenen Betriebsanforderungen zugeschnitten ist.

Bei Incidents zeigt sich der größte praktische Unterschied: Magento Cloud-Kunden mit entsprechendem SLA können den Adobe-Support direkt einschalten, der auf die Infrastruktur-Ebene zugreifen kann, ohne dass das eigene Team involviert sein muss. Bei Self Hosted liegt die komplette Incident-Response beim eigenen Team oder einem beauftragten Dienstleister, was potenziell längere Reaktionszeiten bedeutet, aber auch keine Wartezeit auf einen externen Support-Ticket-Prozess erfordert. Wer eine Rufbereitschaft mit garantierten Reaktionszeiten intern nicht abbilden kann, sollte diesen Punkt bei der Wahl zwischen Magento Cloud und Self Hosted besonders hoch gewichten.

8. Vendor-Lock-in und Exit-Strategie

Ein oft übersehener Faktor ist der Vendor-Lock-in, der mit Magento Cloud einhergeht. Die vorgegebene Deployment-Pipeline über ece-tools, die spezifischen Umgebungsvariablen und die enge Fastly-Integration erschweren einen späteren Wechsel zu einer anderen Infrastruktur, sollte sich die Entscheidung ändern. Ein solcher Exit erfordert typischerweise, die Deployment-Konfiguration komplett neu aufzubauen und die Caching-Strategie durch eine gleichwertige Varnish-Lösung zu ersetzen, was mehrere Wochen Migrationsaufwand bedeuten kann.

Self Hosted-Setups sind von Natur aus portabler, weil sie nicht an eine proprietäre Deployment-Pipeline gebunden sind. Ein Wechsel des Hosting-Anbieters oder der Cloud-Region lässt sich in der Regel ohne grundlegende Architekturänderungen umsetzen, solange die Infrastruktur containerisiert und deklarativ beschrieben ist. Für Unternehmen, die Wert auf maximale Unabhängigkeit vom Infrastruktur-Anbieter legen, ist dieser Portabilitätsvorteil von Self Hosted gegenüber Magento Cloud oft ein entscheidendes strategisches Argument, unabhängig von den reinen Kostenzahlen.

9. Betriebsmodelle im direkten Vergleich

Die folgende Tabelle verdichtet die wichtigsten Unterschiede zwischen Magento Cloud und Self Hosted auf einen Blick, als Ausgangspunkt für die eigene Entscheidungsdokumentation.

Keine Zeile dieser Tabelle sollte isoliert über die Gesamtentscheidung bestimmen. Erst die Gewichtung nach dem eigenen Kontext, etwa vorhandenem DevOps-Team, Traffic-Volatilität und regulatorischen Anforderungen, ergibt eine belastbare Antwort auf die Frage Magento Cloud vs. Self Hosted.

10. Zusammenfassung

Die Entscheidung Magento Cloud vs. Self Hosted ist keine Frage von Trends, sondern von Zahlen und Ressourcen. Magento Cloud reduziert DevOps-Aufwand, liefert automatische Skalierung über Fastly und ein vertragliches Support-SLA, verlangt dafür höhere Hosting-Kosten und akzeptiert einen spürbaren Vendor-Lock-in. Self Hosted bietet volle Konfigurationsfreiheit und geringeren Lock-in, verlangt dafür signifikant mehr internes DevOps-Know-how und Verantwortung für Patching, Skalierung und Incident-Response.

Eine belastbare Wahl entsteht, wenn Total Cost of Ownership über mehrere Jahre, Traffic-Volatilität, vorhandene DevOps-Ressourcen und regulatorische Anforderungen gemeinsam bewertet werden, statt sich auf die reine Hosting-Rechnung zu verlassen. Wer diese vier Dimensionen dokumentiert, trifft eine Entscheidung zwischen Magento Cloud und Self Hosted, die auch bei wachsendem Traffic und veränderten Anforderungen tragfähig bleibt.

11. FAQ: Magento Cloud vs. Self Hosted