Shopware Apps oder Plugins: die richtige Architektur

Ob eine Erweiterung als App oder als Plugin gebaut wird, entscheidet über Update-Sicherheit, Betriebsmodell und Wartungsaufwand Ihres Shops - lange bevor die erste Zeile Code entsteht. Shopware bietet bewusst zwei Erweiterungssysteme: das App-System, das über API und Webhooks kommuniziert und isoliert läuft, sowie das klassische Plugin, das als Symfony-Bundle direkt im Core arbeitet. Über 100.000 (Shopware) Händler weltweit setzen auf Shopware - für jeden von ihnen ist diese Architekturfrage relevant. Dieser Leitfaden zeigt, wann welches System die richtige Wahl ist und wie wir als Shopware-Agentur die passende Erweiterungsstrategie entwickeln.

Zwei Erweiterungssysteme, eine strategische Entscheidung

Shopware ist laut EHI-Studie 2025 zum vierten Mal in Folge das meistgenutzte Shopsystem in Deutschland und liegt bei 11,5% (Shopware/EHI) der Top-1.000-Onlineshops vorn - das sind 115 (Shopware/EHI) der umsatzstärksten Shops des Landes. Deren Netto-Umsatz erreichte 2024 zusammen 80,4 Milliarden Euro (EHI/eCommerceDB). Wer auf dieser Plattform baut, trifft früh eine grundlegende Weichenstellung: App oder Plugin.

Beide Systeme lösen dieselbe Aufgabe - den Shop um Funktionen zu erweitern - auf grundverschiedene Weise. Das App-System hält die Logik außerhalb des Shops und spricht ihn über Schnittstellen an. Das Plugin wird Teil des Shops und greift direkt auf dessen Services zu. Die Wahl bestimmt, ob Ihre Erweiterung in der Cloud läuft, wie update-sicher sie ist und wie viel Wartung sie über die Jahre verursacht. Sie ist damit eine E-Commerce-Architekturentscheidung, keine reine Geschmacksfrage.

In vielen Projekten fällt diese Entscheidung nebenbei - nach Gewohnheit, nach dem, was das Team kennt, oder nach der erstbesten Erweiterung im Store. Das rächt sich später: Ein Plugin, das eigentlich eine App hätte sein sollen, blockiert den Wechsel in die Cloud; eine App, die tief in den Checkout eingreifen müsste, stößt an die Grenzen ihrer Sandbox. Eine fundierte Architektur-Beratung ersetzt das Bauchgefühl durch eine begründete Zuordnung jeder Funktion zum passenden System - genau darum geht es in diesem Leitfaden.

Das App-System: API, Webhooks und Isolation

Das App-System verlagert die Geschäftslogik einer Erweiterung in ein externes System. Shopware kommuniziert mit der App ausschließlich über HTTP-Anfragen (Shopware Developer Documentation): Ereignisse laufen per Webhook, Daten über die API. Das App-System ist bewusst vom Core entkoppelt (Shopware Developer Documentation) - Entwickler müssen nur die Schnittstelle zwischen Shopware und ihrer App verstehen, nicht die internen Strukturen, und sind in der Wahl von Programmiersprache und Framework frei.

In der Praxis registriert sich eine App beim ersten Aktivieren über einen signierten Handshake und erhält anschließend zeitlich begrenzte Zugangsdaten für die API. Für den Massendatenaustausch - etwa Tausende Produkte oder Bestellungen - steht die Sync-API bereit, die mehrere Schreibvorgänge gebündelt verarbeitet. So bleibt die Kommunikation auch bei großen Datenmengen effizient, ohne dass die App jemals direkten Zugriff auf die Datenbank des Shops benötigt (Shopware Developer Documentation).

Der entscheidende Vorteil: Durch die Entkopplung ist eine App automatisch mit mandantenfähigen Cloud-Systemen kompatibel (Shopware Developer Documentation) und läuft ebenso im Self-Hosted-Betrieb - dieselbe Erweiterung, zwei Betriebsmodelle. Auch spezialisierte Funktionen sind abgedeckt: App-basierte Zahlungsarten gibt es seit Shopware 6.4.1.0 (Shopware Developer Documentation), eigene Rule-Builder-Bedingungen seit Shopware 6.4.12.0 (Shopware Developer Documentation). Für viele Integrationsszenarien ist damit kein Plugin mehr nötig.

Das Plugin-System: Symfony-Bundles mit Core-Zugriff

Ein Plugin ist eine dünne Abstraktionsschicht auf dem Bundle-System von Symfony (Shopware Developer Documentation) und wird damit Teil der Anwendung. Es kann tief in Shopware-Prozesse und -Module eingreifen: über Dependency Injection eigene Services registrieren, per Data Abstraction Layer (DAL) Daten lesen und schreiben, Events abonnieren und die Storefront-Templates verändern. Diese Nähe zum Core ist die eigentliche Stärke des Plugin-Modells.

• Eigene Entitäten: Neue Datenmodelle über die DAL, inklusive Migrationen und Repository-Zugriff
• Prozess-Logik: Cart-Processor und -Collector für individuelle Preis-, Rabatt- und Warenkorb-Regeln im Checkout
• Event-Subscriber: Reaktion auf interne Ereignisse ohne Netzwerk-Umweg, direkt im Shopware-Prozess
• Storefront und Admin: Twig-Templates überschreiben, eigene Administration-Module und Komponenten ergänzen
• Scheduled Tasks: Wiederkehrende Aufgaben über die Message-Queue innerhalb des Shops
• Service-Dekoration: Bestehende Symfony-Services erweitern oder gezielt überschreiben

Diese Tiefe hat einen Preis: Plugins laufen ausschließlich in Self-Hosted-Installationen und benötigen serverseitigen PHP-Zugriff. Aktuelle Versionen setzen PHP 8.2 oder 8.3 voraus (Shopware Documentation) - Shopware 6.7 ergänzt seit dem Release im Mai 2025 die Unterstützung für PHP 8.4 (Shopware). Der Betreiber verantwortet Server, Updates und Kompatibilität selbst, was ein verlässliches Hosting und eine saubere Update-Strategie voraussetzt.

Technisch bringt jedes Plugin eine Basisklasse mit, die den Lebenszyklus steuert: Installieren, Aktivieren, Deaktivieren, Deinstallieren und Aktualisieren lassen sich gezielt behandeln - etwa um beim Update Datenbankschemata sauber zu migrieren. Über den Symfony-Service-Container werden eigene Services registriert und bestehende dekoriert. Diese Kontrolle über den gesamten Lebenszyklus ist ein Grund, warum komplexe Fachlogik häufig weiterhin als Plugin umgesetzt wird.

App oder Plugin: der direkte Vergleich

Die folgende Gegenüberstellung fasst die wesentlichen Unterschiede zusammen. Sie ersetzt keine Einzelfallbetrachtung, macht aber die grundlegend verschiedene Natur der beiden Systeme sichtbar.

Aus der Tabelle wird ein Muster sichtbar: Das App-System optimiert auf Entkopplung, Betriebsflexibilität und geringes Risiko, das Plugin auf Tiefe und Kontrolle. Keine Spalte ist pauschal besser - entscheidend ist, welche Eigenschaften Ihr konkreter Anwendungsfall braucht.

Wann das App-System die richtige Wahl ist

Das App-System spielt seine Stärken überall dort aus, wo eine Erweiterung nicht tief in den Bestellprozess eingreifen muss, sondern Daten transportiert, mit externen Diensten spricht oder über viele Shops hinweg funktionieren soll. Für das Synchronisieren von Produkten, Bestellungen und Kunden mit einem ERP-System wie SAP Business One ist der API-basierte Ansatz die naheliegende Wahl - skalierbar und über Umgebungen hinweg wiederverwendbar.

• Ihr Shop läuft in einer Cloud-Umgebung ohne Server- und Dateizugriff
• Sie gleichen Daten mit einem externen System ab, das die eigentliche Logik bereitstellt
• Die Erweiterung soll über mehrere Shops und Mandanten hinweg wiederverwendbar sein
• Ein externer Dienst übernimmt Zahlung, Versand oder Steuerberechnung
• Update-Sicherheit und geringer Wartungsaufwand stehen im Vordergrund
• Das Team arbeitet lieber in einer anderen Sprache als PHP

Wer perspektivisch in Richtung Cloud-Betrieb plant, sollte neue Erweiterungen ohnehin als App konzipieren - so bleibt der Wechsel des Betriebsmodells offen, ohne die Erweiterungen neu bauen zu müssen.

Wann ein Plugin unverzichtbar ist

Sobald eine Erweiterung Logik direkt im Herzen des Shops ausführen muss, führt am Plugin kaum ein Weg vorbei. Individuelle Preis- und Rabattregeln im Checkout, eigene Datenmodelle oder tiefe Anpassungen der Storefront-Templates verlangen den direkten Zugriff, den nur ein im Core laufendes Symfony-Bundle bietet.

• Individuelle Warenkorb-Berechnung sowie Rabatt- oder Preislogik direkt im Checkout
• Eigene Datenbank-Entitäten über die Data Abstraction Layer mit vollem Lese- und Schreibzugriff
• Tiefe Eingriffe in Storefront-Templates und Administration-Komponenten
• Event-Subscriber und geplante Aufgaben innerhalb des Shopware-Prozesses
• Performancekritische Logik, die ohne Netzwerk-Latenz zu einem externen Dienst laufen muss
• Bestehende Symfony-Services, die erweitert oder überschrieben werden sollen

Wartung, Updates und Gesamtkosten im Blick

Die Wahl zwischen App und Plugin ist nicht nur eine technische, sondern eine wirtschaftliche Entscheidung. Über den Lebenszyklus einer Erweiterung entstehen die meisten Kosten selten bei der Erstentwicklung, sondern bei Pflege, Updates und Kompatibilitätstests. Genau an diesem Punkt unterscheiden sich die beiden Systeme deutlich - und genau hier zahlt sich eine bewusste Architekturentscheidung über die Jahre aus.

Ein Plugin ist an die Core-Version gebunden: Bei jedem größeren Shopware-Sprung muss der Code geprüft und oft angepasst werden. Eine App bleibt dank ihrer stabilen Schnittstelle unabhängiger vom Core und übersteht Updates in der Regel ohne Eingriff, solange sich die API-Verträge nicht ändern. Wer die Betriebskosten realistisch plant, sollte diese Unterschiede von Anfang an einkalkulieren.

• Erstentwicklung: Plugins erfordern Shopware- und Symfony-Know-how, Apps zusätzlich einen Betriebsort für den externen Dienst
• Updates: Plugins werden bei Core-Sprüngen geprüft, Apps bleiben über die Schnittstelle stabiler
• Betrieb: Ein Plugin läuft im Shop mit, eine App benötigt eigene Infrastruktur und Überwachung
• Risiko: Ein Plugin-Fehler kann den Shop beeinträchtigen, ein isolierter App-Fehler bleibt begrenzt
• Wiederverwendung: Apps lassen sich über mehrere Shops ausrollen, Plugins werden je Installation gepflegt

Hybride Strategien und die Update-Frage

In der Praxis schließen sich beide Systeme nicht aus. Viele Shops kombinieren robuste Plugins für die tiefe Prozesslogik mit Apps für Integrationen und externe Dienste. Mit App-Scripts verschwimmt die Grenze zusätzlich: Seit Shopware 6.4.8.0 (Shopware Developer Documentation) lässt sich sogar Warenkorb-Logik sandboxed im App-Kontext ausführen - Funktionalität, die früher zwingend ein Plugin erforderte.

Die Update-Frage bleibt dabei der entscheidende Kostenfaktor über die Jahre. Plugins sind an die Core-Version gebunden und müssen bei jedem größeren Sprung geprüft werden - etwa beim Wechsel der PHP-Version im Zuge einer Shopware-Aktualisierung. Apps bleiben dank stabiler Schnittstelle unabhängiger. Wer eine modulare Architektur anstrebt, findet in Composable- und Headless-Ansätzen den größeren Rahmen, in den sich die App-Plugin-Entscheidung einfügt.

Die Frage ist selten App oder Plugin im Absoluten, sondern welche Funktion gehört wohin. Eine saubere Trennung von Integrationen als Apps und Kernlogik als Plugins spart über Jahre Wartungskosten.

XICTRON Entwicklungsteam

Ein typisches Muster aus der Praxis: Die Anbindung an Warenwirtschaft und Versand läuft als App über die API, während Rabatt- und Preislogik, Sonderpreise für Stammkunden oder ein individueller Konfigurator als Plugin direkt im Core arbeiten. So erhält jede Anforderung das System, das am besten zu ihr passt - und der Shop bleibt zugleich anschlussfähig für einen späteren Cloud-Umzug, ohne dass die Integrationen neu gebaut werden müssen.

Auch die nächste Generation von Schnittstellen lässt sich sauber über das App-System anbinden - etwa wenn Sie KI-Agenten über standardisierte Protokolle mit dem Shop verbinden oder regulatorische Anforderungen wie die neuen Produktsicherheits-Pflichten über angebundene Dienste abbilden wollen. Die Architekturentscheidung von heute bestimmt, wie leicht solche Erweiterungen morgen andocken.

So entwickeln wir Ihre Erweiterungsstrategie

Statt aus dem Bauch heraus zu entscheiden, beginnen wir mit einer nüchternen Analyse Ihrer Anforderungen, Ihres Betriebsmodells und Ihrer Roadmap. Daraus leiten wir pro Funktion ab, ob sie als App, als Plugin oder als hybride Lösung am besten aufgehoben ist - und bauen sie so, dass sie zu Ihrem Shop und Ihrem Team passt.

Ob App-System, klassisches Plugin oder eine durchdachte Kombination aus beidem: Entscheidend ist, dass die Architektur zu Ihren Zielen passt und nicht umgekehrt. Unsere E-Commerce-Beratung begleitet Sie von der ersten Analyse bis zur produktiven Erweiterung.

Häufige Fragen zu Shopware Apps und Plugins