5 Open-Source-E-Commerce-Plattformen für Entwickler

Für Frontend-Entwickler, die 2026 ein Headless-Storefront aufbauen, sind Medusa, Saleor, Vendure, Sylius und Shopware die stärksten Open-Source-Commerce-Backends, die es zu evaluieren gilt. Alle sind API-first, werden aktiv gepflegt und lassen sich sauber mit einem Next.js- oder einem anderen React-basierten Storefront kombinieren — unterscheiden sich jedoch erheblich in Bezug auf die Sprachlaufzeit, die API-Form (REST vs. GraphQL), das Lizenzmodell und den operativen Aufwand beim Self-Hosting. Dieser Artikel soll Ihnen helfen, eine Lösung für ein Projekt auszuwählen, in das Sie wochenlange Integrationsarbeit und jahrelange Wartung investieren werden.

WooCommerce, Magento und PrestaShop verdienen hier eine ehrliche Erwähnung: Es sind ausgereifte, weit verbreitete Ökosysteme mit umfangreichen Plugin-Marktplätzen und Merchant-Tooling, mit dem die unten aufgeführten Plattformen nicht mithalten können. Ihr Schwerpunkt liegt jedoch in der WordPress/Admin-Template-Welt, nicht in API-getriebenen Storefronts, die in TypeScript geschrieben sind. Wenn Ihr Storefront eine Next.js-Anwendung ist, die ein typisiertes SDK oder einen GraphQL-Endpunkt aufruft, sind die fünf unten aufgeführten Plattformen die relevante Auswahl. Wenn Ihr Storefront hingegen eine CMS-basierte, themeable Website ist, die von einem Marketing-Team verwaltet wird, lesen Sie den falschen Artikel.

Headless Commerce ist kein Trend mehr, der erst noch verkauft werden muss — es ist die Standardarchitektur für Greenfield-Storefronts. Die Frage ist nicht mehr, ob man das Storefront vom Commerce-Engine entkoppeln soll, sondern welche Engine die beste Developer Experience für die Jahre an Feature-Entwicklung bietet, die folgen werden.

Wie man die Wahl trifft: eine Vergleichstabelle

Der schnellste Weg, eine Auswahlliste einzugrenzen, besteht darin, die Plattformen anhand der Dimensionen nebeneinander zu stellen, die für einen Storefront-Entwickler tatsächlich relevant sind. Die folgende Tabelle fasst die fünf Kandidaten zusammen; Star-Zahlen und Release-Versionen ändern sich ständig, daher sollten sie als Ausgangspunkt betrachtet und vor einer endgültigen Entscheidung anhand der GitHub-Releases-Seite jedes Projekts verifiziert werden.

Zwei Spalten verdienen besondere Aufmerksamkeit. Die Lizenzspalte erzählt nicht die ganze Geschichte: Vendure und Shopware liefern beide einen MIT-lizenzierten Kern, der vollständig produktionstauglich ist, zusammen mit separat lizenzierten kommerziellen Managed-Platform-Angeboten. Das ist ein relevanter Aspekt für die Budgetplanung, kein Trick — der Open-Source-Kern ist tatsächlich nutzbar, ohne für die Plattform-Stufe zu bezahlen. Die Spalte Self-Hosting-Footprint spiegelt die Mindestanzahl an Diensten wider, die Sie in der Produktion betreiben werden, und hier weicht Saleor deutlich von den Node-basierten Optionen ab.

Medusa — Node.js/TypeScript Headless Commerce mit v2-Modulen und Workflows

Medusa ist ein Node.js/TypeScript-Headless-Commerce-Backend, dessen v2-Release die Plattform um unabhängige Commerce-Module herum neu strukturiert hat — Produkte, Warenkorb, Bestellungen, Inventar, Preisgestaltung — von denen jedes durch eine eigene Implementierung oder einen Drittanbieter-Service ersetzt werden kann. Die offizielle v2-Dokumentation beschreibt die Modul- und Workflow-Architektur.

Für einen Frontend-Entwickler ist das Ergebnis die am stärksten komposierbare der fünf Plattformen. Storefront-Code kommuniziert mit dem Medusa-Server über einen typisierten JavaScript-Client; Backend-Anpassungen erfolgen durch das Schreiben von Modulen und Workflows in TypeScript, die im selben Monorepo wie die übrigen Services Ihres Teams leben können. Der offizielle Next.js-Starter in der Medusa-Dokumentation liefert ein funktionsfähiges Storefront mit Warenkorb, Checkout und Account-Flows mit einem einzigen create-medusa-app-Befehl.

Wo Medusa hervorsticht:

• Durchgängige Typenausrichtung. Der Server ist TypeScript; das Storefront-SDK ist TypeScript; benutzerdefinierte Module sind TypeScript. Es gibt keinen Codegen-Schritt zwischen Schemas und Storefront-Typen.
• Workflows. Medusa v2 stellt ein explizites Workflow-Primitiv für mehrstufige Commerce-Operationen (Bestellung aufgeben, Rückgabe usw.) bereit, was langläufige und kompensierbare Logik einfacher nachvollziehbar macht als implizite Transaktionsketten.
• Lokale Entwicklung ist unkompliziert. Ein einzelner Node-Prozess gegen PostgreSQL, plus Redis für Hintergrundjobs.

Wo Medusa Aufmerksamkeit erfordert:

• REST-first. Medusas primäre API ist REST. Storefronts, die einen einzigen GraphQL-Endpunkt und codegen-gesteuerte Typen wünschen, werden Saleor natürlicher finden.
• v1 → v2-Migration. Codebasen, die noch auf Medusa v1 basieren, stehen vor erheblichem Migrationsaufwand; das Modulsystem, das Admin-Interface und die APIs haben sich grundlegend verändert.

Wählen Sie Medusa, wenn Ihr Team TypeScript-nativ ist, Sie die volle Kontrolle über Anpassungen in Ihrer eigenen Sprache wünschen und eine REST- und typisiertes-SDK-Ergonomie für Sie geeignet ist. Überspringen Sie Medusa, wenn Sie eine reine GraphQL-Datenschicht wünschen oder von Anfang an ein umfangreiches, sofort einsatzbereites Admin- und Merchandising-Toolset benötigen.

Saleor — GraphQL-first Headless Commerce auf Python/Django

Saleor ist eine Python/Django-Headless-Commerce-Plattform mit einer GraphQL-first-API. Jede Commerce-Operation — Produktabfragen, Checkout-Mutationen, Bestellverwaltung, Kundenkonten — läuft über einen einzigen versionierten GraphQL-Endpunkt, der in der Saleor API-Referenz dokumentiert ist. Die Codebasis ist BSD-3-Clause-lizenziert; siehe die LICENSE-Datei auf GitHub.

Das GraphQL-first-Design macht sich vor allem auf der Storefront-Ebene bemerkbar. Ein Next.js-Storefront kann seine Datenanforderungen mithilfe von urql, Apollo oder graphql-request direkt bei den Komponenten platzieren, graphql-codegen gegen Saleors Schema ausführen und vollständig typisierte Query- und Mutation-Hooks erhalten, ohne eine separate REST-Adapterschicht schreiben zu müssen. Eine typische Produktseiten-Abfrage sieht folgendermaßen aus:

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

Diese einzelne Abfrage gibt genau das zurück, was die Seite rendert — kein Overfetching, kein separater Inventar-Aufruf, kein Preisformatierungs-Helper, der von der serverseitigen Währungsdarstellung abweicht. Saleor veröffentlicht auch ein offizielles Next.js-Storefront-Beispiel (Storefront-Repository), das Sie forken können, anstatt von Grund auf neu zu bauen.

Wo Saleor Aufmerksamkeit erfordert:

• Operativer Footprint. Saleor im Self-Hosting benötigt Python, PostgreSQL, Redis und einen Celery-Worker-Prozess für asynchrone Aufgaben. Das ist schwerer als eine Node + Postgres-Kombination und sollte berücksichtigt werden, wenn Ihr Team noch keinen Python-Stack betreibt.
• Schema-Versionierungsdisziplin. Eine GraphQL-first-Plattform bedeutet, dass Breaking Schema Changes sichtbar sind. Saleor veröffentlicht neue Minor-Versionen mit klaren Migrationshinweisen, aber Storefronts, die das Schema nicht pinnen und Typen nicht neu generieren, werden nach Upgrades auf stille Fehler stoßen.

Wählen Sie Saleor, wenn Sie einen einzigen GraphQL-Endpunkt wünschen, Sie bereit sind, einen Python-Stack zu betreiben, und Ihr Storefront-Team mit GraphQL-Clients und Codegen vertraut ist. Überspringen Sie Saleor, wenn Ihr Team keine Python-Betriebserfahrung hat und Sie den gesamten Stack lieber auf Node halten möchten.

Vendure — TypeScript/NestJS-Framework mit MIT-Core und einer kommerziellen Platform-Stufe

Vendure ist ein TypeScript/NestJS-Headless-Commerce-Framework mit einer GraphQL-API und einem Angular-basierten Admin-Interface. Es ist die einzige Plattform in diesem Vergleich, die ihre Plugin-API, Service-Schicht und GraphQL-Schema-Erweiterungen in TypeScript mit vollständiger Typinferenz ausliefert — das bedeutet, dass benutzerdefinierte Plugins und Storefront-Code ein gemeinsames Sprach- und Typmodell teilen. Die Vendure-Dokumentation beschreibt das Plugin-System, die dualen Shop/Admin-GraphQL-APIs und das Datenmodell.

Vendures Open-Source-Core (MIT-lizenziert) ist ein vollständig funktionsfähiges Headless-Commerce-Engine. Die kommerzielle Vendure Platform fügt Managed Hosting, Enterprise-Support und zusätzliche Module hinzu, ist jedoch nicht erforderlich, um ein Produktions-Storefront zu betreiben. Diese Trennung ist wichtig zu verstehen, bevor Sie sich für die Plattform entscheiden: Der Core ist tatsächlich vollständig, und „Open Source” bedeutet hier nicht „funktionseingeschränkte Demo.”

Aus Storefront-Perspektive stellt Vendure zwei GraphQL-APIs bereit — Shop für öffentliche Storefront-Operationen und Admin für Back-Office-Tooling. Beide sind introspektierbar und codegen-freundlich. NestJS bildet das Fundament des Servers, was bedeutet, dass benutzerdefinierte Plugins einem vertrauten Modul-Provider-Muster folgen, wenn Ihr Team NestJS-Erfahrung hat.

Wo Vendure glänzt:

• TypeScript überall. Server, Plugins, Admin-UI-Erweiterungen und Storefront — ein einziges Typsystem.
• Saubere Plugin-Architektur. Benutzerdefinierte Felder, Lifecycle-Hooks und GraphQL-Schema-Erweiterungen sind erstklassige Konzepte, keine nachträglichen Ergänzungen.
• Leichtgewichtiges Self-Hosting. Einzelner Node-Prozess gegen PostgreSQL oder MySQL. Der Standard-Getting-Started-Flow verwendet SQLite für die lokale Entwicklung.

Wo Vendure Kompromisse eingeht:

• Kleineres Ökosystem. Im Vergleich zu Saleor oder Medusa ist der Katalog an Drittanbieter-Plugins und -Integrationen kleiner. Sie werden mehr Glue-Code selbst schreiben müssen.
• Admin ist Angular. Wenn Ihr Team das Admin-UI stark anpassen möchte und ausschließlich React verwendet, bedeutet das einen Kontextwechsel.

Wählen Sie Vendure, wenn Sie den TypeScript-nativsten, typsichersten Headless-Commerce-Stack wünschen und bereit sind, einige Integrationen selbst zu entwickeln. Überspringen Sie Vendure, wenn Sie von Anfang an den breitesten Plugin-Marktplatz benötigen oder kein Angular-Admin-Interface tolerieren können.

Sylius — Symfony-Commerce-Framework mit REST und GraphQL via API Platform

Sylius ist ein Open-Source-E-Commerce-Framework, das auf Symfony (PHP) aufbaut. Es positioniert sich als Framework und nicht als schlüsselfertige Plattform: Es stellt die Commerce-Primitive bereit (Produkte, Channels, Bestellungen, Promotionen, Warenkörbe) und setzt voraus, dass Sie diese zu der Anwendung zusammenstellen, die Ihr Unternehmen tatsächlich benötigt. Die Sylius-Dokumentation beschreibt das Komponentenmodell und die Symfony-Bundles.

Für Frontend-Entwickler ist Sylius aufgrund seiner API-Schicht relevant. Sylius integriert sich mit API Platform, um REST- und GraphQL-Endpunkte über sein Datenmodell bereitzustellen, was es als Headless-Backend für ein Next.js- oder anderes JavaScript-Storefront nutzbar macht. Das Standard-Storefront verwendet Twig-Templates — für traditionelle Builds geeignet, für Headless-Setups irrelevant.

Wo Sylius punktet:

• Symfony-Tiefe. Wenn Ihre Organisation Symfony-erfahren ist, fügt sich Sylius natürlicher in das breitere PHP-Enterprise-Ökosystem ein als jede andere Plattform in diesem Vergleich.
• Anpassung durch Framework-Idiome. Services, Events und Entities werden mit Standard-Symfony-Mustern überschrieben. Kein proprietäres Plugin-DSL.
• MIT-Lizenz, keine kommerzielle Stufe erforderlich. Die vollständige Sylius-Codebasis unter MIT ist das, worauf Sie aufbauen.

Wo Sylius Kompromisse eingeht:

• PHP-Laufzeit. Ein Next.js-Team ohne PHP-Betriebserfahrung erbt PHP-FPM, Composer und Symfony-Tooling für das Backend.
• Mehr Eigenentwicklung erforderlich. Sylius ist ehrlich darüber, ein Framework zu sein. Sie werden mehr Code schreiben müssen als mit Medusa oder Saleor, um Feature-Parität mit einer schlüsselfertigen Plattform zu erreichen.

Wählen Sie Sylius, wenn Sie Symfony-Kompetenz im Haus haben und ein Commerce-Framework wünschen, das Sie vollständig auf Ihre Domäne zuschneiden können. Überspringen Sie Sylius, wenn Ihr Team ausschließlich JavaScript verwendet und Sie keine PHP-Laufzeit neben Ihren Node-Services betreiben möchten.

Shopware 6 — PHP/Symfony-Backend mit umfangreichem Merchant-Tooling und einem Vue.js-Storefront

Shopware 6s MIT-lizenzierte Community Edition ist ein vollständiges Commerce-Backend mit traditionellen und Headless-Deployment-Optionen, das eine REST Store API neben seinem Vue.js-basierten Storefront-Framework bereitstellt. Die kommerziellen Rise-, Evolve- und Beyond-Pläne fügen Managed Hosting, erweiterte B2B-Funktionen und Enterprise-Support-Features hinzu, aber der Open-Source-Kern ist ohne eine kommerzielle Lizenz produktionstauglich. Die Shopware-Entwicklerdokumentation beschreibt die Store API, Admin API sowie das App- und Plugin-System.

Shopware ist die merchant-feature-vollständigste Plattform in diesem Vergleich. Das „Shopping Experiences”-CMS bietet einen Drag-and-Drop-Seitenbuilder für Marketing-Seiten; der Rule Builder unterstützt dynamische Preis-, Versand- und Promotionsregeln ohne Code; das Admin-Tooling ist außerordentlich umfangreich. Für einen Entwickler, der ein Next.js-Storefront aufbaut, ist die Store API REST-basiert und gut dokumentiert, und es gibt Community-Next.js-Storefront-Starter, die diese konsumieren.

Wo Shopware punktet:

• Out-of-the-box Merchant-Tooling, das keine der entwicklerorientierten Plattformen oben erreicht.
• Starke Marktposition in Europa mit einem ausgereiften Partner-Ökosystem.
• Hybrid Headless. Sie können das Standard-Vue.js-Storefront betreiben oder über die Store API vollständig headless gehen.

Wo Shopware Kompromisse eingeht:

• PHP + Elasticsearch-Betriebsfootprint. Schwerer im Self-Hosting als die Node-Optionen.
• Plugin-System ist PHP-zentriert. Backend-Anpassungen erfolgen in PHP/Symfony, auch wenn Ihr Storefront TypeScript verwendet.

Wählen Sie Shopware, wenn Sie umfangreiche Merchant-Features out-of-the-box benötigen und mit dem Betrieb eines Symfony/PHP-Stacks vertraut sind. Überspringen Sie Shopware, wenn Ihr Team ausschließlich JavaScript verwendet und Sie eine leichtere, entwicklerorientiertere Option wie Medusa oder Vendure bevorzugen.

Wann Spree stattdessen sinnvoll ist

Wenn Shopware zu enterprise-orientiert erscheint und Ihr Team Ruby-on-Rails-Erfahrung hat, ist Spree Commerce eine vernünftige Alternative. Es ist MIT-lizenziert, vollständig API-getrieben, unterstützt Multi-Store- und Multi-Vendor-Setups und ist lange genug im Einsatz, dass die Rails-Muster gut etabliert sind. Der Kompromiss spiegelt den von Sylius wider: Ruby on Rails statt Symfony, aber die gleiche Art von Entscheidung — das Ökosystem eines ausgereiften serverseitigen Frameworks übernehmen im Austausch für eine Nicht-JS-Laufzeit.

Frontend-seitige Entscheidungsfaktoren

Auf der Storefront-Integrationsebene entscheiden fünf Faktoren darüber, ob sich ein Backend produktiv oder mühsam anfühlt: TypeScript-Ergonomie, Next.js-Kompatibilität, lokaler Dev-Kaltstart, Plugin-Architektur und Dokumentationstiefe.

TypeScript- und Codegen-Ergonomie. Medusa und Vendure liefern beide TypeScript-SDKs, die mit den Servertypen übereinstimmen, ohne einen separaten Generierungsschritt. Saleors GraphQL-Schema wird am besten über graphql-codegen konsumiert, was einen Build-Schritt hinzufügt, aber ausgezeichnete typisierte Hooks erzeugt. Sylius und Shopware erfordern, dass Sie API-Antworten selbst modellieren oder von der Community generierte Clients verwenden.

Next.js-Kompatibilität. Medusa und Saleor pflegen beide offizielle Next.js-Storefront-Beispiele, die mit dem App Router funktionieren. Vendure hat Community-Starter. Sylius und Shopware werden von Next.js-Storefronts typischerweise über direkte API-Aufrufe oder Community-SDKs konsumiert — machbar, aber Sie schreiben mehr der Integration selbst.

Lokale Entwicklungserfahrung. Medusa und Vendure bieten den schnellsten Kaltstart — Abhängigkeiten installieren, eine Migration ausführen, den Server starten, fertig. Saleor ist gut dokumentiert, aber aufwändiger aufgrund der Python + Redis + Celery-Anforderung; Docker Compose wird empfohlen. Shopware und Sylius setzen eine funktionierende PHP-Entwicklungsumgebung voraus; Docker-Images vereinfachen dies, aber die beweglichen Teile sind zahlreicher.

Plugin- und Erweiterungsarchitektur. Alle fünf Plattformen unterstützen benutzerdefinierte Erweiterungen, aber die Developer Experience unterscheidet sich. Vendure-Plugins sind TypeScript-Module mit typsicheren Lifecycle-Hooks. Medusa-v2-Module sind TypeScript-Klassen mit einem klaren Vertrag. Saleor verwendet Webhook-basierte „Apps”, die als separate Services laufen — eine stärkere Isolationsgrenze, aber mehr operativer Aufwand. Sylius und Shopware verwenden Symfonys Bundle/Plugin-Systeme.

Dokumentationsqualität. Unter den fünf pflegen Medusa, Saleor, Vendure und Shopware alle Dokumentationsseiten mit API-Referenzen, Tutorials und Architekturübersichten, die mit den Releases aktuell gehalten werden. Sylius’ Dokumentation ist gründlich, setzt aber Symfony-Kenntnisse voraus.

Reale Fehler, die jede Plattformwahl überleben

Ein häufiges Produktionsfehlermodell in Headless-Storefronts — über alle Backends in diesem Artikel hinweg — ist ein React-Hydration-Mismatch auf Produktseiten, bei dem serverseitig gerenderte Preise, Lagerbestände oder lokalisierte Strings von dem abweichen, was der Client nach dem Abrufen frischer Daten rendert. Weitere wiederkehrende Muster: stille Warenkorb-Zustandsdivergenz, wenn der Client-Warenkorb und die Serversitzung nach einem Netzwerkfehler auseinanderdriften; Zahlungsanbieter-Skripte (Stripe, Adyen, PayPal), die nicht geladen oder initialisiert werden und sich nur als hängengebliebener Checkout-Button manifestieren; und Breaking Schema Changes nach einem Backend-Upgrade, die kryptische Null-Felder statt lauter Fehler erzeugen.

Diese Fehler sind plattformunabhängig, variieren aber in ihrer Debuggbarkeit je nachdem, wie das Backend Fehlerkontext in seinen API-Antworten bereitstellt. Saleors GraphQL-Fehler enthalten strukturierte Codes; Medusas REST-Antworten enthalten Fehlertypen; Shopware und Sylius stellen Symfonys strukturiertes Fehlerformat bereit. Unabhängig davon, welche Sie wählen, schließt die Instrumentierung des Storefronts mit Session-Replay-Tooling wie OpenReplay — um den tatsächlichen DOM-Zustand, Netzwerkanfragen, Konsolenfehler und Benutzerinteraktionen zu erfassen, die zu einem fehlgeschlagenen Warenkorb oder einem defekten Checkout geführt haben — die Lücke zwischen „Benutzer sagt, der Checkout ist kaputt” und einem reproduzierbaren Bug-Report. OpenReplay’s Session-Replay-Produkt ist speziell für diese Kategorie des Frontend-Produktions-Debuggings entwickelt worden.

Die Entscheidung treffen

Die Auswahlliste schrumpft schnell, sobald Sie die Sprachkenntnisse des Teams und die Präferenz der Datenschicht des Storefronts abwägen. Ein TypeScript-natives Team, das ein Next.js-Storefront mit einem typisierten SDK aufbaut, sollte zuerst Medusa und dann Vendure evaluieren. Ein Team, das einen einzigen GraphQL-Endpunkt wünscht und bereit ist, einen Python-Stack zu betreiben, sollte Saleor evaluieren. Ein Symfony-erfahrenes Team sollte Sylius für einen framework-orientierten Build oder Shopware für das umfangreichste Merchant-Tooling evaluieren. Führen Sie den lokalen Quickstart für Ihren Top-Kandidaten oder Ihre Top-Kandidaten durch, bevor Sie sich festlegen — ein Nachmittag mit docker-compose up und ein Rundgang durch das Admin-Interface wird Ihnen mehr sagen als eine weitere Woche des Vergleichslesens.

FAQs

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.