Makro PRO orchestriert mit MedusaJS täglich rund 5.000 Bestellungen über ein dreistelliges Shop-Netzwerk. Andere Unternehmen evaluieren Medusa und entscheiden sich am Ende bewusst dagegen, weil eine Suite-Lösung besser zu ihrem Setup passt. Beide Wege können richtig sein, und genau dieser Gegensatz zeigt, wofür sich das Framework eignet und wofür nicht.
MedusaJS ist ein in TypeScript geschriebenes Open-Source-Commerce-Framework auf Basis von Node.js. Es liefert ein modulares Commerce-Backend mit über 18 Domain-Modulen, einer Workflow-Engine, einem React-Admin und einer strikten Trennung von Storefront, Admin und Datenhaltung. Die Lizenz ist MIT: keine Lizenzgebühr, keine GMV-Beteiligung.
Dieser Beitrag liefert einen neutralen Überblick mit den Details, die in Marketing-Übersichten typischerweise fehlen: Was leistet das Framework technisch, für welche Szenarien lohnt es sich, und wann solltest du die Finger davonlassen?
Was MedusaJS ist und was nicht
Medusa startete 2020 als Open-Source-Alternative zu Shopify Plus und commercetools und wurde am 23. Oktober 2024 mit der Version 2.0 vollständig neu aufgesetzt. Mit über 33.000 GitHub-Stars und rund 150.000 NPM-Downloads pro Monat (Stand Mai 2026) ist es das aktivste Open-Source-Commerce-Projekt überhaupt.
Zwei Einordnungen helfen, das Framework korrekt zu verorten.
Medusa ist kein Shopsystem im klassischen Sinne. Es ist ein Commerce-Backend mit modularer Architektur. Was du unter „Shop" verstehst (Storefront, Produktdetailseite, Checkout-UI), liefert Medusa nicht out of the box. Stattdessen gibt es einen offiziellen Next.js-Starter, Community-Starter für andere Frameworks und ein REST/GraphQL-API-Layer, an dem du dein eigenes Frontend andockst. Wer einen sofort verkaufsfähigen Shop wie bei Shopify oder Shopware sucht, bekommt hier ein Framework, keine Plattform.
Medusa ist kein reines „Headless"-Produkt. Es bringt ein vollständiges, in React geschriebenes Admin-Panel mit, das mit Version 2.0 grundlegend überarbeitet wurde. Bestellverwaltung, Produktpflege, Promotions, B2B-Konten, Multi-Warehouse: alles vorhanden, alles erweiterbar.
In der Praxis konkurriert das Framework nicht mit Shopify oder WooCommerce, sondern mit commercetools, Saleor und maßgeschneiderten Composable-Stacks. Die Vergleichsklasse ist Enterprise-orientiert, der Einstiegspunkt aber Open Source.
Die Architektur im Detail
Mit Version 2.0 wurde aus dem ursprünglich monolithischen Backend eine echte modulare Architektur. Das ist mehr als ein Marketing-Begriff: Es hat handfeste Konsequenzen für Wartung und Erweiterbarkeit.
Commerce-Module ohne harte Datenbankkopplung
Medusa unterteilt jede Geschäftsdomäne (Produkte, Carts, Orders, Payments, Pricing, Inventory, Promotions, Customers) in ein eigenständiges Modul. Im Core sind rund 18 Commerce-Module enthalten. Entscheidend ist, dass zwischen diesen Modulen keine Foreign-Key-Beziehungen auf Datenbankebene existieren. Verknüpfungen werden über sogenannte Module Links abgebildet, die zur Laufzeit aufgelöst werden.
Was nach Architektur-Theorie klingt, wird im Vergleich greifbar: In Shopware hängt der Customer hart am Order, beide leben in derselben Datenbank mit Constraints. In Medusa kannst du das Customer-Modul durch eine Salesforce-Anbindung ersetzen, ohne die Order-Tabelle zu berühren. Zwei Szenarien aus der Praxis:
- Selektive Adoption. Ein PIM-getriebener Hersteller adoptiert nur das Order- und Pricing-Modul und lässt Produktdaten weiter aus seinem bestehenden PIM fließen. Eine große Datenmigration ist keine Voraussetzung.
- Modul-Ersetzung. Reicht das mitgelieferte Pricing-Modul nicht aus, etwa weil ein komplexes Staffelpreis-Modell mit Vertragsindividualität gebraucht wird, kannst du es durch eine eigene Implementierung tauschen, ohne das restliche System anzufassen.
Für gewachsene Mittelstands-Stacks mit ERP, PIM und eigenem OMS ist das eine relevante Eigenschaft. Klassische Suites verlangen oft, dass du dich entweder ganz auf ihr Datenmodell einlässt oder gar nicht.
Die Workflow-Engine
Die Workflow-Engine bekommt in den meisten Medusa-Diskussionen zu wenig Aufmerksamkeit, obwohl sie eines der stärksten Argumente für das Framework ist. Jeder, der schon einmal um drei Uhr morgens in Logs nach einem halb durchgelaufenen Checkout gesucht hat, kennt das Grundproblem mehrstufiger Commerce-Prozesse. Lagerbestand reserviert, Zahlung autorisiert, aber die ERP-Buchung scheitert. Und nun?
Medusa modelliert solche Prozesse als Workflows aus atomaren Steps. Die Engine kümmert sich um drei Dinge:
- Kompensation: Wenn Schritt 4 fehlschlägt, werden die Schritte 1 bis 3 sauber zurückgerollt, jeder mit seiner eigenen
compensate-Funktion. - Retry-Logik: Flüchtige Fehler wie ein Payment-Provider-Timeout lösen automatische Wiederholungen mit konfigurierbarem Backoff aus.
- Idempotenz: Derselbe Workflow läuft bei Mehrfach-Trigger nicht doppelt; jeder Step kann eine Idempotency-Key-basierte Garantie geben.
Ein typischer Order-Placement-Workflow sieht so aus: validateCart → reserveInventory → authorizePayment → createOrder → triggerFulfillment. Schlägt triggerFulfillment fehl, weil die Schnittstelle zum WMS gerade nicht antwortet, hebt die Engine die Inventory-Reservierung wieder auf, gibt die Zahlungsautorisierung frei und protokolliert jeden Schritt nachvollziehbar in einer Audit-Spur. Wer diese Mechanik in einem klassischen Shopsystem haben möchte, baut sie selbst oder ergänzt sie mit einem externen Workflow-Tool wie Temporal.
Storefront, Admin und Hosting strikt getrennt
Architektonisch zerfällt eine Medusa-Installation in drei Komponenten, die unabhängig deploybar sind:
- Medusa Backend: Node.js-Server mit allen Modulen.
- Admin Dashboard: React-SPA, im Backend gehostet oder separat.
- Storefront: vom Backend komplett entkoppelt, üblicherweise Next.js, aber jedes Frontend, das REST oder GraphQL spricht, funktioniert.
Diese Trennung ist kein Selbstzweck. Sie sorgt dafür, dass das Frontend-Team in seinem Tempo arbeitet und das Backend in seinem, und dass Performance-Tuning für die Storefront (Edge-Caching, ISR, statisches Pre-Rendering) unabhängig vom Commerce-Backend stattfindet.
Wofür sich MedusaJS eignet
Medusa ist kein Allzweck-Werkzeug. Es spielt seine Stärken in bestimmten Konstellationen aus.
Am deutlichsten im B2B mit komplexen Pricing- und Account-Modellen. Kundenspezifische Preislisten, freigegebene Sortimente pro Account und mehrstufige Bestellgenehmigungen lassen sich sauber abbilden, weil Pricing- und Customer-Modul von Haus aus für Mehrdimensionalität ausgelegt sind. Wie belastbar das ist, zeigt Makro PRO: Der Großhändler orchestriert rund 5.000 Bestellungen täglich über ein dreistelliges Netzwerk an Shops und Distributionspartnern, bei einem Jahres-GMV im dreistelligen Millionenbereich.
Ähnlich gut passt es für Marketplaces und Multi-Vendor-Setups. Einen eingebauten Marketplace-Modus gibt es zwar nicht, aber dank Sales Channels, Stock Locations und Module Links entstehen Multi-Tenant- und Multi-Vendor-Architekturen mit überschaubarem Aufwand.
Ein eigenes Feld ist die Order-Orchestrierung jenseits des klassischen Webshops. Wer Medusa nicht als Frontstore versteht, sondern als Order-Backbone, etwa zur Konsolidierung von Bestellungen aus mehreren Sales-Kanälen oder als Hub zwischen mehreren ERPs, nutzt es genau dort, wo das modulare Datenmodell überlegen ist. INSPIRED Pet Nutrition etwa setzt es als KI-gestütztes Order-Management zwischen zwei getrennten ERPs ein und senkt die operativen Kosten der Auftragsabwicklung um 80 Prozent.
Den größten Vorsprung bietet das Framework bei Custom Workflows, die Standard-Suites nicht abbilden: Mietmodelle, Subscriptions mit unregelmäßigen Lieferzyklen, Buchungs-Commerce oder Pay-per-Use. Viessmann betreibt darauf eine B2B-Vermietungsplattform für mobile Heiz- und Kühlgeräte; Lieferanten erstellen Angebote dort 60 Prozent schneller, und Buchungen, die früher Wochen brauchten, laufen jetzt in Minuten durch. Medusa zwingt nichts in ein vordefiniertes Order-Konzept.
Schließlich deckt es Internationalisierung mit echter Multi-Region-Logik ab. Mehrere Währungen, regionsspezifische Steuersätze, Versandzonen und Zahlarten gehören zum Core und sind nicht über Plugins zusammengeschustert.
Wofür MedusaJS eher nicht passt
Genauso wichtig ist die andere Seite. Für schnelle Out-of-the-box-Shops ist Medusa die falsche Wahl: Wer in vier Wochen einen B2C-Shop launchen will und kein DevOps-Team in Reichweite hat, ist mit Shopify, Shopware oder einer Cloud-Suite besser bedient. Medusa setzt voraus, dass jemand das Frontend gestaltet, das Hosting betreibt und die Integrationen schreibt.
Auch Teams ohne JavaScript- oder TypeScript-Tiefe stoßen schnell an Grenzen. Das gesamte Customizing, von neuen Modulen über eigene Workflows bis zu Admin-Erweiterungen, geschieht in TypeScript. Ein PHP-lastiges Team kann das System zwar betreiben, aber nicht effizient erweitern.
Marketing-Teams, die ein WYSIWYG-Frontend erwarten, werden ebenfalls enttäuscht. Anders als bei Shopware oder Shopify gibt es kein eingebautes „Shopping Experiences"-Tool; Storefront-Editing läuft über das Frontend-Framework, nicht über das Admin-Panel. Dafür braucht es entweder Code-Disziplin oder ein vorgeschaltetes CMS wie Sanity, Strapi oder Contentful, was wiederum den Stack vergrößert.
Und bei sehr kleinen Produktkatalogen mit klassischen B2C-Bedürfnissen lohnt der Aufwand nicht: Wer 50 Produkte verkauft und Standard-Funktionalität braucht, zahlt eine Komplexitätssteuer, die sich nicht amortisiert.
Total Cost of Ownership: ehrlich gerechnet
Open Source heißt nicht kostenlos. Auch wenn die Lizenz bei null Euro liegt, fallen reale Kosten in vier Bereichen an.
Das Hosting beginnt überschaubar. Self-Hosting auf einer Plattform wie Railway, Render oder DigitalOcean startet realistisch bei 35–110 € im Monat für ein schlankes Setup mit Backend und Datenbank. Mit Skalierung, Redis, Caching-Layer und CDN wächst das schnell auf mehrere hundert Euro. Wer stattdessen Medusa Cloud nimmt, seit Oktober 2025 als Self-Service verfügbar, zahlt nach aktuellem Stand 29 $ für den Develop-, 99 $ für den Launch- und 299 $ für den Scale-Plan pro Monat, jeweils mit nutzungsbasierten Overages für Compute, Storage, Preview-Environments und Build-Minuten. Produktive Shops mit 50–150k Sessions im Monat landen je nach Lastprofil bei 200–800 $ monatlich.
Den mit Abstand größten Posten macht Entwicklung und Wartung aus. Ein konkretes Beispielsetup, bestehend aus einer Storefront auf Basis des Next.js-Starters, drei Custom-Workflows, einer Anbindung an SAP Business One, Algolia für die Suche und Stripe für Payments, liegt typischerweise bei 60–120 Tagen Umsetzungszeit und einem Budget zwischen 80.000 € und 130.000 €. Komplexere B2B-Setups mit eigenen Pricing-Engines erreichen schnell sechsstellige Bereiche, und die laufende Weiterentwicklung kostet so viel wie bei jeder anderen Custom-Lösung.
Dazu kommen die Drittsysteme. Medusa selbst hat keine Suchengine, kein eingebautes CMS und keine eigene Mailing-Lösung. Algolia, Meilisearch, Sanity oder Postmark sind optional, summieren sich aber. Das ist kein Nachteil des Frameworks, sondern Eigenschaft jedes Composable-Setups.
Die oft zitierte Ersparnis von 30–50 Prozent Entwicklungszeit stimmt nur bedingt. Wer eine Custom-Plattform ohnehin bauen müsste, kommt mit Medusa schneller ans Ziel als bei einem Frischstart. Gegenüber einer Suite-Lösung mit fertigem Frontend ist es dagegen kein Effizienzsprung, sondern eine bewusste Investition in Kontrolle und Flexibilität.
Cloud oder Self-Hosting?
Diese Frage spaltet die Community, aber für die meisten mittelständischen Setups ist die Antwort klar: Medusa Cloud, Launch-Plan. Wer Time-to-Value braucht, kein eigenes DevOps-Setup unterhält und sein Team auf Produktentwicklung statt Infrastruktur konzentrieren will, fährt damit am besten.
Self-Hosting lohnt sich nur unter einer Bedingung: ein internes DevOps-Team, das Node.js-Services im Produktivbetrieb sicher führt, inklusive Monitoring, Backups, Skalierung und Sicherheits-Updates. Bei moderatem Traffic ist es auf der reinen Hosting-Rechnung zwar günstiger, doch sobald du die eingesparten Euro gegen die investierten Engineering-Stunden rechnest, fällt der Vorteil meist in sich zusammen. Ohne dieses Team ist Self-Hosting die teurere Option, nur mit verstecktem Preisschild.
Eine Mischform aus Cloud für Staging und Self-Hosting für Produktion (oder umgekehrt) ist technisch möglich, aber organisatorisch fragiler, als sie auf dem Whiteboard aussieht. Wir raten davon ab, solange es keinen zwingenden Grund dafür gibt.
Wie ein realistischer Einstieg aussieht
Eine Medusa-Evaluierung läuft in der Regel durch drei Phasen. Am Anfang steht ein technischer Proof of Concept: vier bis acht Wochen, fester Scope mit Standard-Storefront, einem Payment-Provider, einer ERP-Anbindung und einem klar definierten Use Case. Ziel ist nicht der fertige Shop, sondern eine belastbare Antwort auf die Frage, ob das Framework unter deinen tatsächlichen Anforderungen wie versprochen funktioniert.
Darauf folgt ein MVP mit echtem Traffic, also der Ausbau des PoC zu einer minimalen, aber produktionsfähigen Version mit realistischen Daten, echten Bestellungen und messbaren KPIs. Je nach Integrationstiefe dauert das zwei bis vier Monate.
Erst danach kommen mit Rollout und Erweiterung die anspruchsvollen Funktionen hinzu: KI-gestützte Suche, Personalisierung, Multi-Region-Expansion, Marketplace-Komponenten oder die Anbindung an Agentic-Commerce-Endpunkte.
Die häufigste Fehleinschätzung ist, den Proof of Concept zu überspringen und direkt mit dem MVP zu starten. Wer das tut, baut sich Architektur-Entscheidungen ein, die später nur mit Schmerzen revidierbar sind.
Fazit: Wo Medusa heute steht
Mit Version 2.0 (2024) und dem offiziellen Cloud-Angebot (2025) hat Medusa den Sprung aus dem „interessant, aber riskant"-Zustand geschafft. Enterprise-Implementierungen wie Viessmann, Makro PRO und INSPIRED Pet Nutrition belegen, dass das Framework auch unter echtem Druck trägt. Mit dem 2025 vorgestellten MCP-Server und dem Cloud Development Agent öffnet es sich aktiv für Agentic-Commerce-Anwendungen, einen Pfad, den die meisten klassischen Suites bislang nicht in vergleichbarer Tiefe anbieten.
Eine Massenlösung ist es trotzdem nicht. Wer ein flexibles, dauerhaft erweiterbares Commerce-Backend für komplexe Anforderungen sucht und das technische Team hat, um diese Freiheit zu nutzen, bekommt eines der ausgereiftesten Open-Source-Frameworks am Markt. Wer schnell verkaufen will und das Frontend nicht selbst gestalten möchte, fährt mit einer klassischen Suite besser.
Die richtige Frage lautet deshalb selten „Medusa oder Shopware?", sondern: Welche Probleme wollen wir lösen, und welches Werkzeug hat dafür die wenigsten Bruchstellen? Passen die Eignungs-Szenarien aus diesem Beitrag auf euer Geschäft, gehört Medusa auf die Shortlist. Passen sie nicht, gibt es die passenderen Werkzeuge, und auch das ist eine belastbare Erkenntnis.
Weiterführend bei nextlevels: