Shopware lässt sich auf vier Wegen betreiben: SaaS, PaaS, Self-Hosted oder vollständig Headless mit eigener Backend-Architektur. Bei PaaS denken viele zuerst an das eine Angebot, das Shopware selbst vermarktet. Das ist aber nur einer von zwei Wegen. Den anderen sieht man seltener in der Diskussion, obwohl er für manche Setups besser passt: eine Cloud-PaaS direkt nutzen und Shopware dort selbst betreiben. Wir erklären beide Wege ehrlich. Wo dein Setup hingehört, ist eine Frage für ein Gespräch, nicht für einen Blog-Artikel.
Inhalt
- Was ist Shopware PaaS?
- Der Shopware-eigene Weg
- Der Cloud-PaaS-Weg
- Was unterscheidet die beiden in der Praxis?
- Updates: Auch in PaaS Sache des Betreibers
- Wo wir stehen
Was ist Shopware PaaS?
PaaS heißt: Du bekommst eine fertige Plattform. Deployment-Workflows, Stages, Caching, Skalierung, Monitoring sind eingerichtet. Du musst nicht selbst Server konfigurieren, MySQL tunen oder Load-Balancer aufsetzen. Was du behältst: vollen Zugriff auf den Code, deine Plugins, deine Custom-Logik. Das ist der Unterschied zu SaaS. Dort wäre der Code zu.
Für Shopware ist PaaS der Mittelweg zwischen "alles selbst aufsetzen" (Self-Hosted) und "alles abgeben" (SaaS). Die spannende Frage ist nicht ob PaaS, sondern welche PaaS. Es gibt zwei klar getrennte Wege.
Der Shopware-eigene Weg
Das ist das offizielle Angebot von Shopware. Du buchst PaaS direkt bei Shopware. Die Plattform wird auf einer kuratierten Infrastruktur betrieben, im Hintergrund unter anderem auf Platform.sh. Was du bekommst:
- Vorkonfigurierte Stages (Development, Staging, Production) mit Git-basierten Deployments
- Automatisches Caching, Asset-Pipelines, CDN für Medien
- Skalierungs-Mechanismen ohne eigenes Kubernetes-Setup
- Integration mit dem Shopware-Account und dem Store
- Konsistenz mit der Shopware-Empfehlung: Was Shopware testet, läuft dort
Was das gut macht: Du landest schnell auf einem produktionsreifen Setup, ohne tiefes DevOps-Wissen aufbauen zu müssen. Viele typische Probleme (Deployment-Fehler, Cache-Inkonsistenzen, Stage-Drift) sind durch die Plattform schon adressiert.
Was du dabei in Kauf nimmst: Du bewegst dich im Rahmen der Shopware-PaaS-Architektur. Tiefe Integration in einen eigenen Cloud-Stack braucht Brücken über APIs.
Der Cloud-PaaS-Weg
Hier nutzt du eine Cloud-PaaS direkt. Entweder einen spezialisierten Anbieter wie Platform.sh, Heroku, Render oder Fly.io. Oder die PaaS-Layer eines Hyperscalers (AWS Elastic Beanstalk, Google Cloud Run, Azure App Service). Shopware betreibst du dort selbst. Optional übernimmt eine Agentur oder ein Hosting-Partner die Plattform-Operations.
Was das ermöglicht:
- Volle Kontrolle über Region, Provider, Skalierungsstrategie
- Tiefe Integration in einen bestehenden Cloud-Stack (Datenbanken, Messaging, Analytics)
- Multi-Cloud-Setups, wenn die IT-Strategie das vorgibt
- Eigene Deployment-Pipelines mit eigenen Tools (GitHub Actions, GitLab CI, ArgoCD)
Was du dabei in Kauf nimmst: Plattform-Setup, Hardening, Monitoring, Updates liegen bei dir oder deinem Partner. Mehr Hebel, mehr Verantwortung.
Was unterscheidet die beiden in der Praxis?
Drei Punkte, die wir bei der Einschätzung anschauen:
DevOps-Tiefe im Team. Wer wenig oder gar kein eigenes DevOps macht, ist beim Shopware-eigenen Weg meist gut aufgehoben. Wer eigene Pipelines und Infra-Verantwortung will, hat beim Cloud-PaaS-Weg mehr Spielraum.
Position von Shopware in deiner IT-Landschaft. Ist Shopware das System? Dann passt der Shopware-eigene Weg. Ist Shopware ein Baustein neben Daten-Pipelines, ML-Services, eigenen Microservices? Dann ist der Cloud-PaaS-Weg meist die kohärentere Wahl.
Tempo vs. Tiefe. Schnell live mit Standardprozessen versus eigene Pipeline mit tieferer Anpassung. Beides hat seinen Platz.
Pauschale Empfehlungen geben wir an dieser Stelle bewusst nicht. Welcher Weg zu deinem Setup passt, hängt an Faktoren, die ein Artikel nicht kennt: dein Team, deine bestehende Cloud-Landschaft, dein Zeitplan, dein Vertragsmodell mit Shopware.
Updates: Auch in PaaS Sache des Betreibers
Eine Klarstellung, die oft fehlt: Beide PaaS-Wege sind selbst-update-pflichtig. Die Plattform automatisiert Deployment und Infrastruktur, aber Shopware-Updates spielst du immer aktiv ein. Automatische Updates gibt es nur in der SaaS-Variante.
Heißt: Auch wenn du PaaS bei Shopware buchst, brauchst du jemanden, der Update-Releases verfolgt, im Staging testet und nach Produktion durchpflegt. Mehr dazu im Shopware Update-Guide.
Wo wir stehen
Damit du weißt, von wem du das hier liest: Wir bei dasistweb sind PaaS-ready und betreiben aktuell einen Kunden auf Shopware PaaS. Unser Schwerpunkt liegt sonst auf Self-Hosted-Setups bei spezialisierten Hostern wie Scale Commerce. Wir empfehlen PaaS nicht aus dem Bauch heraus, weil "alle das jetzt machen". Wir informieren dich, und wir sortieren das gemeinsam.
Im Erstgespräch klären wir typischerweise drei Dinge:
- In welche Liga deines Setups wir reinkommen (Standard, Datenanbindungen, Custom)
- Ob du eher PaaS-Typ oder Self-Hosted-Typ bist (Team, Cloud-Strategie, Tempo-Anforderung)
- Welche Vor- und Nachteile der jeweilige Weg in deinem konkreten Fall hat
Manchmal ist die ehrliche Antwort: PaaS ist für euch der einfachere Weg. Manchmal: Self-Hosted bleibt günstiger und flexibler. Manchmal: SaaS reicht euch. Wir sagen das offen, auch wenn das heißt, dass wir nicht der richtige Partner sind.
Verwandte Artikel
- Shopware Kosten: Wo PaaS in die Drei-Ligen-Logik passt
- Shopware Hosting: Self-Hosted-Alternative bei spezialisierten Hostern
- Shopware Cloud vs Self-Hosted: Der breitere Vergleich
- Shopware Update-Strategie: Update-Logik in PaaS und Self-Hosting