Shopware Cloud wird fast überall als Preisfrage behandelt: Was kostet die Cloud, was kostet self-hosted, welche Variante ist günstiger? Diese Frage ist bei Shopware allerdings bereits beantwortet — und zwar von Shopware selbst. Auf der offiziellen Preisseite steht wörtlich: „Shopware SaaS ist zum gleichen Preis erhältlich wie self-hosted.”
Damit fällt das übliche Vergleichskriterium weg, und die eigentliche Frage tritt hervor: Shopware Cloud vs. self-hosted ist eine Architekturentscheidung, keine Kostenentscheidung. Du entscheidest nicht, wie viel du zahlst. Du entscheidest, welchen Zugriff du auf dein eigenes System behältst — und welche Erweiterungen du dann überhaupt noch installieren kannst.
Genau dieser zweite Punkt ist der, über den fast niemand mit Zahlen spricht. Also haben wir ihn gemessen, statt ihn zu beschreiben:
- Den Erweiterungs-Store durchgezählt. Wie viele der Extensions im offiziellen Shopware Store laufen tatsächlich in der Cloud? Und — viel wichtiger — wie viele der meistgekauften?
- Das App-System gegen das Plugin-System gestellt. Beide Erweiterungsarten sind im Quellcode definiert. Ihre Grenzen lassen sich nachzählen, statt sie zu behaupten.
- Die Preisaussagen an der Quelle geholt, nicht aus Sekundärartikeln.
Alle Zahlen in diesem Artikel wurden am 13. August 2026 direkt erhoben — im Shopware Store, auf shopware.com und im geklonten Core-Repository (Commit-Stand 13.08.2026, Version 6.7.13.0). Wo wir uns beim Messen selbst korrigieren mussten, steht das im Text. Das gehört zur Methode, nicht ins Archiv.
Shopware Cloud: Was ist das überhaupt?
„Shopware Cloud” ist kein einzelnes Produkt, sondern ein Sammelbegriff für zwei Betriebsmodelle, die Shopware selbst hostet:
- Shopware SaaS — Software as a Service. Shopware betreibt die Infrastruktur, spielt Updates automatisch ein, kümmert sich um Skalierung und Wartung. Du bekommst einen fertigen Shop und arbeitest in der Administration.
- Shopware PaaS — Platform as a Service. Ebenfalls von Shopware gehostet, aber mit Deployment-Pipeline, Umgebungen, CI/CD und eigenem Code. Laut Shopware „alle Vorteile von SaaS, plus maximale Anpassungsfähigkeit, Performance-Monitoring und Entwickler-Tools”.
Dem gegenüber steht self-hosted (oft „on-premise” genannt): Du installierst Shopware auf deinem eigenen Server oder bei einem Hoster deiner Wahl. Shopware beschreibt das selbst als die richtige Lösung, „wenn du ein erfahrenes Entwicklerteam an deiner Seite hast und die volle Kontrolle über die von dir gewählte IT-Infrastruktur benötigst”.
Der entscheidende Satz für die ganze Entscheidung steht allerdings woanders auf derselben Seite — bei der Community Edition:
„Sie ist nicht in der Shopware Cloud verfügbar – Setup und Wartung liegen damit in deiner Verantwortung.”
Die kostenlose Community Edition gibt es in der Cloud nicht. Wer „Shopware Cloud” sagt, redet zwangsläufig über einen kostenpflichtigen Plan. Das ist die erste harte Grenze, und sie wird in Vergleichen regelmäßig übersehen, weil „Shopware ist Open Source und kostenlos” als Satz für sich genommen stimmt — nur eben nicht für die Cloud.
Die Preisfrage ist schneller beantwortet, als du denkst
Shopwares Pläne heißen Community (kostenlos), Rise (ab 600 €/Monat), Evolve (ab 2.400 €/Monat) und Beyond (individuell), alle Preise netto, Stand 13.08.2026 von der deutschen Preisseite. Die Preisbildung erfolgt laut Shopware „nach dem Gross Merchandise Value (GMV) sowie anderen Individualfaktoren” — das heißt: Der genannte Preis ist eine Untergrenze, dein tatsächlicher Preis hängt an deinem Bruttowarenwert.
Und eben: Der Plan kostet in der Cloud dasselbe wie self-hosted. Der Unterschied liegt woanders — beim Self-Hosting kommen Serverkosten, Updates und Betriebsaufwand obendrauf, in der Cloud sind sie im Plan enthalten. Wir haben die vollständige Kostenaufstellung inklusive TCO-Rechnungen in einem eigenen Artikel behandelt: Was kostet Shopware 6? — dort stehen Hosting, Agentur, Plugins und die versteckten Posten im Detail. Hier geht es um das, was der Preis nicht verrät.
Ein Detail am Rande, das mehr über die Zielgruppen sagt als jede Feature-Tabelle: Einen Rise-Plan kannst du direkt im Shopware Account buchen — aber laut Fußnote nur für self-hosted Shops. Für SaaS und PaaS musst du den Vertrieb kontaktieren. Der Self-Service-Weg führt also ausgerechnet in das Modell, das mehr Eigenverantwortung verlangt.
Die Zahl, die alles entscheidet: 13,2 %
Jetzt zum Kern. In der Cloud kannst du nicht jede Erweiterung installieren — das ist bekannt. Unbekannt ist meist, wie groß die Einschränkung tatsächlich ist. Also haben wir gezählt.
Der offizielle Shopware Store bietet einen Filter „Cloud Compatible”. Wir haben ihn angewendet und alle Ergebnisseiten durchpaginiert:
| Messung | Anzahl | Anteil |
|---|---|---|
| Extensions im Store gesamt | 3.402 | 100 % |
| davon Cloud-kompatibel | 448 | 13,2 % |
| davon nicht Cloud-kompatibel | 2.954 | 86,8 % |
Knapp sieben von acht Erweiterungen im offiziellen Store laufen nicht in der Shopware Cloud. Das ist keine Randnotiz, das ist die Entscheidung.
Und jetzt die Zahl, die wirklich weh tut
13,2 % klingt nach einer Einschränkung, mit der man leben kann — schließlich sind 448 Erweiterungen absolut gesehen viel. Der Haken: Nicht jede Erweiterung ist gleich wichtig. Entscheidend ist, ob die Extensions verfügbar sind, die die meisten Shops tatsächlich einsetzen.
Also haben wir dieselbe Prüfung auf die Bestsellerliste angewendet — die 144 meistgekauften Erweiterungen des Stores, sortiert nach Topseller-Ranking:
| Segment | Cloud-kompatibel | Anteil |
|---|---|---|
| Gesamter Store (3.402) | 448 | 13,2 % |
| Top 144 Bestseller | 12 | 8,3 % |
| Top 48 Bestseller | 3 | 6,3 % |
| Top 24 Bestseller | 3 | 12,5 % |
Je beliebter eine Erweiterung, desto unwahrscheinlicher läuft sie in der Cloud. In den Top 48 des Stores sind es drei Stück. Drei.
Ein Blick auf die Namen macht deutlich, worum es geht. Unter den nicht cloud-fähigen Bestsellern stehen unter anderem:
- PayPal for Shopware 6 (shopware AG)
- Shopware 6 Security Plugin (shopware AG)
- Shopware Migration Assistant (shopware AG)
- Shopware Language Pack (shopware AG)
- Custom JavaScript/CSS Manager, Custom Template Manager (PremSoft)
- SEO Redirect (301 / 302) (scope01)
- Amazon Pay
Das Bemerkenswerte daran: Mehrere dieser Erweiterungen stammen von Shopware selbst. Die Cloud-Beschränkung ist also keine Nachlässigkeit von Drittanbietern, die „noch nicht portiert” haben — sie ist strukturell. Warum das so ist, klärt der nächste Abschnitt.
⚠️ Wie wir uns bei dieser Zahl fast selbst belogen hätten
Unser erster Ansatz war naheliegend: Der Store zeigt auf jeder Produktkarte Badges an, darunter ein Cloud-Symbol. Wir haben also in der Bestsellerliste die Karten mit Cloud-Badge gezählt — Ergebnis: 9 von 144 = 6,2 %. Eine schöne, dramatische Zahl.
Sie war falsch. Der Gegencheck über die Mengenlehre (alle 448 Einträge des Cloud-Filters gegen die 144 Bestseller abgeglichen) ergab 12. Drei Erweiterungen von MILLENWORLD tauchten im Cloud-Filter auf, trugen in der ungefilterten Bestsellerliste aber kein Badge — dieselben Produkte, dieselbe Website, mit gesetztem Filter erschien das Badge, ohne Filter fehlte es.
🔑 Die Lehre: Ein Anzeigeelement ist kein Datenfeld. Das Badge wird gerendert, wenn der Kontext es hergibt — es ist keine verlässliche Eigenschaft des Produkts. Beide Zahlen sahen plausibel aus, beide stammten von derselben Quelle, und nur eine war belastbar. Wir nennen deshalb im Artikel durchgehend die höhere, konservativere Zahl (8,3 %), obwohl die niedrigere unsere These stärker gestützt hätte.
Ein zweiter Fehler derselben Familie: Beim Paginieren zählten wir zunächst 592 Cloud-Badges auf 448 Karten — unmöglich. Ursache: Der Store liefert bei zu hoher Seitenzahl stillschweigend die letzte gültige Seite aus, statt eine leere Seite oder einen Fehler zu melden. Doppelt gezählte Karten. Erst die Deduplizierung über Name + Hersteller ergab die saubere 448. Eine Paginierung, die nie leer wird, kann man nicht zum Abbruchkriterium machen.
Wer die 448 Cloud-Erweiterungen eigentlich baut
Auch das Cloud-Set selbst lohnt einen zweiten Blick, denn 448 Erweiterungen klingen nach einem lebendigen Ökosystem:
| Merkmal des Cloud-Sets | Wert |
|---|---|
| Erweiterungen gesamt | 448 |
| davon kostenlos | 62 (13,8 %) |
| davon kostenpflichtig | 386 (86,2 %) |
| Anbieter gesamt | 116 |
| Anteil des größten Anbieters | 7,1 % (32 Erweiterungen) |
| Anteil der Top-5-Anbieter | 24,6 % (110 Erweiterungen) |
Ein Viertel des Cloud-Angebots stammt von fünf Anbietern. Das ist keine Katastrophe, aber es relativiert die 448: Die Auswahl ist schmaler, als die absolute Zahl vermuten lässt, und konzentrierter auf wenige Häuser.
Warum das so ist: App statt Plugin
Die Erweiterungsgrenze in der Cloud ist keine Willkür, sondern folgt direkt aus der Architektur. Shopware kennt zwei Arten von Erweiterungen, und nur eine davon ist cloud-tauglich.
Plugins sind PHP-Code, der im Shopware-Prozess läuft. Sie werden in die Anwendung geladen, dürfen Services austauschen, Templates überschreiben, eigene Datenbanktabellen anlegen und praktisch jeden Punkt des Systems verändern.
Apps laufen außerhalb von Shopware. Sie kommunizieren ausschließlich über HTTP. Shopwares eigene Dokumentation formuliert das erfreulich klar:
„Fully cloud compatible: By decoupling Shopware and your app, your app is automatically compatible with multi-tenant cloud systems.”
Und genau darin liegt der Preis: Eine App ist cloud-fähig, weil sie nicht in den Kern hineinreicht. In einer Multi-Tenant-Cloud teilen sich viele Shops eine Plattform — fremder PHP-Code im Kern wäre dort ein Sicherheits- und Stabilitätsrisiko für alle anderen Mandanten. Die Beschränkung ist die Bedingung dafür, dass das Modell überhaupt funktioniert.
Der Unterschied, nachgezählt im Quellcode
Beide Erweiterungsarten sind im Shopware-Core definiert. Statt „Apps können weniger” zu behaupten, lässt sich das zählen. Wir haben das Repository geklont (Stand 13.08.2026, 6.7.13.0) und die Angriffsfläche beider Systeme gemessen:
| Erweiterungspunkt | App (Cloud-fähig) | Plugin (nur self-hosted) |
|---|---|---|
| Definitionsort | manifest.xml (XSD-Schema) | PHP-Klasse im Shopware-Prozess |
| Verfügbare Schema-Elemente | 58 (gesamtes Manifest) | — (nicht schemabegrenzt) |
| Ausführbarer Code im Kern | nein (nur HTTP) | ja |
| App-Script-Hooks | 55 | alle davon plus alles andere |
| Auslösbare Webhook-Ereignisse | begrenzt (nur Hookable) | 389 Event-Klassen im Core |
| Twig-Blöcke der Storefront | über Theme-Mechanismus | 2.047 direkt überschreibbar |
| Storefront-Templates | über Theme-Mechanismus | 325 direkt überschreibbar |
| PHP-Klassen im Core dekorierbar | nein | 6.704 |
| Eigene Entitäten (DAL) | über Custom Entities | 193 Core-Entitäten erweiterbar |
| Rechte-Modell | read/create/update/delete/crud im Manifest | keine Schemagrenze |
git clone --depth 1 github.com/shopware/shopware, Commit-Stand 13.08.2026. Schema-Elemente aus src/Core/Framework/App/Manifest/Schema/manifest-3.0.xsd (eindeutige xs:element name=). App-Script-Hooks = konkrete, nicht-abstrakte Klassen, die von einer *Hook-Klasse erben, ohne Test-Artefakte. Event-Klassen = konkrete Klassen mit Suffix Event außerhalb von Test-Verzeichnissen. Twig-Blöcke = eindeutige {% block %}-Namen unter src/Storefront/Resources/views. PHP-Klassen = alle .php-Dateien außerhalb von Test-Verzeichnissen.
Die Zeile, die den Kern trifft: 58 Schema-Elemente gegen 6.704 dekorierbare Klassen. Eine App bewegt sich in einem klar umzäunten Feld, das Shopware definiert. Ein Plugin bewegt sich in Shopware.
Das ist ausdrücklich kein Argument gegen Apps. Das App-System ist technisch die sauberere Lösung: Es überlebt Updates besser, es kann in jeder Sprache geschrieben werden, es kann den Shop nicht zum Absturz bringen. Es beantwortet nur eine andere Frage — nämlich „Wie erweitere ich das System sicher?” statt „Wie ändere ich das System grundlegend?”.
Ein Nebenbefund aus dem Quellcode
Beim Durchsuchen des Cores nach einem Cloud-Schalter kam eine Fehlanzeige heraus, die selbst eine Aussage ist: Es gibt im Core keine SaaS- oder Cloud-Umgebungsvariable, die Funktionen abschaltet. Die Suche nach entsprechenden Konstanten oder Env-Flags in src/Core blieb leer.
Das bestätigt, was Shopware auch offen kommuniziert: Cloud und self-hosted laufen auf derselben Codebasis. Die Cloud ist kein abgespecktes Shopware. Der Unterschied entsteht nicht durch abgeschaltete Features, sondern dadurch, wer Zugriff auf die Ausführungsumgebung hat. Du bekommst dasselbe Programm — nur ohne den Schlüssel zum Maschinenraum.
Was du in der Cloud konkret aufgibst
Aus der Architektur folgen die praktischen Grenzen. Der Reihe nach, ohne Dramatisierung:
1. Kein Root-Zugriff, keine Konsole. Du kannst dich nicht auf den Server einloggen. Kein bin/console, kein direkter Datenbankzugriff, kein Blick in die Logs auf Dateiebene. Wer in der Praxis schon einmal einen Shopware-Fehler über ein Konsolenkommando eingegrenzt hat, weiß, was hier fehlt.
2. Keine eigenen PHP-Plugins. Der große Punkt aus dem Abschnitt oben. Individuelle Anforderungen, die ein Plugin bräuchten — eine exotische ERP-Anbindung, eine spezielle Preislogik, eine tiefe Änderung im Checkout — sind in der SaaS-Variante nicht umsetzbar.
3. Kein Einfluss auf den Update-Zeitpunkt. Automatische Updates sind ein Verkaufsargument und ein Risiko zugleich. Sie nehmen dir Arbeit ab — und sie nehmen dir die Möglichkeit, ein Update erst auf einem Staging-System zu testen und dann bewusst einzuspielen.
4. Kein Zugriff auf die Infrastruktur. Kein eigenes Caching-Setup, keine eigene Elasticsearch-Konfiguration, keine Wahl des Rechenzentrums, kein eigener Cronjob.
5. Keine Community Edition. Wie oben belegt: Der Einstieg in die Cloud ist immer kostenpflichtig.
Und im Gegenzug bekommst du:
1. Keine Serververantwortung. Kein Patchday, kein Kernel-Update, keine Nacht, in der du erklärst, warum der Shop nicht erreichbar ist. Das ist mehr wert, als es klingt — wir haben einen echten Sicherheitsvorfall auf eigener Infrastruktur dokumentiert, der fünf Tage unentdeckt blieb. In einer SaaS-Umgebung wäre diese spezifische Angriffsfläche nicht unsere gewesen.
2. Keine Update-Schuld. Der häufigste Zustand alter Self-hosted-Shops ist nicht „kaputt”, sondern „drei Minor-Versionen hinterher, weil das Update-Fenster nie kam”. In der Cloud kann dieser Zustand nicht entstehen.
3. Vorhersagbare Kosten. Ein Plan statt Server plus Wartungsvertrag plus Notfallstunden.
4. Ein kleineres Sicherheitsproblem. Weniger eigener Code ist weniger eigene Angriffsfläche. Wer sich dafür interessiert, wo Lücken in der Praxis wirklich herkommen: Wir haben das in IT-Sicherheitslücken mit eigenen Messungen aufgeschrieben — der größte Einfallsvektor sind Abhängigkeiten, nicht spektakuläre Zero-Days.
Der Migrationspfad — und warum er nicht symmetrisch ist
Eine Frage, die vor der Entscheidung stehen sollte statt danach: Komme ich wieder raus?
Die gute Nachricht: Weil Cloud und self-hosted dieselbe Codebasis nutzen, sind deine Daten nicht in einem Fremdformat gefangen. Produkte, Kunden, Bestellungen, Kategorien liegen im Shopware-Datenmodell — dem gleichen, das eine Self-hosted-Installation verwendet. Das ist ein struktureller Vorteil gegenüber geschlossenen SaaS-Systemen, bei denen du am Ende nur einen CSV-Export bekommst.
Die unbequeme Nachricht: Der Weg ist trotzdem nicht in beide Richtungen gleich leicht.
- Self-hosted → Cloud ist der schwierigere Weg. Jedes Plugin, das du in den Jahren angesammelt hast, muss ein Cloud-fähiges Gegenstück haben — und die Wahrscheinlichkeit dafür liegt nach unserer Zählung bei 13,2 %, bei den beliebten Erweiterungen sogar darunter. Individualentwicklung muss als App neu gebaut werden.
- Cloud → self-hosted ist der leichtere Weg, weil du nur Dinge mitnimmst, die im engeren Rahmen der Cloud entstanden sind. Alles, was dort lief, läuft auch self-hosted — die Menge der Möglichkeiten wird größer, nicht kleiner.
Daraus folgt eine praktische Empfehlung, die man selten liest: Im Zweifel in der Cloud anfangen. Nicht weil sie besser ist, sondern weil der Ausstieg aus der Cloud der einfachere Richtungswechsel ist. Wer self-hosted startet und in drei Jahren feststellt, dass er die Serververantwortung nicht mehr tragen will, sitzt auf einem Plugin-Stack, der die Migration teuer macht.
Shopware PaaS: der übersehene dritte Weg
In der Diskussion „Cloud oder self-hosted” geht regelmäßig unter, dass Shopware ein Modell dazwischen anbietet. Shopware PaaS ist ebenfalls von Shopware gehostet, erlaubt aber eigenen Code, Deployment-Pipelines und Umgebungen.
Für viele Projekte ist das die eigentlich passende Antwort: Du gibst die Serververantwortung ab, behältst aber die Fähigkeit, tief einzugreifen. Zwei Einschränkungen, die man kennen sollte:
- Der Preis ist nicht veröffentlicht. Shopware schreibt: „Da Shopware PaaS auf deine spezifischen Bedürfnisse angepasst wird, bieten wir für PaaS eine individuelle Preisgestaltung an.” Anders als bei SaaS gibt es also keine Zusage, dass es dasselbe kostet wie self-hosted. Wir schreiben hier bewusst keine geschätzte Zahl hin — eine geschätzte Zahl sieht in einer Tabelle exakt aus wie eine gemessene.
- Es ist kein Selbstbedienungsprodukt. Wie bei SaaS führt der Weg über den Vertrieb, und die Dokumentation weist ein begleitetes Onboarding samt CI/CD-Einrichtung als kostenpflichtige Leistung nach Aufwand aus.
Wenn deine Anforderung lautet „ich brauche eigene Plugins, aber ich will keine Server betreiben”, dann ist PaaS die Kategorie, nach der du fragen solltest — nicht SaaS.
Die Entscheidung: konkrete Kriterien statt Bauchgefühl
Statt einer Pro-und-Contra-Liste ein Satz Fragen, die tatsächlich trennscharf sind. Jede davon lässt sich mit Ja oder Nein beantworten:
Nimm Shopware Cloud (SaaS), wenn:
- Du kein Entwicklerteam hast und auch keins beauftragen willst.
- Deine Anforderungen mit Standardfunktionen plus einer Handvoll Erweiterungen abgedeckt sind.
- Du vorher geprüft hast, dass deine konkret benötigten Erweiterungen im Cloud-Set enthalten sind — der Store-Filter beantwortet das in fünf Minuten.
- Automatische Updates für dich eine Erleichterung sind und kein Risiko.
- Du deine Zeit lieber in Sortiment und Marketing steckst als in Infrastruktur.
Bleib bei self-hosted, wenn:
- Du eigene Plugins brauchst oder bereits hast.
- Eine ERP-, PIM- oder Warenwirtschaftsanbindung existiert, für die es keine App gibt.
- Du Update-Zeitpunkte kontrollieren musst, weil dein Shop geschäftskritisch ist und ein ungeplantes Update inakzeptabel wäre.
- Du besondere Anforderungen an Hosting-Standort, Datenhaltung oder Infrastruktur hast.
- Du die Community Edition nutzen willst — die es in der Cloud nicht gibt.
Frag nach PaaS, wenn:
- Beide Listen oben teilweise auf dich zutreffen: eigener Code nötig, aber keine Lust auf Serverbetrieb.
Und der eine Test, der die Entscheidung praktisch vorwegnimmt: Schreib deine benötigten Erweiterungen auf und prüfe sie einzeln im Store-Filter. Wenn eine geschäftskritische darunter fehlt, ist die Frage beantwortet — unabhängig von allen anderen Argumenten.
Wie wir es selbst machen — und warum das nicht dein Maßstab sein sollte
Wir betreiben Shopware in Produktion self-hosted, unter anderem Pastaclean, und sind offizieller Shopware-Partner. Die Wahl fiel nicht aus Prinzipientreue, sondern weil die Anforderungen sie erzwingen: eigene Plugins für Produktdarstellung und Thumbnailing, Eingriffe in Templates, Anbindungen an bestehende Systeme. Nichts davon wäre in der SaaS-Variante möglich.
Das ist aber ausdrücklich kein Argument für dich. Unsere Konstellation — vorhandenes Entwickler-Know-how plus tiefe Individualanforderungen — ist genau die, für die self-hosted gebaut ist. Wer diese beiden Dinge nicht hat, kauft sich mit self-hosted vor allem eine Verantwortung ein, die er nicht braucht.
Ehrlich gesagt gehört auch die Gegenseite zur Bilanz: Self-Hosting bedeutet, dass Sicherheitslücken deine Lücken sind, dass Updates deine Aufgabe sind und dass Ausfälle in deiner Nacht passieren. Wir haben beides erlebt, und wir würden niemandem raten, sich das ohne Not aufzuhalsen.
Fazit: Die richtige Frage ist nicht „was kostet es”
Shopware Cloud vs. self-hosted wird als Kostenfrage gestellt und ist keine — Shopware sagt selbst, dass SaaS und self-hosted dasselbe kosten. Die echte Frage lautet: Wie viel Zugriff auf dein eigenes System brauchst du?
Die drei Zahlen, die du dir merken solltest:
- 13,2 % der 3.402 Store-Erweiterungen laufen in der Cloud.
- 8,3 % der 144 meistgekauften Erweiterungen laufen in der Cloud — je beliebter, desto unwahrscheinlicher.
- 58 Schema-Elemente stehen einer App zur Verfügung, gegenüber 6.704 dekorierbaren PHP-Klassen für ein Plugin.
Wer diese drei Zahlen kennt, trifft die Entscheidung in zehn Minuten statt in drei Meetings. Und wer unsicher ist, startet in der Cloud — weil der Weg heraus leichter ist als der Weg hinein.
Wenn du das Shopware-Ökosystem breiter einordnen willst, findest du die Nachbarthemen hier: Shopify vs. Shopware für den Systemvergleich mit TCO-Modell, Was kostet Shopware 6? für die vollständige Kostenaufstellung, Magento-Alternative für Umsteiger und Bestes Shopsystem für die Auswahl von Grund auf. Wenn du wissen willst, wie schnell dein Shop tatsächlich ist — egal in welchem Betriebsmodell —, kannst du das mit unserem Core-Web-Vitals-Test direkt messen.
FAQ: Häufige Fragen zu Shopware Cloud
Was ist Shopware Cloud?
Shopware Cloud ist der Sammelbegriff für die beiden von Shopware selbst gehosteten Betriebsmodelle: Shopware SaaS (vollständig verwaltet, automatische Updates, kein eigener Code) und Shopware PaaS (ebenfalls gehostet, aber mit Deployment-Pipeline und eigenem Code). In beiden Fällen betreibt Shopware die Infrastruktur, nicht du.
Was kostet Shopware Cloud?
Die Pläne kosten Rise ab 600 €/Monat, Evolve ab 2.400 €/Monat und Beyond individuell, jeweils netto (Stand 13.08.2026). Die Preisbildung erfolgt laut Shopware nach dem Gross Merchandise Value (GMV) und weiteren individuellen Faktoren — die genannten Beträge sind Untergrenzen. Wichtig: Shopware gibt an, dass SaaS denselben Preis kostet wie self-hosted; der Unterschied liegt darin, dass beim Self-Hosting zusätzlich Server- und Betriebskosten anfallen.
Ist die Shopware Community Edition in der Cloud verfügbar?
Nein. Shopware schreibt auf der eigenen Preisseite ausdrücklich, dass die Community Edition nicht in der Shopware Cloud verfügbar ist und Setup sowie Wartung damit in deiner Verantwortung liegen. Wer die Cloud nutzen will, braucht einen kostenpflichtigen Plan.
Kann ich in der Shopware Cloud eigene Plugins installieren?
Nein, in der SaaS-Variante nicht. Cloud-Umgebungen erlauben ausschließlich Apps — Erweiterungen, die außerhalb von Shopware laufen und nur über HTTP kommunizieren. Klassische PHP-Plugins, die im Shopware-Prozess ausgeführt werden, sind nicht installierbar. Wer eigenen Code braucht und trotzdem nicht selbst hosten will, sollte nach Shopware PaaS fragen.
Wie viele Shopware-Erweiterungen sind cloud-kompatibel?
Von den 3.402 Erweiterungen im offiziellen Shopware Store waren am 13.08.2026 genau 448 als cloud-kompatibel markiert — 13,2 %. Bei den 144 meistverkauften Erweiterungen liegt der Anteil mit 12 (8,3 %) noch niedriger. Unter den nicht cloud-fähigen Bestsellern befinden sich mehrere Erweiterungen von Shopware selbst, darunter das PayPal-Plugin, das Security-Plugin und der Migration Assistant.
Was ist der Unterschied zwischen einer App und einem Plugin?
Ein Plugin ist PHP-Code, der innerhalb von Shopware ausgeführt wird. Es kann Services austauschen, Templates überschreiben und praktisch jeden Teil des Systems verändern — im Core stehen dafür 6.704 PHP-Klassen und 2.047 Twig-Blöcke zur Verfügung. Eine App läuft außerhalb von Shopware und kommuniziert nur über HTTP; ihr Funktionsumfang ist durch das Manifest-Schema mit 58 Elementen und 55 App-Script-Hooks begrenzt. Apps sind dadurch cloud-fähig und update-sicher, Plugins sind mächtiger.
Kann ich von Shopware Cloud zu self-hosted wechseln?
Ja, und das ist die einfachere der beiden Richtungen. Cloud und self-hosted nutzen dieselbe Codebasis und dasselbe Datenmodell, deine Daten sind also nicht in einem Fremdformat gefangen. Beim Wechsel von der Cloud zu self-hosted wächst der Funktionsumfang, es fällt nichts weg. Umgekehrt — von self-hosted in die Cloud — muss jedes vorhandene Plugin ein cloud-fähiges Gegenstück haben, was der eigentliche Aufwandstreiber ist.
Ist Shopware Cloud sicherer als self-hosted?
In einem wichtigen Punkt ja: Serverbetrieb, Patches und Infrastruktursicherheit liegen bei Shopware, und weniger eigener Code bedeutet weniger eigene Angriffsfläche. Das ersetzt aber keine Sorgfalt — Zugangsdaten, Berechtigungen, Drittanbieter-Apps und der Umgang mit Kundendaten bleiben deine Verantwortung. Self-hosted kann genauso sicher sein, verlangt dafür aber ein Team, das Updates und Härtung tatsächlich durchführt.
Wie finde ich heraus, ob meine Erweiterungen in der Cloud laufen?
Im offiziellen Shopware Store gibt es einen Filter „Cloud Compatible”. Damit lässt sich in wenigen Minuten prüfen, ob die konkret benötigten Erweiterungen verfügbar sind. Wichtig: Verlasse dich auf das Filterergebnis, nicht auf das Cloud-Symbol in ungefilterten Listen — wir haben beim Messen festgestellt, dass dasselbe Produkt mit gesetztem Filter ein Cloud-Badge trug und ohne Filter nicht.
Welche Shopware-Variante ist die richtige für mich?
Als Faustregel: SaaS, wenn du kein Entwicklerteam hast und mit Standardfunktionen plus verfügbaren Apps auskommst. Self-hosted, wenn du eigene Plugins, tiefe Systemintegrationen oder Kontrolle über Update-Zeitpunkte brauchst. PaaS, wenn du eigenen Code benötigst, aber keine Server betreiben willst. Der schnellste Test ist immer derselbe: Liste deine unverzichtbaren Erweiterungen auf und prüfe sie einzeln im Cloud-Filter des Stores.