Shopware 6 lässt sich auf Ubuntu zuverlässig betreiben, wenn der Server vor der Installation sauber vorbereitet wird. Entscheidend sind nicht einzelne Installationsbefehle, sondern die richtige Reihenfolge: Domain und Serverzugang absichern, Webserver mit PHP-FPM und Datenbank einrichten, das Webroot auf das Verzeichnis public setzen, Shopware über einen klar gewählten Installationsweg bereitstellen und danach Rechte sowie Hintergrundprozesse prüfen. Welche PHP- und Datenbankversionen zulässig sind, hängt von der eingesetzten Shopware-Version ab. Diese Anforderungen solltest du deshalb unmittelbar vor dem Setup in der offiziellen Dokumentation der Zielversion abgleichen.
Für ein klassisches Shopware-Ubuntu-Setup ist Nginx oder Apache mit PHP-FPM eine übliche Grundlage. Hinzu kommen MariaDB oder MySQL, eine eigene Datenbank samt separatem Benutzer und eine Domain, die bereits auf den Server zeigt. Wer diese Bausteine trennt und nachvollziehbar dokumentiert, reduziert typische Probleme bei Installation, Updates und späterem Betrieb deutlich.
Bevor du Shopware auf Ubuntu installierst, sollte der Server als Betriebsumgebung grundsätzlich stehen. Das verhindert, dass eine an sich funktionierende Installation später durch DNS-Probleme, fehlende Schreibrechte oder unklare Verantwortlichkeiten ausgebremst wird.
Eine feste Liste von Paket- oder Versionsnummern wäre an dieser Stelle irreführend: Ubuntu-Releases, PHP-Versionen und Shopware-Releases entwickeln sich unabhängig voneinander weiter. Prüfe daher vorab, ob die gewünschte Shopware-Version die auf dem Server verfügbare PHP-Version unterstützt und ob benötigte PHP-Erweiterungen vorhanden sind. Das gilt besonders bei bestehenden Servern, auf denen bereits andere Anwendungen laufen.
Auch aus E-Commerce-Sicht lohnt sich diese Vorprüfung. Die technische Installation ist nur ein Baustein der späteren Shop-Architektur. Anforderungen an Schnittstellen, B2B-Logiken, individuelle Preise, Produktdaten oder Tracking sollten möglichst vor dem Setup feststehen. Ein strukturierter Shopware-Check hilft dabei, technische Abhängigkeiten nicht erst während der Umsetzung zu entdecken.
Die technische Basis besteht aus drei getrennten Verantwortungsbereichen: Der Webserver nimmt HTTP-Anfragen an, PHP-FPM führt den Anwendungscode aus und die Datenbank speichert Shopdaten. Diese Trennung erleichtert die Fehlersuche. Liefert der Webserver einen Fehler, ist nicht automatisch die Datenbank schuld; scheitert eine Datenbankverbindung, liegen die Ursachen meist nicht im Routing.
Shopware kann mit Nginx oder Apache betrieben werden. Entscheidend ist nicht die pauschale Wahl eines vermeintlich schnelleren Webservers, sondern eine saubere Konfiguration, die zum Know-how des Teams und zum Hosting passt. Nginx wird oft mit PHP-FPM kombiniert. Apache kann ebenfalls geeignet sein, wenn das bestehende Umfeld darauf ausgelegt ist. Die Konfigurationslogik bleibt gleich: Nur das öffentliche Verzeichnis darf aus dem Internet erreichbar sein, dynamische Aufrufe müssen an PHP weitergereicht werden und nicht vorhandene Shop-Routen müssen bei der Anwendung landen.
Lege für die Shopware-Installation eine eigene Datenbank und einen separaten Datenbankbenutzer an. Verwende nicht das administrative Datenbankkonto für den laufenden Shopbetrieb. Der Benutzer benötigt nur die Berechtigungen, die für diese Datenbank erforderlich sind. Sichere Zugangsdaten gehören nicht in frei zugängliche Dateien, Chatverläufe oder Deployment-Skripte ohne Zugriffsschutz.
Vor dem Start sollte klar sein, wie Datenbank-Backups erstellt und wiederhergestellt werden. Ein Backup ist erst dann belastbar, wenn die Wiederherstellung zumindest in einer geeigneten Testumgebung geprüft wurde. Gerade vor Updates, Erweiterungsinstallationen oder Datenimporten ist ein nachvollziehbarer Rückweg wichtiger als eine rein vorhandene Sicherungsdatei.
PHP-FPM muss mit der Shopware-Version kompatibel sein. Prüfe außerdem die benötigten Erweiterungen anhand der aktuellen Systemanforderungen. Bei den PHP-Limits sind vor allem Arbeitsspeicher, Upload-Größe, maximale Größe von POST-Anfragen und Ausführungszeit relevant. Zu niedrige Werte fallen häufig erst beim Medienimport, bei größeren Datenübertragungen oder während der Installation auf.
Es gibt keine pauschal seriöse Zahl, die für jeden Shop passt. Die richtigen Werte hängen unter anderem von Kataloggröße, Bilddateien, Importen, Erweiterungen und verfügbaren Serverressourcen ab. Passe die Limits bewusst an, dokumentiere die Änderung und stelle sicher, dass die verwendete PHP-FPM-Konfiguration tatsächlich aktiv ist. Eine bearbeitete, aber nicht genutzte Konfigurationsdatei löst kein Problem.
Der zentrale Punkt bei Shopware auf Ubuntu ist das Webroot: Die Domain darf nicht auf das Projektverzeichnis insgesamt zeigen, sondern auf dessen Verzeichnis public. Dort liegen die Dateien, die der Webserver öffentlich ausliefern darf. Konfigurationsdateien, Abhängigkeiten und weitere interne Projektbestandteile bleiben dadurch außerhalb des direkt erreichbaren Webbereichs.
Bei Nginx wird das im Virtual Host als Root-Verzeichnis der Domain hinterlegt. Zusätzlich benötigt die Konfiguration eine Routing-Regel: Existiert eine angeforderte Datei nicht direkt, muss die Anfrage an den zentralen Einstiegspunkt der Anwendung weitergereicht werden. Sonst funktionieren häufig Startseite oder einzelne statische Dateien, während Kategorien, Produktseiten, Suchseiten oder andere sprechende URLs mit einem Fehler enden.
Für Apache gilt dieselbe fachliche Anforderung. Das Dokumentenverzeichnis muss auf public zeigen, und die Umschreibungslogik muss zur Anwendung passen. Eine Konfiguration, die versehentlich auf das übergeordnete Shopware-Verzeichnis zeigt, ist kein akzeptabler Ersatz. Sie kann interne Dateien offenlegen oder zu schwer nachvollziehbaren Fehlerbildern führen.
Prüfe nach jeder Anpassung die Konfiguration des Webservers, bevor du ihn neu lädst oder neu startest. Anschließend kontrollierst du, ob die Domain tatsächlich den gewünschten Virtual Host erreicht. Bei mehreren Projekten auf einem Server ist ein falscher Server-Block beziehungsweise Virtual Host eine häufige Ursache dafür, dass plötzlich eine andere Website oder eine Standardseite erscheint.
Für die Bereitstellung von Shopware gibt es grundsätzlich zwei voneinander getrennte Wege: eine Installation über Composer mit einem Production-Projekt und eine Installation über einen bereitgestellten Installer beziehungsweise ein ZIP-Archiv. Beide Ansätze können sinnvoll sein. Wichtig ist, sie nicht innerhalb eines Projekts zu vermischen.
| Kriterium | Composer / Production-Projekt | Installer / ZIP-Variante |
|---|---|---|
| Passend für | Kontrollierte Server- und Deployment-Prozesse | Überschaubare Erstinstallation mit klarer manueller Bereitstellung |
| Abhängigkeiten | Werden über Composer verwaltet | Werden mit dem bereitgestellten Paket ausgeliefert |
| Wartung | Erfordert ein sauberes Verständnis des Composer- und Update-Prozesses | Erfordert einen ebenso klaren Prozess für Updates und Dateiaustausch |
| Wichtigster Hinweis | Versionsvorgaben und Produktionsablauf vorher festlegen | Archiv vollständig und in die vorgesehene Struktur entpacken |
Composer passt gut zu professionell organisierten Umgebungen, in denen Abhängigkeiten, Versionen und Deployments nachvollziehbar verwaltet werden sollen. Das ist besonders sinnvoll, wenn Entwicklung, Test und Produktion getrennt sind oder mehrere Personen am Projekt arbeiten. Voraussetzung ist allerdings, dass der Prozess nicht nur für die Erstinstallation, sondern auch für spätere Updates verstanden und dokumentiert ist.
Installiere das Projekt in einem vorgesehenen Verzeichnis außerhalb des direkt öffentlichen Webroots. Danach wird der Webserver explizit auf den darin liegenden öffentlichen Ordner ausgerichtet. Die eigentliche Shopware-Einrichtung erfolgt anschließend über den Installationsassistenten im Browser, der Datenbankzugang und Grundkonfiguration abfragt.
Die Installer-Variante kann für eine klar abgegrenzte Erstinstallation geeignet sein, wenn kein Composer-basierter Deployment-Prozess vorgesehen ist. Lade das Paket ausschließlich aus einer vertrauenswürdigen Quelle, entpacke es vollständig in das geplante Projektverzeichnis und prüfe die Eigentümerschaft sowie Schreibrechte, bevor du die Domain aufrufst.
Entscheide dich nicht nur nach dem vermeintlich schnelleren Start. Für den späteren Betrieb ist entscheidend, ob dein Team oder Dienstleister Updates, Erweiterungen, Backups und Fehleranalyse mit dem gewählten Weg zuverlässig beherrscht. Die Eigenschaften von Shopware sind dabei nur dann ein Vorteil, wenn Architektur und Betriebsprozess die Anforderungen des Geschäftsmodells tragen.
In klassischen Ubuntu-Setups läuft der Webserver-Prozess häufig unter dem Benutzer www-data. Dieser Prozess benötigt Zugriff auf die Shopdateien und Schreibrechte in den Bereichen, die Shopware zur Laufzeit beschreiben muss, etwa für Cache, generierte Dateien, Medien oder temporäre Daten. Welche Verzeichnisse im Detail betroffen sind, kann je nach Shopware-Version und Betriebsweise variieren.
Der sichere Grundsatz lautet: Gib dem Webserver nicht pauschal Schreibrechte auf das gesamte Projekt. Setze Eigentümer und Rechte so restriktiv wie möglich, aber so großzügig wie nötig. Besonders sensible Konfigurationsdateien und Zugangsdaten sollten nicht allgemein beschreibbar sein. Nach Änderungen an Eigentümer- oder Gruppenrechten ist ein Test im Browser nötig, denn scheinbar korrekte Dateirechte können durch übergeordnete Verzeichnisse oder abweichende Prozessbenutzer wirkungslos werden.
Ein sinnvoller Abschluss der Erstinstallation besteht aus mehreren Prüfpunkten:
Ein häufiger Sonderfall: Der Installationsassistent startet, bricht aber bei einem späteren Schritt ab. Dann ist das Projekt nicht automatisch defekt. Prüfe zuerst Datenbankzugang, PHP-Umgebung und Schreibrechte, bevor du Dateien erneut kopierst oder die Installation mehrfach startest. Wiederholte Teilinstallationen ohne saubere Analyse können Datenbankzustände und Konfiguration unnötig verkomplizieren.
Mit einer erreichbaren Storefront ist die technische Arbeit nicht abgeschlossen. Shopware verarbeitet je nach Funktion Aufgaben im Hintergrund, etwa Nachrichten aus Warteschlangen oder geplante Aufgaben. Diese Prozesse sollten im produktiven Betrieb nicht dauerhaft von einem geöffneten Browserfenster oder manuellen Aufrufen abhängen. Plane deshalb einen überwachten Hintergrundprozess ein, beispielsweise über einen passenden Systemdienst oder ein anderes zum Hosting passendes Prozessmanagement.
Wie Worker und geplante Aufgaben konkret eingerichtet werden, ist versions- und umgebungsabhängig. Entscheidend ist die Betriebslogik: Der Prozess muss nach Serverneustarts wieder anlaufen, Fehler sollten in Logs sichtbar sein und es braucht eine klare Zuständigkeit für Kontrolle und Wartung. Teste dabei nicht nur, ob ein Dienst startet, sondern ob Aufgaben tatsächlich abgearbeitet werden.
HTTPS gehört ebenfalls in die unmittelbare Nachbereitung. Richte ein gültiges TLS-Zertifikat ein und sorge für eine konsistente Weiterleitung auf die verschlüsselte Variante der Domain. Die konkrete Einrichtung, etwa mit einem Zertifikatsdienst, hängt von Webserver, Hosting und DNS-Situation ab und sollte nach aktueller Primärdokumentation erfolgen.
Für den laufenden Betrieb sind zudem regelmäßige Sicherheitsupdates des Servers, Shopware-Updates nach vorherigem Test, Datenbank- und Dateisicherungen sowie ein Blick in die Anwendungs- und Serverlogs sinnvoll. Bei umfangreicheren Shopprojekten sollte das als wiederholbarer Prozess dokumentiert sein, nicht als Erinnerung im Kalender einzelner Personen. Technische Umsetzung, SEO-Anforderungen und Datenqualität greifen dabei ineinander; bei komplexeren Vorhaben kann eine Shopware-Agentur helfen, Verantwortlichkeiten und technische Anforderungen sauber zu verbinden.
Bei Problemen mit Shopware auf Ubuntu ist eine feste Prüf-Reihenfolge effizienter als das gleichzeitige Ändern mehrerer Einstellungen. Beginne immer mit dem Fehlerbild: Ist die Domain nicht erreichbar, liefert der Webserver einen Fehler, scheitert PHP oder verweigert die Anwendung den Datenbankzugriff?
| Fehlerbild | Wahrscheinliche Ursache | Sinnvolle erste Prüfung |
|---|---|---|
| Installationsseite erscheint nicht | DNS, Firewall oder falscher Virtual Host | Domainauflösung, Webserver-Konfiguration und aktives Webroot prüfen |
| Fehler bei Kategorien oder Produkt-URLs | Fehlender Fallback auf den Anwendungseinstiegspunkt | Routing-Regel und Root-Verzeichnis kontrollieren |
| Datei- oder Cache-Fehler | Unpassende Eigentümerschaft oder fehlende Schreibrechte | Prozessbenutzer, Gruppenrechte und betroffene Verzeichnisse prüfen |
| Abbruch bei Upload oder Import | PHP-Limits oder Zeitüberschreitungen | Aktive PHP-FPM-Konfiguration und Serverlogs abgleichen |
| Datenbankfehler | Falsche Zugangsdaten, Berechtigungen oder nicht erreichbarer Dienst | Verbindungsdaten, Datenbankbenutzer und Dienststatus kontrollieren |
Logs sind dabei keine letzte Notlösung, sondern die wichtigste Informationsquelle. Prüfe sowohl die Fehlerausgaben des Webservers und von PHP-FPM als auch die Protokolle der Anwendung. Achte auf Zeitstempel: Ein älterer Eintrag erklärt nicht zwingend den gerade ausgelösten Fehler. Wenn du Konfigurationen änderst, dokumentiere kurz, was verändert wurde. So lässt sich nachvollziehen, welche Anpassung ein Problem behoben oder verursacht hat.
Der iOnCube Loader ist für ein modernes Shopware-Setup nicht pauschal als Voraussetzung anzunehmen. Hinweise auf ältere PHP- oder iOnCube-Konstellationen solltest du nicht unkritisch auf eine aktuelle Shopware-Installation übertragen. Installiere zusätzliche PHP-Erweiterungen nur, wenn sie für deine konkrete Shopware-Version, eine benötigte Erweiterung oder ein anderes eindeutig geprüftes Abhängigkeitsszenario erforderlich sind.
Docker kann eine Alternative für standardisierte Entwicklungs- oder Deployment-Umgebungen sein. Es löst jedoch nicht automatisch Fragen zu Datenbank, Backups, TLS, Berechtigungen oder Hintergrundprozessen. Für eine klassische Installation auf einem Ubuntu-Server ist es sinnvoller, zunächst die beschriebene Serverbasis eindeutig zu beherrschen.
Ein gut eingerichtetes Shopware-System auf Ubuntu zeichnet sich am Ende nicht nur dadurch aus, dass die Installation im Browser durchläuft. Entscheidend ist ein nachvollziehbarer Betrieb: abgesicherter Zugriff, korrektes öffentliches Verzeichnis, getrennte Datenbankzugänge, funktionierende Hintergrundprozesse und ein getesteter Backup- sowie Update-Prozess.