Laravel E-Commerce: Architektur, Pakete und Auswahlkriterien

Für die meisten Entwickler und mittelgroße B2B-Shops ist ein headless Laravel-Paket mit maßgeschneiderten Modulen die beste Balance aus Time-to-Market, Anpassbarkeit und langfristiger Wartbarkeit. Laravel bietet durch sein Paket-Ökosystem — darunter Cashier für Abonnements und Scout für Volltextsuche — eine Grundlage, die kein generisches Shop-System von der Stange erreicht.

Als nächsten Schritt empfiehlt sich ein Proof-of-Concept: Composer installieren, das bevorzugte Paket einbinden und den Checkout-Flow mit echten Testdaten durchspielen. Wer eine Agentur einbinden möchte, sollte konkrete Architektur- und Integrationsfragen vorbereiten — dazu mehr weiter unten.

Wichtige Erkenntnisse

Für die meisten B2B-Laravel-Shops ist ein headless Paket als Backend-Core mit maßgeschneiderten Modulen für Geschäftslogik die wartungsärmste und flexibelste Architektur.

Thema	Details
Paketauswahl nach Use Case	Bagisto für MVPs und Marktplätze, Lunar für headless Storefronts, Aimeos für große B2B-Kataloge.
Architekturentscheidung früh treffen	Headless oder Monolith bestimmt Team-Setup, Deployment und Skalierungsstrategie für Jahre.
POC vor Vollimplementierung	Checkout, Produktimport und Suchindex im POC validieren — spart Kosten und deckt Risiken früh auf.
SEO und Migration sorgfältig planen	URL-Mapping, 301-Weiterleitungen und Core Web Vitals vor Go-live sicherstellen.
Outwork als Umsetzungspartner	Outwork begleitet Laravel-E-Commerce-Projekte von Discovery bis Betrieb — mit definierten SLAs und Knowledge-Transfer.

Inhaltsverzeichnis

Welches Laravel-E-Commerce-Paket passt zu welchem Projekt?
Was liefert jedes Paket technisch?
Headless oder Monolith? Architektur, Skalierung und Suche
Welche Integrationen und welches Hosting braucht ein Laravel-Shop?
Wie wählen Sie die richtige Lösung?
Migration, Proof of Concept und SEO-Erhalt
Wie Outwork Laravel-E-Commerce-Projekte umsetzt
Was wirklich zählt bei der Paketauswahl
Outwork begleitet Ihr Laravel-E-Commerce-Projekt
Quellen

Welches Laravel-E-Commerce-Paket passt zu welchem Projekt?

Die drei meistgenutzten Pakete für E-Commerce mit Laravel sind Aimeos, Lunar und Bagisto. Alle drei sind Open Source, per Composer installierbar und aktiv gepflegt — aber sie lösen unterschiedliche Probleme.

Kriterium	Aimeos	Lunar	Bagisto
Bestes für	Performance-kritische B2B-Kataloge, große Produktmengen	Headless-Storefronts, developer-first APIs	Marktplätze, schnelle MVPs mit Vue.js-Frontend
Architektur	Monolith + API-Option	Headless / API-first	Monolith mit Vue.js-Frontend
Out-of-the-box	Produktvarianten, Multi-Channel, Preisregeln, Admin	Backend, Admin-Panel, Warenkorb, Checkout-API	Produktkatalog, Checkout, Marktplatz-Modul, Admin
Skalierbarkeit	Hoch (optimiert für große Kataloge)	Hoch (stateless API, beliebiges Frontend)	Mittel bis hoch
Integrationen	Stripe, PayPal, ERP via API	Stripe, eigene Payment-Adapter	Stripe, PayPal, Versand-APIs
Komplexität	Mittel bis hoch	Mittel (Frontend selbst bauen)	Niedrig bis mittel
Lizenz	MIT	MIT	MIT

Aimeos eignet sich gut für Shops mit Tausenden von Produktvarianten und komplexen Preisregeln. Lunar ist die erste Wahl, wenn das Frontend-Team React oder Next.js bevorzugt und das Backend sauber getrennt bleiben soll. Bagisto bringt das meiste von Haus aus mit — inklusive Marktplatz-Logik — und ist damit der schnellste Weg zu einem funktionierenden Shop.

Alle drei Pakete sind auf Packagist verfügbar, haben aktive GitHub-Repositories und regelmäßige Releases. Das Lunar-Repository auf GitHub zeigt offene Issues, aktive Pull Requests und eine wachsende Community. Aimeos und Bagisto haben beide Nutzerrezensionen auf Capterra, was auf reale Produktivnutzung hinweist.

Was liefert jedes Paket technisch?

Aimeos

Aimeos ist auf Performance ausgelegt. Der Produktkatalog unterstützt Varianten, Bundles, digitale Güter und komplexe Attributstrukturen. Das Admin-Panel ist vollständig, die API-Schicht erlaubt auch headless Betrieb.

Produktvarianten, Bundles, digitale Produkte
Multi-Channel und Multi-Shop aus einer Installation
Flexible Preisregeln (Kundengruppen, Mengenrabatte, Zeitfenster)
Vollständiger Checkout-Workflow inkl. Steuerberechnung
REST-API für headless Szenarien

Installation per Composer:

composer require aimeos/aimeos-laravel
php artisan aimeos:setup

Realistischer Time-to-Market für einen einfachen Shop liegt im Bereich von mehreren Wochen. Für komplexe B2B-Setups mit ERP-Anbindung ist ein Zeitraum von mehreren Monaten angemessen.

Lunar

Lunar liefert Backend und Admin, aber kein fertiges Storefront. Das ist Absicht. Entwickler bauen das Frontend selbst — mit Next.js, Nuxt, oder einem anderen Framework ihrer Wahl. Die API folgt klaren Konventionen, die Dokumentation ist gut strukturiert.

Warenkorb, Checkout, Bestellverwaltung als API
Produktkatalog mit Varianten und Medien
Admin-Panel (Laravel Filament-basiert)
Kundenverwaltung und Preisregeln
MIT-Lizenz, aktive Community

Time-to-Market: 6–12 Wochen für MVP, abhängig vom Frontend-Aufwand. Wer kein Frontend-Team hat, unterschätzt diesen Teil regelmäßig.

Bagisto

Bagisto ist die vollständigste Lösung von Haus aus. Vue.js-Frontend, Admin-Panel, Marktplatz-Modul — alles inklusive. Für Teams, die schnell einen funktionierenden Shop brauchen, ist das ein echter Vorteil.

Produktkatalog, Checkout, Kundenverwaltung
Marktplatz-Funktionalität (mehrere Verkäufer)
Vue.js-basiertes Storefront
Modulare Erweiterbarkeit über eigene Pakete
Aktive Community, regelmäßige Releases

Profi-Tipp: Bagisto eignet sich gut als Ausgangspunkt für einen Proof-of-Concept — der Checkout läuft nach der Installation in wenigen Stunden, was frühe Stakeholder-Demos erleichtert.

Time-to-Market: 3–6 Wochen für einen Standard-Shop, mehr bei starken Anpassungen am Frontend.

Headless oder Monolith? Architektur, Skalierung und Suche

Die Architekturfrage ist keine rein technische — sie bestimmt, wer wie lange an welchen Teilen des Systems arbeitet.

Ein Monolith (Aimeos, Bagisto) bündelt Frontend und Backend in einer Anwendung. Deploys sind einfacher, das Team muss weniger koordinieren, und Caching-Strategien greifen direkt auf Datenbankebene. Der Nachteil: Frontend-Änderungen ziehen Backend-Deploys nach sich, und bei sehr hohem Traffic wird horizontale Skalierung aufwendiger.

Ein headless Setup (Lunar, oder Aimeos im API-Modus) trennt Backend und Frontend vollständig. Das Frontend kann als statische Site gebaut werden, CDN-Caching greift aggressiver, und das Backend skaliert unabhängig. Dafür braucht das Team zwei separate Deployment-Pipelines und muss API-Verträge sorgfältig pflegen. Für die Architekturentscheidung zwischen diesen Ansätzen lohnt sich ein Blick auf Microservices vs. Monolith.

Skalierungspraxis

Caching-Layer: Redis für Session, Cache und Queue-Backend. Laravel Cache-Tags für granulares Invalidieren.
Queue-Worker: Bestellverarbeitung, E-Mail-Versand und Integrationsaufrufe asynchron über Laravel Queues.
Horizontale Skalierung: Stateless Application-Server hinter einem Load Balancer; Sessions in Redis, kein lokaler Dateispeicher.
CDN: Statische Assets und Produktbilder über Cloudflare oder AWS CloudFront ausliefern.
Datenbank: Read-Replicas für Katalogabfragen; bei sehr großen Katalogen Sharding-Strategie frühzeitig planen.

Suche

Laravels Scout-Paket verbindet sich mit Meilisearch, Elasticsearch oder Algolia. Meilisearch ist für kleinere bis mittlere Kataloge die einfachste Option — selbst gehostet, schnell integriert. Algolia ist teurer, aber managed und mit sehr guter Relevanz-Tuning-API. Elasticsearch lohnt sich erst bei komplexen Facetten-Anforderungen und großen Datenmengen.

Ops-Checkliste:

Redis als Cache- und Queue-Backend konfiguriert
Queue-Worker als Supervisor-Prozess laufend
Anwendungs-Monitoring (z. B. Laravel Telescope, Sentry)
Lasttest vor Go-live (z. B. mit k6 oder Locust)
Automatische Skalierung der Worker bei Spitzenlast

Welche Integrationen und welches Hosting braucht ein Laravel-Shop?

Payment-Gateways

Stripe ist die erste Wahl für die meisten Projekte — gut dokumentiert, Laravel Cashier-Integration vorhanden, und in der Schweiz vollständig verfügbar. PayPal funktioniert als Ergänzung. Für Schweizer Projekte sind zusätzlich TWINT und PostFinance relevante lokale Optionen; beide haben offizielle oder Community-gepflegte Laravel-Pakete. SEPA-Lastschrift läuft ebenfalls über Stripe. Wer lokale Acquirer (z. B. Worldline) einbinden muss, plant dafür 2–4 Wochen Integrationsaufwand ein.

Hosting-Optionen

Managed Laravel Hosts (Forge + DigitalOcean, Ploi, Laravel Vapor): schnell aufgesetzt, wenig Ops-Aufwand, gut für MVPs und mittelgroße Shops.
Container / Kubernetes (AWS EKS, Google GKE): volle Kontrolle, beliebig skalierbar, aber höherer Betriebsaufwand. Sinnvoll ab mittlerer Teamgröße mit DevOps-Erfahrung.
Platform as a Service (Heroku, Railway): einfach, aber weniger flexibel bei Datenbankoptimierungen und Queue-Konfiguration.

Für Schweizer Datenschutzanforderungen (DSGVO-ähnliche Anforderungen nach DSG) empfiehlt sich ein Hosting-Anbieter mit Rechenzentrum in der EU oder der Schweiz — AWS Frankfurt, Exoscale oder Infomaniak sind gängige Optionen.

Integrationscheckliste:

ERP-Anbindung (SAP, Abacus, Bexio) via REST-API oder Middleware
PIM-System (Akeneo, Pimcore) für komplexe Produktdaten
CRM-Integration für Kundendaten und Bestellhistorie — Outworks Erfahrung mit CRM-Systemen zeigt, wie eng diese Anbindung die Betriebseffizienz beeinflusst
Versand-APIs (DHL, Swiss Post, DPD) für automatische Label-Generierung
Tax/Invoice-Provider (z. B. Avalara, Easybill) für automatische Steuerberechnung

Profi-Tipp: Alle Integrationen zu externen Systemen gehören in Laravel-Queue-Jobs — nie synchron im Request-Lifecycle. Ein fehlgeschlagener ERP-Aufruf darf keinen Checkout blockieren.

Wie wählen Sie die richtige Lösung?

Entscheidungskriterien

Technischer Fit: Passt die Paket-Architektur zum bestehenden Stack und den Fähigkeiten des Teams?
Integrationsaufwand: Wie viele externe Systeme müssen angebunden werden, und wie gut ist die API des Pakets dokumentiert?
Team-Skillset: Hat das Team Frontend-Kapazität für headless, oder ist ein integrierter Monolith realistischer?
Total Cost of Ownership: Lizenzkosten (alle drei sind MIT), Hosting, Entwicklung, laufende Wartung und Sicherheitsupdates.
Community und Support: Wie aktiv ist das Repository? Gibt es kommerzielle Support-Optionen?

Fragen an Agenturen und Anbieter

Wie oft erscheinen neue Releases, und wie werden Breaking Changes kommuniziert?
Gibt es einen definierten Migrationspfad bei Major-Versionen?
Wie werden Sicherheitslücken gemeldet und gepatcht?
Welches SLA gilt für Wartung und kritische Bugfixes?
Wie sieht der Knowledge-Transfer am Projektende aus?

Red Flags

Repository seit mehr als 6 Monaten ohne Commit-Aktivität
Fehlende oder veraltete Dokumentation für Kernfunktionen
Proprietäre Erweiterungen ohne Quellcode-Zugang
Unklare Lizenzbedingungen bei kommerzieller Nutzung
Keine öffentliche Roadmap oder Issue-Tracker

Migration, Proof of Concept und SEO-Erhalt

POC-Checkliste

Ein sinnvoller Proof-of-Concept deckt drei Kernbereiche ab:

Checkout-Flow: Produkt in den Warenkorb, Adresseingabe, Zahlungsabwicklung mit Testdaten durchspielen.
Produktimport: Mindestens 1.000 Produkte mit Varianten importieren und die Performance der Katalogseiten messen.
Suchindex: Scout-Integration aufsetzen, Facetten-Suche testen, Antwortzeiten unter Last prüfen.

Erfolgskriterien festlegen, bevor der POC startet — z. B.

Migrationsschritte

Datenexport: Produkte, Kunden und Bestellungen aus dem Altsystem exportieren (CSV, API oder direkte DB-Abfrage).
Datenmapping: Feldstrukturen zwischen Alt- und Neusystem abgleichen; fehlende Felder identifizieren.
Redirect-Strategie: Alle alten URLs auf neue URLs mappen, 301-Weiterleitungen in Laravel-Routen oder Nginx konfigurieren.
Staged Deploy: Erst Staging, dann schrittweiser Traffic-Shift (z. B. 10 % → 50 % → 100 %) mit Monitoring.
Rollback-Plan: Altsystem bis mindestens 4 Wochen nach Go-live betriebsbereit halten.

SEO-Erhalt

URL-Mapping vollständig dokumentieren, bevor die Migration startet
Canonical Tags auf allen Produktseiten korrekt setzen
XML-Sitemap nach Migration neu generieren und bei Google Search Console einreichen
Core Web Vitals (LCP, CLS, INP) vor und nach Migration messen — Lighthouse und PageSpeed Insights als Baseline
Crawl-Fehler in den ersten 4 Wochen täglich überwachen

Wie Outwork Laravel-E-Commerce-Projekte umsetzt

Outwork begleitet Laravel-E-Commerce-Projekte von der ersten Architekturentscheidung bis zum laufenden Betrieb. Der Ablauf folgt einem strukturierten, aber anpassbaren Rahmen.

Phase	Inhalt	Typische Dauer
Discovery	Anforderungsanalyse, Integrationskartierung, Architekturentscheidung	1–2 Wochen
Architektur-Design	Paketauswahl, Datenbankschema, API-Verträge, Hosting-Setup	1–2 Wochen
MVP / POC	Kernfunktionen (Checkout, Katalog, Admin), erste Integrationen	4 Wochen
Iterative Implementierung	Erweiterungen, Optimierungen, weitere Integrationen	4 Wochen
Betrieb und Wartung	Monitoring, Sicherheitsupdates, Feature-Releases	Laufend

Typische Ergebnisse aus Projekten dieser Art: kürzere Time-to-Market durch Wiederverwendung bewährter Module, reduzierte Lizenzkosten durch MIT-Pakete statt proprietärer Shop-Systeme, und klar definierte Übergabe-Dokumentation für interne Teams.

Outworks Teamzusammensetzung für ein mittleres Laravel-E-Commerce-Projekt umfasst in der Regel einen Lösungsarchitekten, zwei bis drei Backend-Entwickler, einen Frontend-Spezialisten und einen DevOps-Engineer. SLA-Modelle für Wartung werden projektspezifisch vereinbart — von reaktivem Support bis zu definierten Reaktionszeiten unter vier Stunden.

Discovery-Ergebnisse: dokumentierte Architekturentscheidung, Risikobewertung, Integrationsplan
POC-Abnahme: funktionierender Checkout mit echten Zahlungsdaten, Produktimport validiert
Knowledge-Transfer: Betriebsdokumentation, Runbooks, Übergabe-Session mit internem Team

Was wirklich zählt bei der Paketauswahl

Der häufigste Fehler bei der Evaluierung ist die Suche nach dem einen perfekten Paket. In der Praxis gibt es das nicht. Aimeos, Lunar und Bagisto lösen echte Probleme — aber keines davon löst alle Probleme eines spezifischen Projekts ohne Anpassung.

Was in der Praxis öfter unterschätzt wird: der Abstand zwischen einer funktionierenden Demo und einem produktionsreifen Shop. Bagisto läuft nach der Installation in Stunden — aber ein Marktplatz mit 50 Verkäufern, TWINT-Integration und SAP-Anbindung ist ein anderes Projekt. Lunar gibt Entwicklern maximale Freiheit, aber diese Freiheit kostet Frontend-Zeit, die im Budget stehen muss.

Der hybride Ansatz — ein headless Core-Paket als Backend, maßgeschneiderte Module für Geschäftslogik, ein modernes Frontend-Framework — ist für die meisten B2B-Projekte überlegen. Er reduziert technische Schulden, weil die Kernfunktionen vom Paket gewartet werden, während die Geschäftslogik im eigenen Code bleibt und unabhängig weiterentwickelt werden kann.

Wer ein geringes Budget hat, sollte mit Bagisto oder Lunar starten und Anpassungen minimal halten. Bei komplexen Preisregeln, mehreren Verkaufskanälen und ERP-Integration ist höhere Investition für Entwicklung und Betrieb einzuplanen. Das ist kein Argument gegen Laravel — es ist ein Argument für ehrliche Planung.

Outwork begleitet Ihr Laravel-E-Commerce-Projekt

Wer einen Laravel-Shop plant, steht vor einer Architekturentscheidung, die den nächsten drei bis fünf Jahren des Projekts prägt. Outwork unterstützt Unternehmen dabei — von der ersten technischen Beratung über den POC-Workshop bis zur vollständigen Projektlieferung und laufenden Wartung.

Das Leistungsangebot umfasst maßgeschneiderte Softwareentwicklung, Plattform- und SaaS-Entwicklung, Migrationen von bestehenden Shop-Systemen, DevOps-Setup und Developer Outsourcing für Teams, die kurzfristig Kapazität für einen POC oder eine Migration brauchen. Engagements starten als klar abgegrenztes POC-Projekt, als Teamaugmentation für bestehende Entwicklungsteams oder als vollständige Projektlieferung.

Der konkrete nächste Schritt: eine technische Erstberatung, in der Architektur, Paketauswahl und Integrationsanforderungen gemeinsam bewertet werden. Alle Leistungen im Überblick finden sich auf der Outwork-Website.