Shopware: SaaS, PaaS oder Self-Hosted? Warum die Frage falsch gestellt ist

Die Antwort auf diese Frage sieht fast überall gleich aus: eine Vergleichstabelle mit drei Spalten und Bewertungen von „gering“ bis „sehr hoch“. Am Ende steht immer derselbe Satz – es kommt auf Ihr Business an. Das stimmt. Es hilft nur niemandem.

Wir betreiben und entwickeln seit Jahren Shopware-Projekte im gehobenen Mittelstand und im B2B. In keinem einzigen Fall war „Wie viel Kontrolle brauche ich?“ die Frage, an der die Entscheidung tatsächlich hing. Die eigentliche Frage lautet: Wer trägt die Verantwortung, wenn der Checkout um 3 Uhr nachts steht – und wer hat dann die Daten, um herauszufinden, warum?

Alles andere folgt daraus. Dieser Beitrag dreht die übliche Reihenfolge deshalb um: erst die Ausschlusskriterien, dann die Kostenlogik, dann das Modell. Wenn Sie noch vor der Systemwahl selbst stehen, beginnt die Entscheidung eine Stufe früher – beim herstelleragnostischen Auswahlprozess.

Vier Ausschlusskriterien, die die Entscheidung vorwegnehmen

Bevor Sie Vor- und Nachteile abwägen, prüfen Sie, ob ein Modell für Sie überhaupt in Frage kommt. Vier Kriterien schließen in der Praxis am häufigsten aus – und zwar hart, nicht graduell.

1. Code-Zugriff: App-System oder Plugin?

Das ist der unterschätzteste Punkt der gesamten Diskussion. In Shopware SaaS entwickeln Sie ausschließlich gegen das App-System, also über APIs, von außen, ohne Zugriff auf den Core. In PaaS und Self-Hosted können Sie klassische Plugins bauen, eigene Composer-Pakete einbinden, Services dekorieren, Subscriber registrieren.

Klingt nach einem Detail, ist aber die Wasserscheide. Prüfen Sie es an einem konkreten Beispiel: Ihre Preisfindung liest Staffelpreise und kundenindividuelle Konditionen aus dem ERP. Im App-System heißt das HTTP-Request pro Berechnung, Latenz, Fallback-Logik, Caching-Strategie – ein eigenes kleines verteiltes System. Als Plugin heißt es: ein dekorierter Service im selben Prozess.

Ausschluss: Wenn Ihre Kernlogik in den Bestellprozess eingreifen muss – Preisfindung, Verfügbarkeit, Freigabe-Workflows, Kreditlimit-Prüfung – ist SaaS raus. Nicht „schwieriger“, sondern raus. Warum das gerade im Großhandel regelmäßig unterschätzt wird, zeigt unser Beitrag B2B-E-Commerce: Warum Standard-Shops im Großhandel scheitern.

2. Datenhoheit als Compliance-Anforderung

Nicht „Datenschutz ist uns wichtig“, sondern: Steht in Ihrem Vertrag mit einem Konzernkunden, in Ihrer ISMS-Dokumentation oder in einer Branchenauflage, dass Sie den Verarbeitungsort benennen und Zugriffe protokollieren müssen? Falls ja, brauchen Sie mehr als eine Auftragsverarbeitungsvereinbarung – Sie brauchen Kontrolle über die Infrastruktur.

Ausschluss: Harte Compliance-Auflagen führen zu Self-Hosted bei einem deutschen Provider mit eigenem Rechenzentrum.

3. Debugging-Tiefe

Wenn Ihr Shop langsam ist: Wie tief kommen Sie an die Ursache heran? In einem gemanagten Modell sehen Sie, was das Dashboard des Anbieters zeigt. In einem sauber betreuten Self-Hosted-Setup sehen Sie Slow-Query-Logs, PHP-FPM-Worker-Auslastung, Varnish-Hit-Rate, Redis-Evictions, Message-Queue-Backlog – und mit APM den einzelnen Request bis auf SQL-Ebene.

Der Unterschied zeigt sich nie im Normalbetrieb. Er zeigt sich am Black Friday und drei Tage nach einem Release.

4. Der Exit

Alle drei Modelle setzen auf derselben Codebasis auf – das wird gern als Beleg für Wechselfreiheit angeführt. Das stimmt für den Core. Es stimmt nicht für alles, was Sie darum herum gebaut haben. Ein Wechsel weg von SaaS bedeutet: Apps neu als Plugins denken, Datenexport, DNS, Redirects, SEO-Absicherung, Payment-Neuanbindung. Ein Wechsel von PaaS zu Self-Hosted bedeutet vor allem, Deployment und Infrastruktur neu aufzusetzen.

Faustregel: Je später der Wechsel, desto teurer. Wer heute weiß, dass in 24 Monaten ERP-Integration und internationale Rollouts anstehen, sollte nicht erst dann migrieren. Was ein solcher Schritt umfasst, beschreiben wir im Lexikon unter Replatforming.

Kostenlogik: Sie zahlen für Wachstum oder für Last

Die Modelle unterscheiden sich nicht nur in der Höhe der Kosten, sondern in deren Struktur. Das ist der entscheidende Punkt.

Der Kern in einem Satz: Bei umsatzbasierten Modellen zahlen Sie für Wachstum, bei ressourcenbasierten Modellen für Last. Und beides korreliert im E-Commerce deutlich schlechter, als man annimmt. Ein B2B-Shop mit 400 Bestellungen im Monat und siebenstelligem Umsatz erzeugt kaum Last, kostet in einem umsatzbasierten Modell aber erheblich. Umgekehrt bei einem B2C-Shop mit hohem Traffic und kleinen Warenkörben: viel Last, wenig Umsatz je Bestellung – da kann das Cloud-Modell wirtschaftlich klar überlegen sein.

Rechnen Sie das über fünf Jahre, nicht über ein Jahr. Und nehmen Sie in die Self-Hosted-Spalte ehrlich die Posten mit auf, die in Cloud-Angeboten bereits enthalten sind: Wartung, Updates, Monitoring, Backups, Security, Entwicklungsressourcen. Diese Posten verschwinden nicht, sie wandern nur – zu Ihrem Hosting-Partner und zu Ihrer Agentur. Wie schnell diese Rechnung kippt, zeigen wir in Make or Buy: Warum Eigenbetrieb im E-Commerce oft teurer ist als gedacht.

Kurz und ohne Diplomatie: Wann welches Modell passt

• SaaS ist richtig, wenn Sie Standard-Commerce betreiben, schnell live wollen und Ihre Individualität im Sortiment und im Marketing liegt, nicht im Prozess. Wer hier zu Self-Hosted greift, kauft Komplexität, die er nicht braucht.
• PaaS ist richtig, wenn Sie Code-Zugriff brauchen, aber bewusst kein Ops-Know-how aufbauen wollen, und Ihr Deckungsbeitrag umsatzabhängige Plattformkosten trägt. Ein ehrlicher Hinweis: Prüfen Sie den Reifegrad der konkreten PaaS-Variante zum Zeitpunkt Ihrer Entscheidung – dieser Bereich hat sich in den letzten 24 Monaten mehrfach verändert.
• Self-Hosted ist richtig, wenn individuelle Integrationen, ERP-Anbindung, Datenhoheit und langfristige Kostenplanbarkeit zusammenkommen. Das ist bei den meisten unserer B2B- und Mittelstandsprojekte der Fall – kein technischer Reflex, sondern das Ergebnis der Kriterien oben. Wie eine solche Architektur aussieht, beschreiben wir in Shopware für B2B: Architektur und Best Practices.

Und der Fall, über den selten jemand schreibt: Self-Hosted ist falsch, wenn Sie es als „billiger“ verstehen und dann bei Provider und Betreuung sparen. Ein schlecht betreutes Self-Hosted-Setup ist die schlechteste aller Optionen – volle Verantwortung, keiner der Vorteile. Was dabei konkret schiefgeht, haben wir in Ausfälle, Sicherheitslücken, Lastspitzen aufgeschrieben.

Warum wir bei Self-Hosted zu 100 % auf maxcluster setzen

Self-Hosted heißt nicht „selbst schrauben“. Es heißt: Sie wählen Ihren Infrastrukturpartner selbst – und diese Wahl entscheidet, ob das Modell funktioniert. Für Shopware-Projekte ist unsere Antwort eindeutig und ohne Alternative: maxcluster. Nicht als Standardempfehlung mit Hintertür, sondern als Setzung. Hier ist der technische Grund.

APM powered by Tideways – das Ende des Blame Game

Das wichtigste Feature zuerst, weil es das größte Betriebsproblem im E-Commerce löst. Das klassische Szenario: Die Produktseite lädt vier Sekunden, der Kunde bricht ab – und das Server-Monitoring meldet CPU bei 12 Prozent, RAM bei 40 Prozent, I/O unauffällig. Alles grün. Es folgt die Diskussion zwischen Hoster und Agentur, in der beide Seiten recht haben und niemand die Ursache sieht.

Der Grund: Performance-Probleme im E-Commerce entstehen fast nie auf dem Server, sondern in der Anwendung. Klassisches Infrastruktur-Monitoring kann das strukturell nicht zeigen. maxcluster hat Application Performance Monitoring in Kooperation mit Tideways direkt in das Managed Center integriert – ohne separates Tool, ohne Setup, ohne Systemwechsel. Was das konkret bringt:

• Aufschlüsselung nach Layern: Wie viel Zeit verbringt ein Request in PHP, in SQL, im Cache, in externen Calls? Das ist der Unterschied zwischen „der Shop ist langsam“ und „die Kategorieseite verliert 900 Millisekunden in einer ungeindexten Query“.
• N+1-Queries und fehlende Indizes werden sichtbar. Einzeln kostet eine Query vielleicht 20 Millisekunden zu viel. Bei 200 Queries pro Seitenaufruf sind das Sekunden. In Shopware tritt das typischerweise in Produktlisten, Filtern und im Warenkorb auf – also genau dort, wo die Conversion entsteht.
• Trends statt Momentaufnahmen. Sie sehen, ob ein Release die Performance verschlechtert hat – unter echtem Traffic, nicht im Testsystem.
• Datenhaltung bei maxcluster in Deutschland. Keine Performance-Daten Ihrer Kunden in einer US-Cloud. Für DSGVO-sensible Projekte ist das kein Nice-to-have.

Für uns als Agentur ändert das die Arbeitsweise: Wir diskutieren nicht mehr über Vermutungen, sondern öffnen das Managed Center und sehen, wo die Zeit verloren geht. Optimierung wird zur Messreihe statt zum Bauchgefühl – und zahlt direkt auf die Core Web Vitals ein.

Was den Betrieb sonst absichert

• Managed Center. Der komplette E-Commerce-Stack konfigurierbar, ohne für jede Standardaufgabe auf die Konsole zu müssen: PHP-Versionen und -Module, PHP-FPM-Modus und max_children, OPcache, Varnish inklusive eigener VCL, Redis beziehungsweise Valkey, Elasticsearch und OpenSearch, Solr, Cronjobs, SSH-Keys mit IP-Allowlisting, DNS, SSL.
• Update-Tag mit Stage-First und Rollback. maxcluster aktualisiert monatlich über 2.500 Cluster, Stage-Cluster laufen zuerst, Rollbacks sind in Minuten möglich. Genau das entschärft in der Praxis den Einwand, Self-Hosted bedeute, sich selbst um Updates kümmern zu müssen.
• Backups, die auch ein Ransomware-Szenario überstehen. Immutable Backups plus geografisch getrennte Offsite-Sicherung, mit anpassbaren Intervallen und Aufbewahrungszeiten.
• Sicherheit auf Anwendungsebene. Web Application Firewall, DDoS-Schutz, automatische Malware-Scans mit Sansec-Expertise und ShopSecurity-Checks, die konkret auf typische Schwachstellen prüfen: offene .env-Dateien, ungeschützte Git-Verzeichnisse, veraltete TLS-Versionen, bekannte Lücken in Modulen. PCI-DSS-Unterstützung inklusive.
• local mc. Eine DDEV-Integration, die die lokale Entwicklungsumgebung nah an die Produktionsrealität bringt. Klingt unspektakulär, verhindert aber die teuerste Fehlerklasse überhaupt: Bugs, die erst nach dem Deployment auftreten. Sauberes DevOps beginnt hier, nicht in der Pipeline.
• Eigenes Rechenzentrum in Deutschland, 24/7-Überwachung und deutschsprachiger Support mit E-Commerce-Verständnis. Wenn wir dort anrufen, müssen wir nicht erklären, was ein Shopware-Message-Queue-Worker ist.

Der eigentliche Punkt: maxcluster versteht sich nicht als Serveranbieter, sondern als E-Commerce-Betreiber. Der Unterschied wird an einem Feature wie APM sichtbar – ein reiner Hoster hätte wenig Anlass, Ihnen Werkzeuge zu geben, mit denen Sie sehen, dass das Problem in der Anwendung liegt.

Für uns bedeutet das eine klare Rollenverteilung. maxcluster verantwortet Infrastruktur, Stabilität und Betriebswerkzeuge. Wir verantworten Architektur, Code und Weiterentwicklung. Beide Seiten sehen dieselben Daten. Das ist der Grund, warum Self-Hosted für unsere Projekte funktioniert – und ohne diesen Partner würden wir es so nicht empfehlen. Was professionelles Hosting darüber hinaus leisten muss, lesen Sie in Performance & Sicherheit.

In vier Fragen zur Entscheidung

1. Muss Ihre Geschäftslogik in den Bestellprozess eingreifen? Ja, dann ist SaaS raus.
2. Ist Datenhoheit eine vertragliche oder regulatorische Pflicht? Ja, dann Self-Hosted.
3. Benötigen Sie Debugging bis auf SQL-Ebene? Ja, dann Self-Hosted oder PaaS mit passender Observability.
4. Haben Sie einen Partner, der Betrieb und Observability übernimmt? Nein, dann nicht Self-Hosted – egal, was die ersten drei Antworten sagen.

Bleiben nach Frage 1 bis 3 mehrere Modelle übrig, ist die Entscheidung tatsächlich eine Geschmacksfrage. Das ist aber seltener der Fall, als übliche Vergleichstabellen suggerieren.

Fazit & nächste Schritte

Die Frage ist nicht, wie viel Kontrolle Sie wollen. Die Frage ist, welche Verantwortung Sie tragen können – und wer Ihnen dabei hilft, sie zu tragen. Für Standard-Commerce mit schnellem Time-to-Market ist SaaS die wirtschaftlich klügere Wahl, und das sagen wir auch, wenn es gegen unser eigenes Projektinteresse spricht. Für individuelle B2B- und Mittelstandsprojekte mit ERP-Anbindung, eigenen Prozessen und langfristiger Kostenplanung ist es Self-Hosted – auf maxcluster, mit APM als Standard und nicht als Sonderausstattung.

Sie stehen vor dieser Entscheidung oder betreiben einen Shop, bei dem das Monitoring grün zeigt und die Kunden trotzdem abspringen? Wir schauen uns Ihr Setup an und sagen Ihnen ehrlich, welches Modell passt – auch wenn die Antwort lautet, dass Sie bleiben sollten, wo Sie sind. Mehr zu unseren Leistungen rund um Shopware und Hosting, oder direkt der Shop-Health-Check als Einstieg.