Wir beraten als Shopware Agentur Unternehmen täglich bei der Frage, welches Cloud-Modell zu ihren E-Commerce-Projekten passt. Seit Shopware PaaS als gleichwertige dritte Option neben Self-Hosted (SH) und SaaS positioniert ist, hat sich die Diskussion in unseren Beratungsgesprächen deutlich verschoben. Viele Shopware-Projekte, die früher reflexhaft auf Self-Hosted-Lösungen gesetzt haben, profitieren heute von der managed Cloud. Andere Shopware-Projekte sollten dagegen weiterhin auf der eigenen Cloud-Infrastruktur bleiben oder gleich auf SaaS umsteigen.
Wichtig zur Einordnung: Shopware PaaS Native befindet sich weiterhin in einem Beta-nahen Reifegrad. Funktionen werden laufend ergänzt, einzelne Bausteine sind aktuell noch nicht produktiv ausgereift. Wir kommunizieren das in der Beratung offen und unterscheiden in diesem Beitrag klar zwischen heute belastbaren Vorteilen und Punkten, an denen Shopware nachbessern muss.
In diesem Beitrag fassen wir aus konkreter Praxis zusammen, wann sich der Wechsel zu Shopware PaaS lohnt, wann er es nicht tut und welche Wissenslücken bei Entscheidern und Entwicklern im Vorfeld am häufigsten auftauchen.
Shopware PaaS ist ausdrücklich kein klassisches Hosting. Während ein Hosting-Anbieter Ihnen Server, Speicher und einige für Shopware optimierte Dienste zur Verfügung stellt, liefert die Shopware-Cloud ein managed Operating Model, das speziell auf Shopware-Projekte zugeschnitten ist. Sie behalten Ihre Customizings, Ihre Plugins und damit die gesamte Anwendung in eigener Hand. Shopware übernimmt im Gegenzug die DevOps-Arbeit, die Skalierung der Cloud, das Deployment und das Patching.
Die Cloud-Plattform läuft im Hintergrund auf AWS in der Region EU-Central. Dieser Punkt ist für Kunden mit Datensicherheits- oder Compliance-Anforderungen wichtig, weil Shopware in der Außenkommunikation ansonsten eine „Europe First"-Positionierung verfolgt.
Der konzeptionelle Unterschied zwischen generischem Hosting und Shopware PaaS ist groß. Hosting liefert Hardware. Shopware PaaS liefert ein Shopware-ready Operating Model, das aus folgenden Bausteinen besteht:
Wer den Begriff PaaS auf etwas teureres Hosting reduziert, übersieht den Hebel der Bündelung. Die Shopware-Cloud ist eine Kombination aus Cloud-Plattform, Deployment-Werkzeugen, Performance-Services und nativen Monitoring-Schnittstellen. Eine fundierte Übersicht über die Modell-Optionen direkt vom Hersteller liefert Shopware in seinem offiziellen Vergleich von SaaS, PaaS und Self-Hosted.
Shopware bietet heute drei Wege, einen Commerce-Shop zu betreiben.
Self-Hosted bedeutet, dass Sie oder ein Hosting-Partner die komplette Cloud bereitstellen, Patches einspielen und das Deployment selbst orchestrieren. Sie haben die maximale Kontrolle über Ihre Kundendaten und über jeden Server, tragen aber auch die volle DevOps-Verantwortung für Ihren Shopware-Shop. Bei Setups wie unserem über Maxcluster lassen sich PHP-Versionen, Speicherlimits, Datenbankschemata und Schnittstellen frei konfigurieren.
Shopware SaaS ist das Gegenteil. Sie bekommen einen einsatzbereiten Shopware-Shop ohne SSH-Zugang, ohne eigene Plugins per Code und ohne DevOps-Aufwand. Plugins aus dem klassischen Store sind in SaaS nicht möglich, nur Cloud-Apps. Für Standard-Shops mit geringem Customizing-Bedarf eignet sich SaaS gut, weil die Cloud-Plattform alle Wartungs- und Sicherheitsthemen abdeckt.
Shopware PaaS sitzt zwischen diesen beiden Extremen. Sie behalten den vollen Code-Zugriff, die Plugin-Hoheit (Apps und klassische Plugins) und die Möglichkeit, eigene Workflows zu definieren. Gleichzeitig betreibt Shopware die Cloud, sorgt für skalierbare Lastverteilung und liefert ein integriertes Monitoring.
Wichtig für eine ehrliche Einordnung: PaaS bringt auch Einschränkungen mit, die in unserer Beratung häufig unterschätzt werden. Konkret betrifft das:
Wir beschreiben PaaS unseren Kunden gern so: Sie behalten Ihre Anwendung, Sie geben die Cloud-Operations ab. Sie akzeptieren dafür, dass die Cloud stärker standardisiert ist als ein eigenes Setup über Maxcluster.
„PaaS ist kein besseres Hosting, sondern eine andere Arbeitsteilung: Sie behalten Ihre Anwendung, Shopware übernimmt den Betrieb."
Dr. Thomas Limberg
Geschäftsführer der AGIQON GmbH
Aus unserer Beratungspraxis lassen sich fünf Kriterien benennen, bei deren Vorliegen wir aktiv zu Shopware PaaS raten.
Das erste Kriterium ist die Existenz eines internen Entwicklerteams oder einer langfristig gebuchten Agentur. Wenn kontinuierlich an Ihrem Shopware-Shop weiterentwickelt wird, brauchen Ihre Entwickler strukturierte Workflows und ein klares Deployment-Schema. PaaS bringt diese Bausteine bereits mit. Vergleichbare Workflows haben wir in unseren Self-Hosted-Projekten über unsere eigenen CI/CD-Pipelines ebenfalls aufgebaut. Bei PaaS bekommen Sie das Setup als Teil des Angebots.
Das zweite Kriterium ist hoher Anpassungsbedarf in Kombination mit API-basierten Schnittstellen. Sobald Ihre Entwickler eigene Plugins entwickeln, individuelle Themes betreiben oder spezifische Schnittstellen zur Warenwirtschaft, zum PIM oder zum CRM bauen, ist SaaS zu eng. PaaS bietet hier mehr Flexibilität als SaaS, ohne die operative Last eines vollständigen Self-Hosted-Setups. Wichtig: PaaS funktioniert nur dann reibungslos, wenn die Schnittstellen API-basiert sind. Datei-basierte Schnittstellen sind in PaaS nicht abbildbar (mehr dazu im Abschnitt „Wann PaaS für Sie nicht passt").
Das dritte Kriterium sind professionelle Workflows. Shopware PaaS ist git-basiert. Jeder Push erzeugt einen neuen Build, und Branches lassen sich auf Vorschau-, Staging- und Produktions-Umgebungen abbilden. Wenn Sie heute manuell deployen, gewinnen Ihre Entwickler mit PaaS Zeit. Wenn Sie heute bereits über automatisierte CI/CD-Pipelines verfügen, etwa über GitLab in einem Maxcluster-Setup wie bei uns, liegt der Mehrwert eher in der mitgelieferten Standardisierung und nicht in einer dramatischen Geschwindigkeitssteigerung. Hier sollten Sie ehrlich prüfen, was Ihr Status quo ist.
Das vierte Kriterium ist die Frage der Cloud-Anbieter-Wahl. Shopware PaaS läuft heute auf AWS in der Region EU-Central. Wenn Ihnen die Cloud wichtig ist, das Bauen und Betreiben einer eigenen Cloud aber nicht zum Projekt werden soll, ist die managed Variante ein natürlicher Mittelweg. Beachten Sie aber, dass die Plattform technisch auf AWS aufsetzt. Für Kunden mit harten DSGVO- oder Datensouveränitätsanforderungen ist das ein Punkt, der früh geklärt werden muss.
Das fünfte Kriterium ist Performance und Observability. Wenn Ihre Entwickler schon zum Projektstart wissen, dass sie Lasttests, eine echte Fehleranalyse und feingranulare Logs brauchen, bietet die Shopware-Cloud mit Grafana, Loki und OpenTelemetry eine solide Basis. Einschränkend: Bei Maxcluster können wir das Performance-Tool und die Tiefe der Analyse frei wählen. In PaaS sind wir derzeit auf das von Shopware angebotene Bundle festgelegt, und Blackfire ist noch nicht verfügbar. Wie sehr ein einzelner solcher Baustein die Skalierbarkeit beeinflussen kann, beleuchten wir am Beispiel der Suche in unserem Beitrag Elasticsearch in Shopware 6: Skalierbare Suche in Echtzeit.
Genauso wichtig ist, dass Shopware PaaS nicht in jedem Szenario die beste Lösung ist. Wir raten in den folgenden Konstellationen davon ab.
Wenn Ihr Hauptziel echte Einfachheit ist, also wenig technische Beteiligung, schneller Time-to-Value und keine eigenen Workflows, dann ist Shopware SaaS die richtige Antwort. Sie nehmen damit bewusst Einschränkungen bei Plugins und Customizing in Kauf, sparen sich dafür jegliche DevOps-Diskussion. Für reine Standard-Commerce-Lösungen ohne tiefgreifenden Anpassungsbedarf ist SaaS oft die wirtschaftlich klügere Wahl.
Wenn die volle Hoheit über Ihre Kundendaten ein hartes Compliance- oder Sicherheitskriterium ist, etwa in regulierten Branchen oder bei spezifischen Auflagen Ihrer Konzernrichtlinien, führt der Weg zu Self-Hosted. Bei Self-Hosted-Setups können Sie genau festlegen, in welchem Rechenzentrum Ihre Kundendaten liegen und welche Hände sie berühren. Da Shopware PaaS auf AWS EU-Central aufsetzt, ist diese Hoheit dort nur eingeschränkt gegeben.
Viele Shopware-Projekte arbeiten mit Datei-Schnittstellen zur Warenwirtschaft, zum Beispiel mit einem Produktimport, der eine große XML-Datei auf dem Server ablegt, oder mit einem Bestellexport, der eine CSV-Datei erzeugt, die ein anderes System abholt. Diese Muster funktionieren in PaaS nicht out of the box, weil Sie keinen Dateisystem-Zugriff erhalten. Es sind ausschließlich API-basierte ERP-Anbindungen möglich. Vor einem Wechsel auf PaaS müssen solche Schnittstellen umgebaut werden.
Lange Importlaufzeiten über zehn Minuten, hoher Speicherbedarf jenseits der vorgegebenen 512 MB, eigene Datenbankschemata oder PHP-Versionen abseits des PaaS-Standards sind in PaaS nicht abbildbar. Auch Konstellationen mit parallelen Systemen auf derselben Domain, zum Beispiel WordPress neben Shopware, lassen sich in PaaS nicht realisieren.
Existierende Shopware-Shops lassen sich nicht über einen einfachen Backup-Restore in PaaS übernehmen. Daten, Datenbank und Medien müssen über den Shopware-Import-Export-Mechanismus oder über andere Wege übertragen werden. Wenn der bestehende Shop Datei-basierte Schnittstellen, SSH-abhängige Plugins oder eine alte PHP-Version nutzt, ist eine Migration nach PaaS in der Regel nicht der richtige Weg.
Die Cloud-Plattform ist request-basiert, die Konfiguration wird gemeinsam mit Shopware abgestimmt. Wer eine reine Klick-und-Buch-Beziehung sucht, fühlt sich hier eher unwohl.
Als zertifizierte Shopware-Partner beraten wir Sie unabhängig zur Wahl zwischen Shopware PaaS, SaaS und Self-Hosted. Wir begleiten Architektur-Validierung, PaaS-Migration und technische Umsetzung mit Praxis aus über 200 Shopware-Projekten.
Jetzt Projekt anfragenWir kommunizieren transparent: Shopware PaaS Native ist aus unserer Sicht aktuell noch nicht so ausgereift, wie der Marketingauftritt vermuten lässt. Im Sinne einer fairen Erwartungssteuerung benennen wir hier die Punkte, an denen wir in eigenen Projekten Reibung erlebt haben.
Wir empfehlen deshalb: PaaS gehört in Neukundengespräche, aber jedes konkrete Projekt sollte vor Vertragsabschluss eine technische Bewertung durchlaufen. Wenn der Shop zu komplex ist, ist Self-Hosted über Maxcluster der ehrlichere Weg.
Bei den Shopware-Projekten, die wir auf PaaS migriert haben, sehen wir wiederkehrende Effekte.
Eine neue Vorschau-Umgebung für einen Feature-Branch lässt sich nach einmaliger Einrichtung mit überschaubarem Aufwand zur Verfügung stellen. Wichtig: Diese Fähigkeit muss auch in PaaS zunächst eingerichtet werden, sie ist nicht ab Projektstart sofort verfügbar. Wenn der Workflow steht, können Entwickler parallel arbeiten, ohne sich gegenseitig zu blockieren.
Viele klassische DevOps-Aufgaben verschieben sich von Ihrem Team zur Cloud-Plattform. Konkret gilt das für:
Ergänzend: Auch Maxcluster skaliert automatisch und übernimmt einen Großteil dieser Themen. Der Unterschied liegt eher im Service-Modell und im Vertragsverhältnis als in einer technisch eindeutigen Überlegenheit der PaaS-Cloud.
In der Shopware-Cloud arbeiten wir mit einem einheitlichen Stack aus Logs, Metriken und Traces über offene Standards. Das vereinfacht Fehleranalysen in vielen Fällen. Einschränkend: Wir mussten in einzelnen Projekten zusätzliche Hilfsmittel bauen, um an Informationen zu kommen, die in einem Maxcluster-Setup direkt verfügbar sind.
In Beratungsterminen begegnen uns rund um Shopware PaaS immer wieder dieselben Wissenslücken. Wir greifen die vier wichtigsten hier auf, weil sie regelmäßig zu falschen Entscheidungen führen.
Theoretisch bleibt Ihr Investment in die Anwendung portierbar, weil Shopware bewusst keine Cloud-spezifischen Code-Pfade verlangt. Praktisch ist ein Wechsel weg von PaaS aber kein einfacher Backup-Restore-Vorgang. Es gibt keinen klassischen Datenbankzugriff und keinen Dateisystem-Zugriff, mit dem Sie Daten direkt herunterladen könnten. Im Migrationsfall müssen Daten und Medien über Shopware-eigene Import-Export-Mechanismen oder über API-Schnittstellen übertragen werden. Planen Sie das ein, bevor Sie sich für PaaS entscheiden.
Manche Entscheider gehen davon aus, dass ihre Entwickler auf einer managed Cloud keine eigenen Plugins mehr deployen können. Das gilt für SaaS, aber nicht für PaaS. In PaaS deployen Ihre Entwickler via Composer und git wie gewohnt, nur eben in standardisierten Umgebungen statt auf einem von Ihnen betriebenen Server. Klassische Plugins und Apps sind in PaaS nutzbar.
PaaS ist transparenter als reines SaaS. Sie haben Zugriff auf Logs, Metriken und Traces. Gleichzeitig bekommen Sie weniger Einblick als bei einem Macluster-Setup, in dem SSH, FTP und direkter Datenbankzugriff zur Verfügung stehen. Wer aus der Self-Hosted-Welt kommt, sollte einplanen, dass bestimmte Debug-Routinen anders aufgesetzt werden müssen. In eigenen Projekten haben wir Werkzeuge ergänzt, um etwa Datenbankinhalte komfortabel einsehen zu können.
Self-Hosted-Setups wirken in der monatlichen Rechnung günstiger, verursachen aber DevOps- und Patching-Aufwand. Über drei Jahre gerechnet kann dieser Aufwand die scheinbare Ersparnis bei der eigenen Cloud übersteigen. Umgekehrt liegt PaaS im Preisgefüge oberhalb von Self-Hosted. Bei Themen wie dem MySQL 8.0 Extended Support können sich Mehrkosten ergeben, die Sie in der TCO-Betrachtung berücksichtigen sollten. Eine pauschale Aussage „günstiger" oder „teurer" wäre deshalb unseriös, der Vergleich braucht den konkreten Projektkontext.
Wenn Sie heute auf SH laufen und einen Wechsel auf Shopware PaaS prüfen, ist die Migration je nach Komplexität ein überschaubares oder ein anspruchsvolles Projekt. Die Codebasis bleibt im Kern dieselbe, weil Shopware sowohl auf Self-Hosted als auch auf PaaS dieselbe Core-Anwendung ausführt. Was sich ändert, sind die Wege, wie Ihre Entwickler deployen, wie Konfigurationsdaten verwaltet werden und wie Ihr Beobachtungs- und Monitoring-Setup angebunden ist. Wenn Ihre Migration zusätzlich noch einen Versionssprung beinhaltet, hilft unser Beitrag Shopware 5 auf 6 updaten: Jetzt wird es langsam Zeit bei der Planung des Gesamtaufwands.
Aus unseren Migrationsprojekten kristallisieren sich die folgenden Bereiche heraus, in denen am häufigsten nachgearbeitet werden muss:
Aus unserer Beratungspraxis hat sich ein klarer Befund ergeben: Die alleinige Orientierung an der Shop-Größe führt nicht weiter. Entscheidend ist die technische Komplexität. Wir empfehlen, in der Anforderungsanalyse die folgenden Fragen früh zu beantworten:
Für kleinere E-Commerce-Marken mit Standard-Anforderungen, also wenig Customizing, wenigen Integrationen und einem klaren Wunsch nach Einfachheit, ist Shopware SaaS oft die wirtschaftlich vernünftigste Wahl. Hier zahlen Sie nicht für Flexibilität, die Sie nicht abrufen, und profitieren von der Geschwindigkeit, mit der Sie online gehen können.
Für Mid-Market-Commerce-Marken mit individuellen Anforderungen, internem oder agenturseitigem Entwicklerteam und überschaubarer technischer Komplexität ist Shopware PaaS in vielen Fällen unsere Empfehlung. Voraussetzung ist, dass die Anforderungen sich innerhalb der PaaS-Leitplanken bewegen: API-basierte Schnittstellen, keine Spezialanforderungen an PHP-Konfiguration oder Datenbank-Schema. Sie bekommen die Flexibilität von Self-Hosted, ohne die operativen DevOps-Lasten zu tragen.
Für komplexe Shops mit Datei-basierten Schnittstellen, hohem individuellen Konfigurationsbedarf, eigenen Datenbankschemata oder harten Datenhoheits-Anforderungen ist Self-Hosted über Maxcluster weiterhin der richtige Weg. Auch für bestehende Shops mit umfangreicher Historie ist die Migration nach PaaS oft nicht sinnvoll. Eine pauschale Empfehlung wäre an dieser Stelle unseriös.
Shopware PaaS ist weder Hosting-Premium noch Cloud-Lite. Die Cloud-Plattform schließt eine reale Lücke zwischen vollständiger SaaS-Standardisierung und vollumfänglicher Self-Hosted-Verantwortung. Für Mid-Market-Kunden mit überschaubarer Komplexität ist sie oft die naheliegende Wahl, weil sie Flexibilität bei der Anwendung mit klaren Service Levels bei der Cloud kombiniert. Gleichzeitig befindet sich die Plattform technisch noch im Reifeprozess und sie bringt klare Leitplanken mit, die zu Ihren konkreten Anforderungen passen müssen.
Mit Shopware PaaS erhalten Unternehmen Commerce-Plattform und Cloud-Infrastruktur aus einer Hand. Dadurch entfällt die zusätzliche Abstimmung mit externen Hosting- oder Cloud-Anbietern. Statt mehrerer Dienstleister gibt es einen zentralen Vertragspartner mit klaren Verantwortlichkeiten für Plattform, Betrieb und Service Levels. Das reduziert Komplexität, vereinfacht Support-Prozesse und schafft mehr Transparenz im laufenden Betrieb.
Wenn Sie überlegen, ob Shopware PaaS für Sie passt, helfen die hier beschriebenen Kriterien als erste Selbstprüfung. Für eine fundierte Entscheidung empfehlen wir, eine konkrete Architektur-Validierung mit Ihrer Shopware Agentur und mit Shopware durchzuführen. Wenn Sie bei dieser Bewertung Unterstützung brauchen, sprechen Sie uns direkt an. Wir prüfen mit Ihnen gemeinsam Ihre konkrete Ausgangslage, Ihre Roadmap und das passende Cloud-Modell.