Was macht ein gutes Shopware-Setup aus? Mehr als die Mindestanforderungen

Die kurze Antwort

Ein gutes Shopware-Setup geht über die Mindestanforderungen hinaus: Es ist robust, ausfallsicher und so gebaut, dass neue Features stabil laufen und stabil bleiben. Dazu gehören neben Webserver, PHP und Datenbank auch Komponenten, die Shopware als optional führt: Redis, OpenSearch, eine Message Queue, ein separater Dateispeicher und ein Reverse Proxy. Genauso wichtig sind der Prozess (Deployments ohne Wartungsmodus, ein Testsystem nah am Live-Shop) und ein Hosting, das Ausfälle und Wartung abfängt, ohne dass der Shop steht.

Was unterscheidet ein gutes Shopware-Setup von den Mindestanforderungen?

Die Mindestanforderungen sagen nur, ob Shopware startet. Ein gutes Setup beantwortet drei andere Fragen: Läuft der Shop auch unter Last stabil? Fängt er Ausfälle einzelner Teile ab? Und gehen neue Features live, ohne an anderer Stelle etwas kaputt zu machen? Unser Shopware-Team setzt Schutz gegen Angriffe dabei als selbstverständlich voraus und misst ein Setup vor allem daran, ob Änderungen heute und in Zukunft sauber laufen.

Für dich als Shopbetreiber ist das der entscheidende Unterschied. Ein Shop, der die Mindestanforderungen erfüllt, funktioniert an einem ruhigen Dienstag. Ein guter Shop funktioniert auch am Tag der großen Kampagne, beim nächsten Update und bei der dritten Änderung in Folge. Die folgenden Abschnitte zeigen, welche Bausteine dafür sorgen, und verweisen für die Details jeweils auf unsere Vertiefungsartikel.

Welche Server-Anforderungen hat Shopware 6?

Laut der offiziellen Hosting-Dokumentation von Shopware braucht Shopware 6 mindestens PHP 8.2 (empfohlen 8.4) mit einem memory_limit von mindestens 512 MB, dazu MariaDB ab 10.11.6 oder MySQL ab 8.0.22 und einen Webserver wie Caddy, Apache oder Nginx. Redis bzw. Valkey für Cache und Sessions sowie OpenSearch für Suche und Indexierung führt Shopware als optional.

Genau dieses „optional“ ist die Stelle, an der sich gute von minimalen Setups trennen. Ohne Redis und OpenSearch läuft ein Shop, aber Cache, Sessions und Produktsuche landen auf der Datenbank, die dann alles gleichzeitig erledigen muss. Für einen kleinen Katalog mit wenig Besuchern mag das reichen. Für einen B2B-Shop mit Tausenden Artikeln, Kundenpreisen und Login wird die Datenbank schnell zum Engpass.

Welche Komponenten gehören zu einem professionellen Shopware-Setup?

Ein professionelles Setup verteilt die Arbeit auf spezialisierte Komponenten, damit nicht alles an der Datenbank hängt. Pflicht sind Webserver, PHP und Datenbank. Dazu kommen ein Cache-Speicher (Redis bzw. Valkey), eine Suchmaschine (OpenSearch), eine Message Queue für Hintergrundaufgaben, ein separater Dateispeicher und ein Reverse Proxy, der fertige Seiten ausliefert. Jede Komponente nimmt der Datenbank oder dem Webserver eine Aufgabe ab.

Wofür braucht Shopware eine Message Queue?

Eine Message Queue ist eine Warteschlange für Aufgaben, die nicht sofort im Seitenaufruf erledigt werden müssen. Shopware legt solche Aufgaben ab, und separate Prozesse (Worker) arbeiten sie im Hintergrund ab. Laut Shopware-Dokumentation versendet Shopware Mails standardmäßig synchron, was die Seitengeschwindigkeit beeinträchtigen kann. Über die Message Queue laufen sie im Hintergrund.

Was das praktisch heißt, zeigt der Moment mit vielen gleichzeitigen Bestellungen. Muss der Shop jede Bestellbestätigung sofort selbst verschicken, bindet das genau dann Ressourcen, wenn der Checkout sie am dringendsten braucht. Mit Message Queue landet die Mail in der Warteschlange, und der nächste Kunde kann weiter bestellen. Unser Shopware-Team setzt dafür in der Regel RabbitMQ ein. Shopware empfiehlt außerdem, die Warteschlange auf Produktivsystemen über eigene Worker-Prozesse statt über den Admin-Worker im Browser abzuarbeiten, damit Aufgaben auch dann laufen, wenn niemand im Backend eingeloggt ist.

Was gehört in Redis, und was bringt das dem Shop?

Redis ist ein sehr schneller Zwischenspeicher im Arbeitsspeicher. Lesezugriffe auf die Datenbank sind vergleichsweise teuer. Redis legt häufig gebrauchte Daten deshalb so ab, dass sie schneller gelesen werden können, und entlastet gleichzeitig die Datenbank. Für Setups mit mehreren Servern empfiehlt die Shopware-Dokumentation zum Cluster-Setup mindestens fünf getrennte Redis-Instanzen: für Session und Warenkorb, Objekt-Cache, Locks und Zähler, Nummernkreise sowie die Message Queue.

Der Nutzen für dich ist doppelt: Seiten und Warenkörbe reagieren schneller, und die Datenbank hat mehr Luft für das, was nur sie kann, etwa Bestellungen sauber zu speichern. Dass Redis eingerichtet ist, heißt allerdings nicht, dass es auch genutzt wird. Wie oft Redis zwar angelegt, aber nicht aktiv ist, und wie man das prüft, beschreiben wir in unserem Artikel über die häufigsten Fehler in übernommenen Shopware-Setups.

Warum Dateien in einen separaten Speicher auslagern, und was ist mit dem CDN?

Ein separater Dateispeicher (meist S3 oder ein S3-kompatibler Anbieter) legt Bilder, Medien und Dokumente außerhalb des Webservers ab. Laut Shopware-Dokumentation ist er Pflicht, sobald mehrere App-Server laufen, weil Dateien auf der lokalen Platte eines Servers für die anderen unsichtbar sind. Auch mit nur einem Server bringt er Backups, Redundanz und Speicher, der mit den Daten wächst.

Vor einigen Jahren galt das Content Delivery Network als zentraler Performance-Tipp. Auch wir haben es 2024 noch so eingeordnet. Heute ist die Speicherfrage die wichtigere Architekturentscheidung: Ein separater Dateispeicher macht mehrere App-Server erst möglich, und Bilder und Medien liegen nicht mehr auf dem Webserver, der sie sonst neben allen Seitenaufrufen ausliefern muss. Ein CDN kann zusätzlich davor sitzen. Die Shopware-Dokumentation empfiehlt es etwa für Shops, die Dateien lokal speichern und viel Traffic haben, und erlaubt auch, die öffentliche Adresse des Dateispeichers auf eine CDN-Domain zu legen. Es ersetzt die Speicherfrage aber nicht und ist nicht für jeden Shop nötig.

Was bringt ein Reverse Proxy vor dem Shop?

Ein Reverse Proxy ist ein Cache-Server, der vor dem Shop sitzt. Ruft ein Besucher eine Seite auf, die ein anderer Besucher kurz vorher schon angefordert hat, liefert der Proxy die fertige Seite direkt aus, ohne dass Shopware sie neu berechnen muss. Die Shopware-Dokumentation empfiehlt bei mehreren App-Servern einen Reverse-Proxy-Cache wie Varnish und liefert dafür eine Standardkonfiguration mit.

Der Effekt ist spürbar, weil die teuerste Arbeit wegfällt: Warenkorb, Preise und Seitenaufbau müssen für viele Aufrufe nicht neu berechnet werden. Eine Grenze hat das Ganze allerdings, gerade im B2B-Geschäft. Für eingeloggte Kunden oder sobald Produkte im Warenkorb liegen, liefert Shopware standardmäßig keine kompletten Seiten aus dem Cache. Wann Caching hilft und wann ein anderer Hebel besser greift, erklären wir im Artikel Shopware-Performance optimieren.

Wie laufen Deployments ohne Wartungsmodus?

Ein Deployment ist das Ausrollen neuer Code-Stände auf den Live-Shop. In einem schwachen Setup schaltet der Shop dafür jedes Mal in den Wartungsmodus, oft eine halbe Stunde lang, in der niemand bestellen kann. In einem guten Setup läuft das Deployment im laufenden Betrieb. Bei unserem Shopware-Team bekommen Besucher davon in aller Regel nichts mit.

Ganz ohne Restrisiko geht es nicht: Klickt ein Kunde genau im Moment des Umschaltens auf „Kaufen“, kann bei ihm ein Fehler auftreten. Das ist sehr unwahrscheinlich und betrifft dann einzelne Kunden, nicht alle. Der Unterschied zur Wartungspause ist für dich wirtschaftlich erheblich, gerade wenn du häufig Änderungen ausrollst. Voraussetzung ist ein sauberer, automatisierter Deployment-Prozess. Wie Staging und Live sauber gleich bleiben, beschreibt unser Artikel zur Deployment-Hygiene.

Wie nah muss das Testsystem am Live-Shop sein?

So nah wie möglich. Ein Testsystem (Staging) ist nur dann aussagekräftig, wenn Server-Setup, Konfiguration und Code-Stand dem Live-Shop entsprechen. In den Setups, die unser Shopware-Team betreut, unterscheidet sich Staging nur im Datenstand vom Live-Shop, also bei Produkten und Bestellungen. Und es sollte immer mindestens auf demselben Code-Stand sein wie Live, nie dahinter.

Für ein gutes Setup gehört dazu auch, dass sich der Live-Datenstand mit vertretbarem Aufwand auf Staging spiegeln lässt. Manuell kostet das schnell einen halben Tag, automatisiert geht es deutlich schneller. Das klingt nach Detail, entscheidet aber darüber, ob Tests mit realistischen Daten stattfinden oder aus Zeitgründen ausfallen. Kundendaten sollten dabei anonymisiert werden, damit sie nicht ungeschützt auf dem Testsystem liegen.

Wie sichert das Hosting den Shop gegen Ausfälle ab?

Über Redundanz: Fällt ein Server aus, übernimmt ein anderer. Unser Shopware-Team arbeitet mit zwei verbreiteten Strategien. Bei der ersten steht ein gespiegelter Zweitserver bereit, auf den bei einem Ausfall umgeschaltet wird. Ein Anbieter verspricht dafür etwa 60 Sekunden. Bei der zweiten verteilt sich der Shop auf mehrere App-Server, und ein ausgefallener Server wird einfach aus dem Verbund genommen.

Redundanz hilft auch bei Wartung. Muss etwa die Datenbank auf eine neue Version, schaltet das Hosting auf das Ersatzsystem um, aktualisiert das Hauptsystem, schaltet zurück und aktualisiert danach das Ersatzsystem. Der Shop bleibt dabei erreichbar. Von einem guten Hosting solltest du solche Strategien erwarten. Wie zwei Shopware-Hoster das konkret umsetzen, zeigt unser Hosting-Vergleich von ScaleCommerce und maxcluster.

Wann reicht ein Server, und wann braucht es mehrere?

Für viele Shops reicht ein gut ausgestatteter Server mit Failover. Mehrere App-Server lohnen sich, wenn der Traffic regelmäßig hoch ist oder starke Spitzen auftreten, etwa bei großen Kampagnen. Die meisten Shops, die unser Shopware-Team betreut, kommen im Regelbetrieb mit ein bis zwei App-Servern gut aus und lasten ihre Infrastruktur gar nicht aus.

Der Unterschied liegt in der Art zu wachsen. Mehr CPU-Kerne und Arbeitsspeicher für einen Server (vertikal skalieren) sind einfach, stoßen aber irgendwann an eine Grenze. Zusätzliche Server (horizontal skalieren) sind teurer und aufwendiger im Betrieb, lassen sich aber fast beliebig erweitern. Für horizontales Skalieren brauchst du die Bausteine von oben: einen gemeinsamen Dateispeicher und Redis, damit alle Server dieselben Daten sehen. Vor- und Nachteile beider Wege vertieft unser Artikel zu horizontaler und vertikaler Skalierung.

Woran erkennst du, ob dein Shopware-Setup gut ist?

Am einfachsten mit ein paar direkten Fragen an deine Agentur oder deinen Hoster. Die Antworten zeigen schnell, ob dein Setup nur die Mindestanforderungen erfüllt oder für Last, Ausfälle und Weiterentwicklung gebaut ist. Wenn mehrere Fragen mit „nein“ oder „weiß ich nicht“ beantwortet werden, lohnt sich ein genauerer Blick.

• Laufen Deployments ohne Wartungsmodus?
• Gibt es ein Testsystem, das technisch dem Live-Shop entspricht und nie hinter dessen Code-Stand liegt?
• Sind Redis und OpenSearch aktiv im Einsatz oder nur angelegt?
• Werden Mails und Hintergrundaufgaben über eine Message Queue mit eigenen Workern abgearbeitet?
• Liegen Bilder und Dateien in einem separaten Speicher mit Backup?
• Was passiert, wenn der Server ausfällt, und wie lange ist der Shop dann weg?
• Lassen sich Datenbank-Updates ohne Shop-Stillstand einspielen?
• Wird der Shop überwacht, und wer wird bei einem Ausfall informiert?

Ein gutes Setup kostet im Betrieb mehr als ein minimales. Was die einzelnen Posten im laufenden Betrieb ausmachen, zeigt unsere Übersicht zu den Shopware-Kosten. Ein gutes Setup ist außerdem die Grundlage einer sauberen Wartung nach dem Go-live.

Wie wir dich unterstützen können

Wir bei datrycs bauen und betreuen Shopware-Setups so, dass sie unter Last stabil bleiben, Ausfälle abfangen und neue Features ohne Wartungspause live gehen. Wenn du wissen willst, wie dein aktuelles Setup bei den Fragen oben abschneidet, sprich uns über das Kontaktformular am Ende dieser Seite an.