Medusa Marketplace aufbauen: Praxisbericht aus Produktion

Wer einen Medusa Marketplace aufbauen will, findet Tutorials für die ersten dreißig Minuten und wenig über die Monate danach. Dieser Praxisbericht füllt die Lücke mit einem realen System: Medusa v2 als Commerce-Kern, 10.000 Produkte, 50 Händler, komplett selbst gehostet und seit dem Start ohne einen einzigen Infrastruktur-Zwischenfall in Betrieb.

Alle Preise und Versionen unten habe ich am 27. August 2026 an den Primärquellen geprüft. Wo eine Zahl aus meinem eigenen Betrieb stammt statt aus einer Preisliste, steht das ausdrücklich dabei – die Vermischung dieser beiden Kategorien ist der Grund, warum die meisten Kostenartikel unbrauchbar sind.

Warum Medusa v2 und nicht Shopify oder Sharetribe?

Weil ein Marktplatz an Logik hängt, die Ihnen keine SaaS-Plattform überlässt: Provisionsmodelle, Händler-Onboarding, Auftragssplitting, Auszahlungsrhythmen. Auf Medusa ist diese Logik TypeScript in meinem Repository; auf einer gemieteten Plattform ist sie ein Feature-Request. Das ist die Entscheidung in einem Satz – die längere Fassung hat zwei ehrliche Hälften.

Shopify ist die bessere Wahl für einen Standard-Katalog mit einem einzigen Verkäufer, und das schreibe ich als jemand, dessen Geschäft der Gegenentwurf ist; die Kostenrechnung Medusa vs. Shopify zieht diese Grenze in Zahlen. Sharetribe ist der schnellere Start, um eine Marktplatz-Idee ohne Code zu validieren, und Mirakl spielt in einer anderen, unternehmensgroßen Liga; mein englischer Plattformvergleich ordnet alle drei nach Umsatzgrößen ein. Medusa gewinnt, wenn der Marktplatz selbst das Produkt ist: wenn Provisionslogik, Händlerregeln und Checkout Ihr Wettbewerbsvorteil sind und Plattformgebühren auf wachsendem Umsatz sich wie eine Steuer auf den eigenen Erfolg lesen.

Wie sieht der Produktions-Stack aus?

Sechs Dienste, ein Bild: Eine Next.js-Storefront spricht mit einem Medusa-v2-Backend in zwei Prozessen (Server und Worker), dahinter PostgreSQL und Redis, die Produktbilder in Cloudflare R2, die Zahlungen bei Stripe. Die Marktplatz-Schicht über Medusa ist Mercur (MIT-Lizenz, 1.738 GitHub-Sterne am Prüftag): Händler-Panel, Auftragssplitting, Provisionen, Auszahlungen.

Die Deployment-Form folgt Medusas eigenem Produktionsleitfaden: zwei Instanzen derselben Anwendung, eine mit MEDUSA_WORKER_MODE=server für Anfragen, eine mit MEDUSA_WORKER_MODE=worker für Hintergrundjobs, und die Dokumentation nennt ausdrücklich mindestens 2 GB RAM als Voraussetzung. In Produktion stehen vier Medusa-Module hinter Redis: Caching, Event Bus, Workflow Engine und Locking.

Und wo läuft die Storefront? Medusas Dokumentation empfiehlt den Split ausdrücklich: das Next.js-Frontend zu einem Frontend-Host wie Vercel, den Medusa-Server dagegen zu einem Anbieter, der langlaufende Node.js-Prozesse betreibt, denn das Backend ist ein Server und keine Serverless-Funktion. Wer diesem Rat folgt, sollte wissen: Vercels Hobby-Plan ist auf nicht-kommerzielle Nutzung beschränkt, eine kommerzielle Storefront beginnt dort beim Pro-Plan für 20 $. Ich halte stattdessen alles auf einer Plattform. Weniger Dashboards, eine Rechnung, und bei sekundengenauer Abrechnung ist die Storefront ein Rundungsfehler neben dem Backend. Der vollständige Vergleich Railway gegen Vercel gegen VPS verdient einen eigenen Artikel: Der Deployment-Vergleich geht alle drei Wege mit geprüften Preisen durch.

Zwei Betriebsfakten von meiner Seite, klar als Erfahrung markiert und nicht als Benchmark: Einzelne Services bauen auf Railway in zwei bis drei Minuten und deployen parallel, und der Stack läuft seit dem Start ohne Infrastruktur-Zwischenfall. Railway bietet außerdem einen MCP-Server, mein KI-Setup kann die Infrastruktur also direkt inspizieren und verwalten – diesen Arbeitsablauf beschreibe ich im Guide zu Medusa und KI-Agenten.

Und wie sieht ein Deploy mechanisch aus? npx medusa build erzeugt laut Build-Dokumentation ein eigenständiges Bundle in .medusa/server, das nicht mehr von den TypeScript-Quellen abhängt und zuverlässig auf einen Produktionsserver kopiert werden kann. Der allgemeine Deployment-Leitfaden lässt Datenbankmigrationen über ein Predeploy-Skript mit medusa db:migrate vor dem Start laufen; für den Smoke-Test gibt es den Health-Endpoint unter /health und den Admin unter /app. Auf Railway ist diese ganze Sequenz ein Git-Push: Beide Medusa-Services bauen aus demselben Commit, migrieren einmal und rollen über. Ein Nebeneffekt, der Debugging-Zeit spart: Weil Server und Worker aus demselben Commit entstehen, gibt es zwischen beiden keinen Versionsdrift – ein ganzes Fehlerbild weniger.

Die Zwei-bis-drei-Minuten-Builds sind dabei wichtiger, als sie klingen. Ein Deploy, der zehnmal am Tag ohne Zeremonie läuft, macht die einzelnen Änderungen klein, und kleine Änderungen sind der Grund, warum dieser Marktplatz ohne Zwischenfälle shippt.

Was kostet ein selbst gehosteter Marktplatz wirklich?

Zuerst meine reale Summe, denn nach ihr fragt jeder: Das komplette Backend – Medusa-Server, Worker, PostgreSQL, Redis auf Railway – kostet 40–60 US-Dollar im Monat, die rund 6 GB Produktbilder in R2 unter einem Dollar. Das ist eine Produktionsrechnung für 10.000 Produkte und 50 Händler, keine Hochrechnung.

Jetzt der Hochrechnungsteil, sauber gemacht. Railway rechnet Ressourcen sekundengenau nach tatsächlichem Verbrauch ab; zum Schätzen übersetzt man die aktuellen Sätze (Stand: 27.08.2026) in Monatswerte: Arbeitsspeicher zu 0,00000386 $ pro GB-Sekunde ergibt rund 10,14 $ pro durchgehend belegtem GB und Monat, vCPU zu 0,00000772 $ pro Sekunde rund 20,29 $ pro voll genutztem Kern-Monat, Egress 0,05 $ pro GB. Der Hobby-Plan kostet 5 $ im Monat inklusive 5 $ Nutzung. Cloudflare R2 berechnet 0,015 $ pro GB-Monat bei kostenlosem Egress, und das Gratiskontingent – 10 GB Speicher, eine Million Schreib- und zehn Millionen Lesezugriffe monatlich – deckt erstaunlich viel Katalog-Bildmaterial ab.

Lesen Sie die Tabelle als das, was sie ist: Die mittlere Zeile ist eine echte Rechnung, die beiden anderen sind Arithmetik aus der Preisliste mit offengelegten Annahmen. Ihr CPU-Profil wird abweichen, und Railways sekundengenaue Abrechnung macht Leerlauf billig – genau deshalb kostet ein Marktplatz-Backend, das überwiegend auf Anfragen wartet, weniger, als das Denkmodell vom provisionierten Server vermuten lässt.

Zwei Details, die die Tabelle versteckt. Erstens die R2-Operationen: Der Erstimport eines Katalogs mit 10.000 Produkten schreibt jedes Bild genau einmal, und selbst bei mehreren Bildern pro Produkt bleibt das im Bereich einiger Zehntausend Class-A-Operationen – gegen ein Gratiskontingent von einer Million pro Monat. Die Speicherseite meiner Migration hat exakt nichts gekostet. Zweitens der Egress: R2s kostenloser Datenausgang ist strukturell, kein Lockangebot. Bildtraffic ist die eine Kostenzeile, die mit dem Marketingerfolg skaliert statt mit der Kataloggröße, und bei Anbietern, die Egress pro Gigabyte berechnen, wird sie zum klassischen Überraschungsposten. R2 berechnet dafür nichts.

Der Posten, der all das in den Schatten stellt, ist die Entwicklung. Infrastruktur für 60 $ im Monat ist Rauschen gegen Engineering-Zeit; dieses Verhältnis ist der ehrliche Kern jeder Build-oder-SaaS-Rechnung, die ich veröffentlicht habe. Wer den eigenen Fall gegen echte Zahlen testen will, bevor Monate investiert sind: Ein zweiwöchiger PoC-Sprint mit Ihrem realen Händlermodell ist der günstigste mir bekannte Weg zur Antwort.

Welche zwei Medusa-Fallen haben am meisten Zeit gekostet?

Nicht die Bugs des Frameworks, sondern seine Grenzen. Die beiden teuren Lektionen waren die Datenmigration hinein und das Prozessmodell in Produktion – beide sind vorhersehbar genug, um sie einzuplanen, und genau dafür steht dieser Abschnitt.

Falle eins: die Migration aus WordPress. Mein Marktplatz startete nicht auf Medusa, sondern auf WordPress, und den lebenden Katalog dort herauszubewegen war das größte einzelne Arbeitspaket des gesamten Projekts. Die Falle ist die strukturelle Unverträglichkeit: WooCommerce speichert Produkte als Posts mit Metadaten, lose typisiert und nachsichtig, während Medusa ein strukturiertes Modell aus Produkten, Varianten, Optionen und Preisen erwartet.

Eine Marktplatz-Migration fügt obendrein eine Dimension hinzu, die WordPress nie kannte, denn jedes der 10.000 Produkte brauchte einen Eigentümer unter den 50 Händlern. Allein diese Zuordnung rechtfertigte eine eigene Mapping-Tabelle, und die Varianten-Nachmodellierung erzwang Entscheidungen, die WooCommerce uns jahrelang erspart hatte: Welche Attributkombinationen sind echte kaufbare Varianten, und welche waren nur Beschreibungstext im Dropdown-Kostüm? Die Bilder mussten aus der WordPress-Mediathek nach R2, und eine Falle teilt jede Systemmigration: Kundenpasswörter wandern nicht mit, die Hashes sind systemspezifisch – das gehört in die Kundenkommunikation, nicht in die Bugliste.

Funktioniert hat eine gestufte Pipeline statt eines Wochenend-Skripts:

1. Katalog und Kunden aus WooCommerce exportieren.
2. Produkte, Varianten und Händlerzuordnung für Medusas Struktur nachmodellieren.
3. In Chargen importieren, Bilder direkt nach R2.
4. Parallellauf mit Testbestellungen, erst dann den Traffic umschalten.

Nichts davon ist exotisches Engineering, aber es ist ein Projekt mit eigenem Zeitplan und kein Import-Button. Es ist der Hauptgrund, warum meine ehrliche Antwort auf „Wie lange bis Produktion?“ eine Spanne ist: wenige Wochen im besten Fall, Monate, wenn sich Integrationen und Datenarbeit stapeln.

Falle zwei: Der Worker-Mode ist keine Option, sondern Pflicht. Medusas Deployment-Dokumentation beschreibt einen Split, den die Community auf die harte Tour lernt: eine Instanz mit MEDUSA_WORKER_MODE=server, eine zweite mit MEDUSA_WORKER_MODE=worker und DISABLE_MEDUSA_ADMIN=true, dazu Redis für Caching, Event Bus, Workflow Engine und Locking. Eine einzelne Instanz wirkt in der Entwicklung funktionstüchtig und degradiert dann in Produktion, weil Hintergrundjobs – Bildverarbeitung, Event-Subscriber, geplante Workflows – mit Kundenanfragen um denselben Prozess konkurrieren. Auf Railway ist der Split schlicht: zwei Services aus demselben Repository mit unterschiedlichen Umgebungsvariablen. Die 2-GB-RAM-Untergrenze der Dokumentation ist real, und sie von Anfang an pro Instanz zu budgetieren ist billiger, als sie unter Last zu entdecken.

Wie viel bringt der KI-Workflow wirklich?

Genug, dass ich ihn zum Stack zähle. Mit Produktivitätsprozenten schmücke ich das nicht, denn ein kontrolliertes Experiment habe ich beim Bau eines Marktplatzes nicht nebenher laufen lassen. Berichten kann ich die Form der Arbeit. Zwei MCP-Server sitzen in meiner Coding-Umgebung: der von Railway, über den der Agent Services, Deployments und Logs direkt inspiziert, statt dass ich sie ihm nacherzähle, und der von GitHub für die Repository-Seite. Medusa kommt dem Agenten von der anderen Richtung entgegen, mit offiziellem MCP-Server und installierbaren Agent Skills – ungewöhnlich unter Commerce-Frameworks und der Grund, warum das KI-Tooling einen eigenen Artikel auf diesem Blog hat.

Der unglamouröse Gewinn ist die Dokumentation: Interne Docs für einen Stack aus sechs Diensten zu erzeugen und zu pflegen wurde von einer aufgeschobenen Pflicht zu einem Nebeneffekt der Arbeit. Der vollständige Einblick in den Claude-Code-Workflow (EN) dahinter ist inzwischen ein eigener Artikel; die ehrliche Vorschau: Infrastruktur-bewusste Agenten haben meine tägliche Geschwindigkeit stärker verändert als jede Code-Vervollständigung davor.

Was würde ich anders machen – und wann ist Medusa die falsche Wahl?

Drei Änderungen, wenn ich heute starten würde. Ich würde den Server/Worker-Split vom ersten Deploy an fahren, statt ihn als Produktionsdetail zu behandeln. Ich würde die WordPress-Migration als eigene Projektphase mit eigener Deadline budgetieren, denn „die Daten ziehen wir nebenbei um“ ist die Formel, mit der Wochen verschwinden. Und ich würde das KI-Tooling früher verdrahten – der Railway-MCP-Server plus Medusas Agent Skills haben meine tägliche Entwicklungsgeschwindigkeit so verändert, dass ich sie inzwischen zum Stack zähle, nicht zum Zubehör.

Und der Ehrlichkeitsabsatz, den dieser Blog jedem Leser schuldet: Medusa ist die falsche Wahl, wenn Katalog und Checkout dem Standard entsprechen und keine Entwicklerkapazität existiert. Dann ist SaaS in jedem von mir durchgerechneten Szenario günstiger, und den Abschnitt „Wann Shopify die richtige Wahl ist“ gibt es in meinem Vergleich genau deshalb. Medusa verdient seinen Platz, wenn individuelle Logik das Produkt ist – ein Marktplatz mit eigenem Provisionsmodell ist der Lehrbuchfall. Eine Produktionsreife-Checkliste aus diesem Projekt entsteht gerade als Download-Begleiter; bis dahin zeigt der Marktplatz-Leitfaden die operative Seite, und den größeren Systemüberblick liefert mein Vergleich der Open-Source-Shopsysteme.

Wenn Sie dort stehen, wo ich stand – besitzen oder mieten? –, dann buchen Sie ein Gespräch und bringen Sie Ihr Händlermodell mit; dreißig Minuten gegen echte Zahlen schlagen eine weitere Woche Tab-Sammeln. Alle Artikel der Serie sammelt der Themenbereich E-Commerce, die englische Fassung dieses Praxisberichts steht hier, und was KI-Agenten im Shop-Betrieb leisten, zeigt der E-Commerce-Branchenbereich.