Shopware 6 Hosting: Worauf es wirklich ankommt

Shopware 6.7 verlangt mindestens PHP 8.2 und führt in seiner offiziellen Stack-Übersicht PHP 8.4 als empfohlene Version. Wer heute ein Shopware Hosting bucht, bei dem 8.2 die neueste verfügbare Version ist, kauft ein Ablaufdatum mit. Nicht in fünf Jahren, sondern beim nächsten Major-Release.

Genau da gehen die meisten Hosting-Entscheidungen schief. Geführt werden sie als Preisvergleich, obwohl eine technische Entscheidung mit Folgekosten dahintersteckt. Neun Euro gegen neunundzwanzig, ähnlich viel Speicher, also nimmt man die neun. Zwei Jahre später steht der Shop auf einer PHP-Version, die Shopware nicht mehr unterstützt, und der Umzug kostet ein Vielfaches der Ersparnis.

Ein Angebot liest sich anders, wenn du weißt, wonach du suchst. Neun Punkte, eine Schwelle, ein Fall in dem teureres Hosting nichts löst. Keine Anbieternamen, keine Preise, die morgen anders aussehen.

Die neun Punkte, an denen du ein Shopware Hosting bewertest

1. PHP-Version und Nachzieh-Geschwindigkeit. Shopware hebt die unterstützten PHP-Versionen mit den Major-Releases an. Für 6.7 sind es mindestens 8.2, empfohlen 8.4. Frag nicht nur, welche Version heute läuft, sondern wie viele Wochen der Anbieter nach dem PHP-Release braucht, bis er sie anbietet. Wer ein Jahr hinterherhinkt, blockiert dein nächstes Shopware-Update.

2. OPcache und Realpath-Cache. Shopware nennt in seinen Performance-Empfehlungen konkrete Werte: opcache.max_accelerated_files=20000, opcache.interned_strings_buffer=20, opcache.validate_timestamps=0 im Produktivbetrieb und realpath_cache_ttl=3600. Frag, ob du diese Werte setzen darfst. Bei vielen Billig-Tarifen lautet die Antwort nein, und dann bringt der schnellste Prozessor wenig.

3. Datenbank-Variante und Version. Shopware 6.7 setzt MariaDB ab 10.11.6 oder MySQL ab 8.0.22 voraus, als empfohlene Versionen nennt die Doku MariaDB 11.4 beziehungsweise MySQL 8.4. Wichtig sind zwei Serverwerte: group_concat_max_len muss laut Shopware mindestens 320000 betragen und sql_mode darf ONLY_FULL_GROUP_BY nicht enthalten. Steht im Angebot nur “MySQL”, frag nach der Minor-Version.

4. Arbeitsspeicher für PHP. Shopware fordert ein memory_limit von mindestens 512 MB. Für Produktimporte über die Administration ist das die Untergrenze, nicht der Zielwert. Wer regelmäßig größere Kataloge importiert, sollte 1 GB oder mehr setzen dürfen.

5. Cron und Worker als eigener Prozess. Zwei getrennte Dinge. Der Cron ruft bin/console scheduled-task:run --no-wait auf, das Beispiel in der Shopware-Doku steht auf alle fünf Minuten. Der Worker ist ein dauerhaft laufender Prozess, in der Doku als bin/console messenger:consume async --time-limit=60 --memory-limit=128M notiert, gestartet und überwacht von systemd oder Supervisor. Kann dein Hoster keinen dauerhaften Prozess betreiben, streich ihn von der Liste.

6. Elasticsearch oder OpenSearch, aber nur bei Bedarf. Shopware führt die Suche im offiziellen Stack als optional und nennt bewusst keine harte Produktzahl. Der einzige Anhaltspunkt in der Doku lautet, dass sich die Anbindung lohnt, sobald ein Projekt mehrere tausend Datensätze führt. Unsere Faustregel dazu: unter 5.000 Artikeln inklusive Varianten kaufst du dir Infrastruktur, die du warten und bezahlen musst, ohne dass ein Kunde den Unterschied merkt. Unterstützt sind OpenSearch ab 1.0 und Elasticsearch ab 7.8.

7. Objekt-Cache. Shopware nennt Redis ab Version 7 als Minimum und Valkey 8.0 als Empfehlung. Genutzt wird er für Sessions, Warenkorb, Objekt-Cache und Locks. Auf Shared Hosting fast nie verfügbar. Ohne Objekt-Cache landet alles in der Datenbank, und die wird zum Engpass, bevor die CPU es wird.

8. Staging-Umgebung. Eine zweite Instanz mit derselben Konfiguration, auf der du Updates testest. Manche Tarife bringen sie mit, bei anderen buchst du faktisch zwei Pakete. Rechne das in den Preis ein, sonst testest du in Produktion.

9. Backup-Rückspielzeit statt Backup-Häufigkeit. Fast jeder Anbieter wirbt mit täglichen Backups. Die relevante Frage ist eine andere: Wie lange dauert es vom Anruf bis zum wieder laufenden Shop, und machst du das selbst oder der Support? Aus unserer Projekterfahrung liegt ein mittelgroßer Shop bei zwei bis sechs Stunden, wenn der Ablauf geübt ist. Ist er es nicht, wird ein Tag daraus.

Die Schwelle, ab der Shared Hosting nicht mehr trägt

Klare Regel, damit du nicht nach Gefühl entscheidest. Shared Hosting trägt, solange dein Shop unter allen drei Werten bleibt: 5.000 Artikel inklusive Varianten, 50 Bestellungen pro Tag, 30 gleichzeitige Besucher in der Spitze. Reißt du einen davon dauerhaft, gehörst du auf einen Managed Server oder in die Cloud. Diese drei Zahlen sind Erfahrungswerte aus unseren Projekten, keine offizielle Shopware-Angabe.

Der Grund liegt nicht in der Rechenleistung. Ab dieser Größe brauchst du Dinge, die Shared Hosting technisch nicht liefert: einen dauerhaft laufenden Worker-Prozess, einen Objekt-Cache, konfigurierbare PHP-Werte und ab ein paar tausend Artikeln eine Suche jenseits von MySQL.

Und eine Vorbedingung, die die Schwelle aushebelt: Erlaubt dein Tarif keinen SSH-Zugang, kein memory_limit von 512 MB und keinen Hintergrundprozess, trägt er von Tag eins nicht. Dann ist die Artikelzahl egal.

Beim Wechsel selbst hilft es, ehrlich zu rechnen. Ein Umzug im laufenden Betrieb kostet aus unserer Projekterfahrung ein bis zwei Entwicklertage. Bei einem üblichen Tagessatz von 1.000 Euro im DACH-Raum sind das 1.000 bis 2.000 Euro plus deine eigene Zeit für Tests. Das relativiert die Ersparnis von 20 Euro im Monat ziemlich schnell.

Wann mehr CPU dein Problem nicht löst

Hosting ist der falsche Hebel, wenn dein Shop aus anderen Gründen langsam ist. Drei Verdächtige, die häufiger schuld sind als der Server: zu viele Plugins, die sich in dieselben Events hängen, eine Datenbank, in der seit Jahren niemand aufgeräumt hat, und Produktbilder, die als 4-MB-JPEG ausgeliefert werden.

So prüfst du das in zehn Minuten, bevor du ein teureres Paket buchst. Miss die reine Server-Antwortzeit einer Kategorieseite bei aktivem HTTP-Cache. Liegt sie unter 200 Millisekunden, ist dein Server nicht das Problem. Dann liegt der Fehler im Frontend oder in einer Erweiterung, und mehr CPU kauft dir nur Zeit, bis die nächste Lastspitze kommt. Welche Hebel im Frontend tatsächlich etwas bringen, haben wir im Beitrag zu Pagespeed und Ranking auseinandergenommen.

Ehrlich gesagt sehen wir das oft: Ein Shop wandert auf doppelt so starke Hardware, die Ladezeit verbessert sich um 15 Prozent, und ein halbes Jahr später steht dieselbe Frage wieder da. Das Geld wäre in einem Plugin-Audit besser angelegt gewesen.

Der Fehler, der in fast jedem übernommenen Shop steckt

Der Message-Queue-Worker läuft nicht als Dienst, sondern nur über den Admin-Worker im Browser. Das ist Shopwares Standard für Entwicklungsumgebungen, und weil es im Test funktioniert, bleibt es so.

Ursache ist meistens der Hoster: Kein SSH, kein systemd, kein Supervisor, also keine Möglichkeit, messenger:consume dauerhaft laufen zu lassen. Die Folge merkst du nicht sofort, sondern zwei Wochen später. Der Suchindex aktualisiert sich nur, wenn jemand in der Administration eingeloggt ist. Bestellbestätigungen gehen verzögert oder gar nicht raus. Der Cache-Warmup findet nachts nicht statt, also trifft der erste Kunde am Morgen einen kalten Cache. Shopware selbst schreibt in der Doku klar, dass die Queue im Produktivbetrieb über die CLI laufen soll und nicht über den Browser.

Der Test dauert fünf Minuten: Logg dich aus der Administration aus, schließ alle Browser-Tabs, leg im Shop eine Testbestellung an. Kommt die Bestätigungsmail nicht innerhalb weniger Minuten an, läuft dein Worker nicht als Dienst.

Was du jetzt tun kannst

Nimm dein aktuelles Hosting-Angebot und geh die neun Punkte durch. Bei drei oder mehr offenen Antworten hast du kein Preisproblem, sondern ein Betriebsrisiko. Frag den Anbieter schriftlich, nicht im Chat, und lass dir die PHP-Roadmap geben.

Denkst du ohnehin gerade über einen Wechsel oder eine Migration von Shopware 5 auf 6 nach, ist der Zeitpunkt gut. Wir betreuen Shopware-Shops im laufenden Betrieb und wissen, welche Fragen ein Anbieter beantworten muss, bevor du unterschreibst. Die Fokus-Session dauert 60 Minuten und hält dein aktuelles Angebot gegen die neun Punkte: PHP-Roadmap, Worker als Dienst, Datenbankversion und Backup-Rückweg, jeweils mit der Frage, was davon schriftlich zugesagt ist.