Shopware env-Konfiguration: So vermeidest du Go-live-Probleme

Es ist Montagmorgen, 9:30 Uhr. Dein neuer Shopware-Shop soll heute live gehen. Du hast das Deployment auf den Produktionsserver angestoßen, alle Dateien sind hochgeladen, die Datenbank ist migriert. Du öffnest die Admin-URL im Browser – und siehst: „Network Error". Ein Blick in die Konsole zeigt 500er-Fehler, die Storefront lädt nicht, und dein E-Mail-Postfach bleibt leer, obwohl Testbestellungen längst raus sein sollten – genau der Moment, in dem eine erfahrene Shopware-Agentur mit einem sauberen Go-live-Prozess den Unterschied macht.

Was ist passiert? Die Antwort liegt meist in einem unscheinbaren Detail: der Shopware env-Konfiguration. Umgebungsvariablen steuern, wie sich dein Shop in verschiedenen Umgebungen verhält – Development, Staging, Production. Wenn diese Werte nicht korrekt gesetzt oder nicht sauber getrennt sind, führt das zu Admin-Fehlern, fehlgeschlagenen Mailversänden, Performance-Problemen bei der Suche oder hängenden Background-Jobs.

In diesem Ratgeber erfährst du, was Shopware env bedeutet, welche Variablen wirklich entscheidend sind, wie du Dev, Staging und Prod sauber voneinander trennst und welche typischen Fehler du vermeiden solltest. Am Ende bekommst du eine praxisnahe Go-live-Checkliste, die dir hilft, solche Überraschungen künftig zu verhindern.

Was Shopware env ist – und warum du es als Nicht-Entwickler verstehen solltest

Wenn du mit Shopware arbeitest, hast du wahrscheinlich schon von der .env-Datei gehört. Diese Datei liegt im Shopware Stammverzeichnis und enthält Umgebungsvariablen, die bestimmen, wie dein Shop sich verhält – ohne dass Code geändert werden muss. Das Prinzip ist einfach: Dieselbe Codebasis läuft in verschiedenen Umgebungen (lokal beim Entwickler, auf einem Staging-Server, in der Produktion), aber jede Umgebung hat andere URLs, Datenbank-Zugangsdaten, Mail-Server oder Suchmaschinen-Endpunkte.

Statt diese Werte hart im Code zu verdrahten, liest Shopware sie aus der .env-Datei oder direkt aus den Umgebungsvariablen des Systems.

Warum ist das für dich als Projektleitung oder Shop-Betreiber relevant? Weil falsch gesetzte env-Variablen die häufigste Ursache für Go-live-Probleme sind. Selbst wenn deine Agentur oder dein Hoster technisch versiert ist, musst du als Entscheider verstehen, welche Einstellungen kritisch sind und welche Fragen du stellen solltest. Denn am Ende bist du verantwortlich, wenn der Shop nicht läuft – und das kannst du nur kontrollieren, wenn du die Basics kennst.

Die gute Nachricht: Du musst kein DevOps-Experte werden. Es reicht, wenn du die 5-6 wirklich wichtigen Variablen kennst und weißt, wann welche Einstellung welche Auswirkung hat. Denk an env-Variablen wie an die Grundeinstellungen deines Autos: Du musst nicht wissen, wie der Motor funktioniert, aber du solltest wissen, wo Licht, Blinker und Scheibenwischer sind – und dass du mit Winterreifen im Sommer nicht optimal fährst.

Wann ist Shopware env überhaupt deine Baustelle? Cloud vs. Managed vs. Self-hosted

Bevor wir in die Details einsteigen, ist es wichtig zu verstehen: Nicht bei jedem Setup musst du dich intensiv mit env-Variablen auseinandersetzen. Die Relevanz hängt stark von deinem Hosting-Modell ab.

Shopware Cloud (PaaS)

Wenn du Shopware Cloud nutzt, kümmert sich Shopware selbst um die meisten Infrastruktur-Details. Env-Variablen werden über ein Web-Interface oder die Cloud-CLI gesetzt, viele kritische Einstellungen (Datenbank, Cache, Mail) sind vorkonfiguriert oder werden automatisch gemanagt. Deine Rolle als Entscheider: Prüfen, dass APP_URL korrekt ist, Mail-Versand funktioniert und nach Updates alles läuft. Du musst nicht tief ins System eingreifen.

Managed Hosting (z.B. spezialisierte Shopware-Hoster)

Hier übernimmt dein Hoster Server-Setup, Updates, Backups und oft auch env-Konfiguration. Du hast mehr Kontrolle als in der Cloud, aber viele technische Details werden für dich erledigt. Deine Rolle: Verstehen, welche env-Variablen existieren, bei Problemen die richtigen Fragen stellen und sicherstellen, dass dein Hoster vor dem Go-live alle kritischen Werte geprüft hat.

Self-hosted (eigener Server, Root-Zugriff)

Du oder deine Agentur habt vollen Zugriff auf Server, Dateisystem und Konfigurationsdateien. Hier ist env-Konfiguration komplett in eurer Hand – und damit auch die Verantwortung. Deine Rolle: Klären, wer env-Variablen setzt, wie Deployments ablaufen und wie im Fehlerfall vorgegangen wird. Hier ist das Wissen aus diesem Artikel besonders wichtig.

Faustregel: Je mehr Kontrolle du hast, desto wichtiger ist es, env-Variablen zu verstehen. Bei Cloud ist das Thema „nice to know", bei Self-hosted ist es Pflicht. Wenn du dir unsicher bist, frag deine Agentur oder deinen Hoster: „Welches Hosting-Modell nutzen wir, und wer ist für env-Konfiguration verantwortlich?"

Die 3 Umgebungen: Dev, Staging, Prod – und warum jede andere Regeln braucht

In professionellen Shopware-Projekten gibt es typischerweise drei Umgebungen:

• Development (Dev): Die lokale Entwicklungsumgebung auf dem Rechner deines Entwicklers oder deiner Agentur. Hier wird Code geschrieben, getestet und debugged. In dieser Umgebung ist es okay (sogar erwünscht), dass Fehler ausführlich angezeigt werden, damit Probleme schnell gefunden werden.
• Staging: Eine Test-Umgebung, die der Produktionsumgebung möglichst ähnlich ist. Hier werden neue Features, Updates oder Änderungen getestet, bevor sie live gehen. Staging sollte produktionsähnlich konfiguriert sein (gleiche Serverstruktur, ähnliche Datenbank-Größe), aber es darf noch nicht öffentlich erreichbar sein.
• Production (Prod): Der Live-Shop, den deine Kunden sehen und nutzen. Hier zählt Stabilität, Performance und Sicherheit. Fehler dürfen nicht nach außen sichtbar sein, und jede Einstellung muss auf maximale Zuverlässigkeit optimiert sein.

Jede dieser Umgebungen braucht unterschiedliche env-Einstellungen. Beispiel: In Dev willst du detaillierte Fehlermeldungen sehen (APP_DEBUG=1), damit dein Entwickler schnell Bugs findet. In Prod wäre das ein Sicherheitsrisiko – Angreifer könnten durch die Fehlermeldungen interne Pfade, Datenbankstrukturen oder Serverdetails erkennen. Deshalb muss in Prod APP_DEBUG=0 sein.

Faustregel für dich als Entscheider: Dev darf und soll anders sein (Debug an, lokale Mail-Tools, vereinfachte Konfiguration). Staging und Prod müssen sich aber ähneln – mit dem Unterschied, dass Staging noch eine Testumgebung ist und Prod Live. Wenn deine Agentur sagt „Das funktioniert auf Staging, also wird es auch in Prod funktionieren", solltest du prüfen, ob die env-Einstellungen wirklich identisch sind. Oft liegt der Teufel im Detail: Staging nutzt noch einen Test-Mailserver, Prod den echten. Oder Staging hat noch alte Cache-Einstellungen, die in Prod anders sind.

Die 5 Must-have env-Variablen, die du als Nicht-Techniker kennen musst

Jetzt wird's konkret. Diese fünf Variablen sind in 90% aller Shopware-Projekte entscheidend – und als Projektleitung solltest du zumindest grob verstehen, was sie tun und wann sie falsch gesetzt sind.

1. APP_URL – Die Basis-Adresse deines Shops

APP_URL ist die vollständige URL, unter der dein Shop erreichbar ist. Shopware nutzt sie, um Links in E-Mails zu generieren, Sitemaps zu erstellen und interne Prüfungen durchzuführen (z.B. ob der Admin erreichbar ist). Wenn APP_URL falsch ist, passieren merkwürdige Dinge: Der Admin lädt nicht, E-Mails enthalten defekte Links, oder der Shop denkt, er läuft auf einer anderen Domain.

Beispiel Dev: APP_URL=http://localhost:8000

Beispiel Staging: APP_URL=https://staging.mein-shop.de

Beispiel Prod: APP_URL=https://www.mein-shop.de

Typischer Fehler: Nach dem Umzug von Staging auf Prod wurde APP_URL nicht angepasst. Der Shop läuft jetzt unter www.mein-shop.de, aber APP_URL steht noch auf staging.mein-shop.de. Resultat: Admin nicht erreichbar, Self-Check schlägt fehl, Mails verlinken auf Staging.

Was du prüfen solltest: Frag deine Agentur oder deinen Hoster vor dem Go-live: „Ist APP_URL exakt auf unsere Live-Domain gesetzt, inklusive https:// und www (falls ihr das nutzt)?"

2. APP_ENV und APP_DEBUG – Der Modus des Shops

APP_ENV bestimmt, in welchem Modus Shopware läuft: dev (Entwicklung) oder prod (Produktion). APP_DEBUG schaltet ausführliche Fehlermeldungen ein (1) oder aus (0).

Dev: APP_ENV=dev, APP_DEBUG=1 – Shopware zeigt alle Fehler detailliert an, Cache wird nicht aggressiv genutzt, Performance ist zweitrangig.

Staging/Prod: APP_ENV=prod, APP_DEBUG=0 – Shopware cached aggressiv, zeigt keine internen Fehler nach außen, Performance ist optimiert.

Typischer Fehler: Der Shop geht live, aber APP_DEBUG=1 ist noch gesetzt. Kunden sehen bei Fehlern Stack Traces, Datenbankabfragen und interne Pfade. Das ist nicht nur unprofessionell, sondern ein Sicherheitsrisiko.

Was du prüfen solltest: Frag vor dem Go-live: „Ist APP_DEBUG auf 0 gesetzt?" Falls deine Agentur sagt „Wir lassen es auf 1, um Probleme besser zu sehen", ist das ein Warnsignal. Debug gehört nicht in Prod.

3. MAILER_DSN – Wie dein Shop E-Mails versendet

MAILER_DSN konfiguriert den Mail-Versand. Shopware braucht einen SMTP-Server, um Bestellbestätigungen, Passwort-Reset-Mails oder Newsletter zu verschicken. Wenn MAILER_DSN falsch ist, gehen keine Mails raus – und das merkst du oft erst, wenn der erste Kunde sich beschwert.

Beispiel: MAILER_DSN=smtp://benutzername:passwort@smtp.example.com:587

Typischer Fehler: Auf Staging wurde ein Test-Mailserver genutzt (z.B. MailHog), der keine echten Mails verschickt. Beim Umzug auf Prod wurde vergessen, MAILER_DSN auf den echten SMTP-Server umzustellen. Resultat: Keine Bestellbestätigungen, keine Rechnungen, keine Passwort-Resets.

Was du prüfen solltest: Frag vor dem Go-live: „Haben wir eine Testmail aus der Prod-Umgebung verschickt? Ist sie angekommen?" Das ist der einfachste Test, um zu prüfen, ob MAILER_DSN korrekt gesetzt ist. Mach das selbst – verschick eine Testmail an deine eigene Adresse über den Admin-Bereich (Einstellungen → System → Mailer).

4. DATABASE_URL – Zugriff auf die Datenbank

DATABASE_URL sagt Shopware, wo die Datenbank liegt und wie darauf zugegriffen wird. Format: mysql://benutzer:passwort@host:port/datenbankname

Beispiel Dev: DATABASE_URL=mysql://root@127.0.0.1:3306/shopware_dev

Beispiel Prod: DATABASE_URL=mysql://shopuser:sicherespasswort@db-server.example.com:3306/shopware

Typischer Fehler: Nach dem Deployment wurde DATABASE_URL nicht angepasst, der Shop versucht weiterhin, auf die Dev- oder Staging-Datenbank zuzugreifen. Resultat: Fehlermeldungen, keine Produkte sichtbar, oder schlimmer: Prod-Shop zeigt Staging-Daten.

Was du prüfen solltest: Das übernimmt in der Regel dein Hoster oder deine Agentur. Aber frag nach: „Nutzt die Prod-Umgebung auch wirklich die Prod-Datenbank?" Klingt trivial, passiert aber öfter als du denkst.

5. OPENSEARCH_URL / ELASTICSEARCH_URL (falls genutzt)

Wenn dein Shop viele Produkte hat (ab ca. 5.000-10.000) oder komplexe Filter nutzt, wird oft Elasticsearch oder OpenSearch für die Suche eingesetzt. OPENSEARCH_URL (bzw. ELASTICSEARCH_URL) sagt Shopware, wo der Suchserver liegt.

Beispiel: OPENSEARCH_URL=http://localhost:9200 (Dev) oder OPENSEARCH_URL=http://es-cluster.example.com:9200 (Prod)

Typischer Fehler: Elasticsearch läuft in Staging, aber in Prod wurde es nicht eingerichtet – oder die URL ist falsch. Resultat: Produktsuche ist extrem langsam oder funktioniert gar nicht.

Was du prüfen solltest: Frag: „Nutzen wir Elasticsearch/OpenSearch? Wenn ja, ist es in Prod korrekt konfiguriert und läuft es?" Lass dir zeigen, dass eine Produktsuche auf Prod schnell und korrekt funktioniert.

Typische Fehlerbilder und wie du sie erkennst (ohne ins Terminal zu müssen)

Als Nicht-Entwickler wirst du wahrscheinlich nicht selbst in Logdateien graben. Aber du kannst Symptome erkennen und die richtigen Fragen stellen. Hier sind die häufigsten Probleme und ihre Erkennungsmerkmale:

„Shopware 6 network error" im Admin

Symptom: Du versuchst, dich im Admin einzuloggen oder eine Seite zu öffnen, und siehst „Network Error" oder eine endlose Ladeanimation.

Häufigste Ursache: APP_URL ist falsch gesetzt. Shopware versucht, sich selbst über diese URL zu erreichen (Self-Check), und scheitert.

Was du tun kannst: Öffne die Browser-Entwicklertools (F12 in Chrome/Firefox), geh auf den „Network"-Tab und lade die Seite neu. Schau dir die fehlgeschlagenen Requests an: Welche URL wird aufgerufen? Stimmt sie mit der echten Shop-URL überein? Wenn nicht, ist APP_URL falsch. Leite diese Info an deine Agentur weiter.

Keine E-Mails kommen an

Symptom: Kunden beschweren sich, dass sie keine Bestellbestätigungen bekommen. Du selbst bekommst keine Test-Mails.

Häufigste Ursache: MAILER_DSN ist falsch oder wurde nicht von Staging auf Prod angepasst.

Was du tun kannst: Geh in den Admin unter „Einstellungen → System → Mailer" und verschicke eine Testmail an deine eigene Adresse. Kommt sie an? Wenn nein, prüfe im Spam-Ordner. Wenn auch dort nichts ist, ist MAILER_DSN falsch konfiguriert. Kontaktiere deine Agentur oder deinen Hoster mit der Info: „Testmail aus Admin kommt nicht an."

Produktsuche oder Kategorieseiten sind sehr langsam

Symptom: Kategorieseiten mit vielen Produkten oder die Suchfunktion laden extrem langsam (mehrere Sekunden oder Timeouts).

Häufigste Ursache: Elasticsearch/OpenSearch ist nicht korrekt konfiguriert oder läuft nicht. Shopware fällt auf die MySQL-Datenbank zurück, die für solche Abfragen nicht optimiert ist.

Was du tun kannst: Frag deine Agentur: „Läuft Elasticsearch/OpenSearch? Wurde nach dem Deployment die Produktindexierung durchgeführt?" Ein einfacher Test: Geh auf eine Kategorieseite mit vielen Produkten oder nutze die Suche. Lädt sie schnell (unter 1 Sekunde)? Wenn nein, stimmt etwas mit der Suchkonfiguration nicht. Für tiefergehende Hintergründe zur Einrichtung lohnt sich auch der Beitrag zu Elasticsearch in Shopware 6.

Cache-Probleme nach Deployment

Symptom: Nach einem Deployment zeigt der Shop alte Inhalte, veraltete Preise oder Produkte, die eigentlich gelöscht wurden. Oder: Der Shop wirft plötzlich Fehler, die vorher nicht da waren.

Häufigste Ursache: Der Cache wurde nach dem Deployment nicht geleert.

Was du tun kannst: Frag deine Agentur: „Wurde nach dem Deployment der Cache geleert?" Das sollte Standard sein. Falls das Problem weiterhin besteht, bitte um ein komplettes Cache-Clearing. In der Regel übernimmt deine Agentur das technisch – du musst nur wissen, dass es nötig ist und danach fragen.

Go-live Checkliste: Die 8 Punkte, die du vor jedem Launch abhaken solltest

Hier ist deine praxisnahe Checkliste. Geh sie mit deiner Agentur oder deinem Hoster durch, bevor der Shop live geht. Du musst nicht jedes Detail selbst verstehen – aber du musst sicherstellen, dass jemand diese Punkte geprüft hat.

1. APP_URL korrekt gesetzt? Stimmt die URL exakt mit der Live-Domain überein (inklusive https://, www falls genutzt, Port falls abweichend)? Test: Admin-Login funktioniert ohne „Network Error".
2. APP_ENV=prod und APP_DEBUG=0? Keine Debug-Meldungen nach außen sichtbar. Test: Rufe eine nicht existierende Seite auf (z.B. /test123) – es sollte nur eine generische 404-Seite kommen, keine detaillierte Fehlermeldung.
3. MAILER_DSN auf echten SMTP-Server gesetzt? Testmail aus Admin verschickt und erfolgreich empfangen (auch im Posteingang gelandet, nicht nur Spam).
4. Datenbank korrekt? Prod-Shop nutzt Prod-Datenbank, nicht Staging oder Dev. Test: Produkte, Bestellungen, Kunden stimmen mit erwartetem Stand überein.
5. Elasticsearch/OpenSearch (falls genutzt) läuft? Produktsuche und Kategorieseiten laden schnell. Test: Komplexe Suche mit Filtern durchführen – Antwortzeit unter 1 Sekunde.
6. Cache geleert? Nach Deployment wurde der Cache von deiner Agentur geleert. Test: Storefront lädt flüssig, keine merkwürdigen Darstellungsfehler.
7. SSL-Zertifikat gültig? Shop ist per https:// erreichbar, Browser zeigt grünes Schloss. Test: Rufe Shop-URL auf und prüfe Zertifikat. Wenn du dabei auch Shopware mit HTTPS sauber aufgesetzt hast, vermeidest du gemischte Inhalte und Weiterleitungschaos.
8. Checkout-Test durchgeführt? Komplette Testbestellung von der Produktauswahl bis zur Bestellbestätigung durchgespielt. Test: Bestellbestätigungs-Mail kommt an, Bestellung erscheint im Admin, Zahlungs- und Versandmethoden funktionieren.

Was env-Konfiguration löst – und was nicht (realistische Erwartungen)

Es ist wichtig zu verstehen: Korrekte env-Variablen sind notwendig, aber nicht hinreichend für einen erfolgreichen Go-live. Selbst wenn alle env-Einstellungen perfekt sind, können andere Probleme auftreten.

Was env-Konfiguration löst:

• Shop erreicht die richtige Datenbank und kann Daten lesen/schreiben
• E-Mails werden korrekt verschickt
• Admin ist erreichbar und funktioniert
• Produktsuche nutzt die richtige Suchmaschine (Elasticsearch/OpenSearch)
• Performance ist optimiert (Caching, Prod-Modus)
• Keine internen Fehlerdetails werden nach außen sichtbar

Was env-Konfiguration NICHT löst:

• Plugin-Kompatibilität (ein Plugin kann trotz korrekter env-Konfiguration Fehler werfen)
• Theme-Probleme (CSS/JS-Fehler, defekte Layouts)
• Zahlungs-/Versanddienstleister-Integration (API-Keys, Webhooks müssen separat konfiguriert werden)
• DNS-Probleme (Domain zeigt auf falschen Server)
• Server-Ressourcen (zu wenig RAM/CPU, falsche PHP-Version)
• Inhalts- oder Datenqualität (fehlende Produktbilder, defekte Kategorien)

Praxistipp: Behandle env-Konfiguration als Teil eines größeren Go-live-Checks. Eine vollständige Checkliste umfasst: env-Variablen, Plugin-Tests, Theme-Tests, Zahlungs-/Versandtests, Performance-Tests, SEO-Checks (Redirects, Robots.txt, Sitemap) und Content-Prüfung. Env ist ein kritischer Baustein – aber eben nur einer von vielen.

Wann brauchst du fortgeschrittene Konfiguration (Redis, Elasticsearch, etc.) – und was sie kostet

Nicht jeder Shop braucht jede Technologie. Als Nicht-Techniker ist es wichtig zu verstehen, wann zusätzliche Infrastruktur nötig ist – und wann sie nur Komplexität (und Kosten) ohne echten Nutzen bringt. Hier eine grobe Orientierung:

Redis (Caching/Sessions)

Wann nötig: Wenn du mehrere App-Server hast (Load Balancing/Cluster) oder einen sehr großen Shop mit hoher Last (mehrere tausend Besucher gleichzeitig). Redis ist ein In-Memory-Cache, der schneller ist als Filesystem-Cache und sich über mehrere Server teilen lässt.

Wann nicht nötig: Kleine bis mittlere Shops (bis ca. 10.000 Besucher/Tag) auf einem einzelnen Server kommen gut mit Filesystem-Cache aus.

Kosten/Aufwand: Redis als Managed Service (z.B. AWS ElastiCache, Hetzner Cloud Redis) kostet ca. 10-50 €/Monat. Self-hosted auf deinem Server: kein direkter Kostenfaktor, aber mehr Konfiguration und Monitoring nötig.

Entscheidungshilfe: Frag deine Agentur: „Haben wir Load Balancing oder mehrere App-Server?" Falls nein, brauchst du wahrscheinlich kein Redis. Falls ja, ist Redis sinnvoll oder sogar notwendig – und mit einer soliden Redis-Konfiguration für Shopware vermeidest du Session- und Cache-Probleme.

Elasticsearch / OpenSearch (Produktsuche)

Wann nötig: Ab ca. 5.000-10.000 Produkten oder wenn du viele Filter nutzt (Farbe, Größe, Marke, Preisspannen etc.). MySQL ist für komplexe Produktsuchen nicht optimiert und wird bei vielen Produkten langsam.

Wann nicht nötig: Kleine Shops mit wenigen hundert oder tausend Produkten und einfachen Filtern kommen mit MySQL-Suche aus.

Kosten/Aufwand: Elasticsearch/OpenSearch als Managed Service (z.B. AWS OpenSearch, Elastic Cloud) kostet ab ca. 50-150 €/Monat (abhängig von Datenmenge und Traffic). Self-hosted: Server-Ressourcen (min. 2-4 GB RAM zusätzlich), regelmäßiges Monitoring und Wartung nötig.

Entscheidungshilfe: Frag deine Agentur: „Wie viele Produkte haben wir? Wie komplex sind unsere Filter?" Wenn ihr unter 5.000 Produkte habt und nur 2-3 einfache Filter, könnt ihr Elasticsearch vorerst weglassen. Falls ihr später wachst, kann ES nachträglich ergänzt werden.

Hintergrund-Jobs / Message Queue

Wann nötig: Wenn dein Shop viele zeitintensive Hintergrund-Jobs hat (z.B. Newsletter an tausende Empfänger, komplexe Datenimporte, automatische Thumbnails-Generierung). Shopware nutzt Symfony Messenger – deine Agentur richtet Worker-Prozesse ein, die Jobs asynchron abarbeiten.

Wann nicht nötig: Kleine Shops mit wenig Hintergrund-Aktivität (z.B. nur gelegentliche Newsletter, keine großen Imports) kommen auch ohne dedizierte Worker aus.

Kosten/Aufwand: Keine direkten Kosten, aber deine Agentur/Hoster muss Worker-Prozesse einrichten und überwachen. Das ist Teil der laufenden Wartung.

Entscheidungshilfe: Frag: „Haben wir regelmäßig lange laufende Jobs (Newsletter, Importe, komplexe Indexierungen)?" Falls ja, sollten Worker laufen. Falls nein, ist es optional. Deine Agentur übernimmt die technische Umsetzung – du musst nur wissen, dass es nötig ist.

Welche Fragen du deiner Agentur/deinem Hoster stellen solltest

Wenn du mit einer Agentur oder einem Hosting-Partner arbeitest, ist es wichtig, Verantwortlichkeiten frühzeitig zu klären. Hier sind die Fragen, die du vor dem Projekt und spätestens vor dem Go-live stellen solltest:

Vor Projektstart

• Welches Hosting-Modell nutzen wir? (Shopware Cloud, Managed Hosting, Self-Hosted?) Daraus ergibt sich, wer für env-Variablen, Server-Konfiguration und Betrieb zuständig ist.
• Wer setzt die Umgebungsvariablen? Werden sie direkt auf dem Server gesetzt, über ein Hosting-Panel oder via CI/CD-Pipeline?
• Wer ist für Mail-Konfiguration zuständig? Müssen wir selbst SMTP-Zugänge besorgen, oder stellt der Hoster das? Wer kümmert sich um SPF/DKIM, damit Mails nicht im Spam landen?
• Nutzen wir Elasticsearch/OpenSearch? Wenn ja: Wer richtet es ein, wer überwacht es? Ab welcher Shop-Größe ist es nötig? Was kostet es zusätzlich?
• Wie läuft das Deployment ab? Manuell per FTP, per Git, oder automatisiert via CI/CD? Wer führt es aus, und gibt es eine Rollback-Strategie?

Vor Go-live

• Ist APP_URL auf die finale Live-Domain gesetzt? Wurde der Self-Check im Admin erfolgreich durchgeführt?
• Ist APP_DEBUG=0 und APP_ENV=prod? Keine Debug-Infos nach außen sichtbar?
• Wurde eine Testmail aus der Prod-Umgebung verschickt? Ist sie angekommen (auch nicht im Spam)?
• Wurde eine komplette Testbestellung durchgeführt? Von der Produktauswahl bis zur Bestellbestätigung?
• Wurde der Cache nach dem finalen Deployment geleert? (Deine Agentur macht das – du fragst nur nach, ob es passiert ist.)
• Gibt es ein Monitoring/Alerting? Wer wird benachrichtigt, wenn der Shop down ist, Mails nicht rausgehen oder Elasticsearch ausfällt?
• Gibt es eine Rollback-Strategie? Was passiert, wenn nach dem Go-live ein kritischer Fehler auftritt? Kann schnell zur letzten funktionierenden Version zurückgekehrt werden?

Zusammenfassung: Was du heute umsetzen solltest

Shopware env-Variablen sind das Fundament jeder stabilen Shop-Installation. Als Entscheider oder Projektleitung musst du kein DevOps-Experte sein, aber du solltest die Basics kennen und die richtigen Fragen stellen können. Hier sind die vier wichtigsten Takeaways:

1. Kenne die 5 kritischen env-Variablen: APP_URL, APP_ENV, APP_DEBUG, MAILER_DSN, DATABASE_URL (und ggf. OPENSEARCH_URL). Wenn diese falsch sind, funktioniert der Shop nicht korrekt – egal wie gut der Code ist.
2. Nutze die Go-live-Checkliste: Geh vor jedem Launch die 8 Punkte durch. Lass dir von deiner Agentur bestätigen, dass jeder Punkt geprüft wurde. Das dauert 10 Minuten und kann dir stundenlange Troubleshooting-Sessions ersparen.
3. Verstehe, was env-Konfiguration löst – und was nicht: Env ist kritisch für Grundfunktionen (DB, Mail, URL), löst aber nicht Plugin-, Theme-, Zahlungs- oder DNS-Probleme. Behandle es als Teil eines größeren Go-live-Checks.
4. Kläre Verantwortlichkeiten und Kosten frühzeitig: Wer setzt env-Variablen? Wer testet Mail-Versand? Wer kümmert sich um Elasticsearch? Was kostet zusätzliche Infrastruktur (Redis, OpenSearch)? Diese Fragen vor Projektstart zu klären, verhindert Missverständnisse und Verzögerungen beim Go-live.

Wenn du diese vier Dinge umsetzt, hast du die häufigsten Go-live-Probleme bereits im Griff. Shopware env ist kein Hexenwerk – es sind einfach die richtigen Einstellungen zur richtigen Zeit. Und mit den richtigen Fragen stellst du sicher, dass dein Shop vom ersten Tag an stabil läuft.

Viel Erfolg beim nächsten Launch!