Medusa Deployment: Railway, Vercel oder eigener Server?

Medusa-Deployment beginnt mit einem Fakt, der die halbe Hosting-Landschaft aussortiert: Das Backend ist ein langlaufender Node.js-Server, keine Serverless-Funktion, und Medusas Deployment-Dokumentation sagt das ohne Umschweife. Dieser Vergleich nimmt die drei Ziele, die tatsächlich auf Shortlists landen (Railway, Vercel und der eigene Server), und misst sie an dem, was Medusa verlangt. Jeden Preis habe ich am 27. August 2026 an der Quelle geprüft.

Meine Interessenlage vorweg: Ich betreibe einen Medusa-Marktplatz auf Railway in Produktion – 10.000 Produkte, 50 Händler, seit dem Start ohne Infrastruktur-Zwischenfall. Einen der drei Wege kenne ich also von innen, die anderen beiden aus der Evaluation. Den Aufbau selbst beschreibt der Praxisbericht; hier geht es nur um die Deployment-Entscheidung.

Was verlangt Medusa überhaupt vom Host?

Vier Dinge, und sie filtern den Markt, bevor irgendein Preis eine Rolle spielt:

1. Einen langlaufenden Node.js-Prozess. Serverless scheidet laut Dokumentation aus.
2. Zwei Instanzen in Produktion: eine im Server-Modus für Anfragen, eine im Worker-Modus für Hintergrundjobs, umgeschaltet über MEDUSA_WORKER_MODE.
3. Mindestens 2 GB RAM; das steht wörtlich so in den Anforderungen.
4. Redis, das in Produktion vier Module trägt: Caching, Event Bus, Workflow Engine und Locking.

Mit PostgreSQL und einem S3-kompatiblen Dateispeicher besteht „Medusa deployen“ in Wahrheit aus fünf bis sechs Diensten statt aus einem.

Noch etwas, bevor Sie nach Tutorials suchen: Die offizielle Dokumentation führt derzeit nur Medusa Cloud, einen allgemeinen Self-Hosting-Leitfaden und eine Vercel-Anleitung für die Storefront. Einen eigenen Railway-Guide gab es einmal; seine alte URL leitet heute auf einen Cloud-oder-selbst-Vergleich um, der Railway nur beiläufig erwähnt. Der Railway-Weg unten ist also aus dem allgemeinen Leitfaden und meinem Produktions-Setup zusammengesetzt, nicht aus einer offiziellen Anleitung abgeschrieben – es gibt keine.

Railway: der Weg aus meiner Produktion

Railways Passung zu Medusa in einem Satz: Es betreibt langlaufende Prozesse mit sekundengenauer Abrechnung und behandelt ein Projekt aus mehreren Services als Normalfall. Der ganze Stack (Server, Worker, PostgreSQL, Redis) wohnt in einem Projekt, deployt aus einem Repository und erscheint auf einer Rechnung.

Das Setup, verdichtet auf die tragenden Schritte: PostgreSQL und Redis aus den Templates anlegen, dann zwei Services aus demselben Medusa-Repository. Der Server-Service bekommt MEDUSA_WORKER_MODE=server und liefert den Admin aus; der Worker läuft mit MEDUSA_WORKER_MODE=worker und DISABLE_MEDUSA_ADMIN=true. Beide brauchen DATABASE_URL, REDIS_URL, COOKIE_SECRET, JWT_SECRET. Den Produktions-Build erzeugt npx medusa build – laut Build-Dokumentation ein eigenständiges Bundle in .medusa/server –, und Migrationen laufen über ein Predeploy-Skript mit medusa db:migrate vor dem Start. Smoke-Test: GET /health antwortet mit OK, der Admin unter /app.

Die Kosten lassen sich schlicht ausrechnen. Railways aktuelle Sätze: 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 5 $ monatlich inklusive 5 $ Nutzung. Weil die Abrechnung dem tatsächlichen Verbrauch folgt, kostet ein Commerce-Backend mit viel Leerlauf weniger, als das Denkmodell vom provisionierten Server nahelegt: Ein kleiner Shop kommt auf etwa 15–25 $ im Monat, mein Produktions-Backend liegt bei 40–60 $ – das ist die Rechnung, die Railway tatsächlich stellt.

Zwei Erfahrungswerte, als solche markiert: Einzelne Services bauen in zwei bis drei Minuten und deployen parallel, was zehn Deploys am Tag zur Routine statt zur Heldentat macht. Und Railway liefert einen MCP-Server mit, ein KI-Coding-Agent kann Services, Deployments und Logs also direkt inspizieren – diesen Arbeitsablauf zeigt der Guide zu Medusa und KI-Agenten.

Vercel: Storefront ja, Backend nein

Vercel steht in diesem Vergleich, weil die Frage ständig kommt, und sie verdient Präzision statt Abwinken. Für das Medusa-Backend hat Vercel die falsche Form: Die Compute-Einheit ist eine Funktion mit begrenzter Laufzeit (300 Sekunden im Standard, erweiterbar auf 800), und Vercels eigene Functions-Dokumentation stellt klar, dass Functions nicht für unbegrenzte Ausführung gedacht sind. Ein Commerce-Backend mit Event Bus, geplanten Jobs und Workflow Engine ist genau die Last, die diese Annahme ausschließt; entsprechend führt Medusas Dokumentation Vercel nicht als Server-Option.

Für die Storefront empfiehlt dieselbe Dokumentation Vercel ausdrücklich: das Next.js-Frontend zum Frontend-Host, das Backend zu einem Node.js-Host. Eine Fußnote gehört in jede ehrliche Fassung dieses Rats: Vercels Hobby-Plan ist auf persönliche, nicht-kommerzielle Nutzung beschränkt; eine kommerzielle Shop-Storefront beginnt beim Pro-Plan für 20 $ im Monat inklusive 20 $ Nutzungsguthaben. Das ist ein völlig vernünftiger Posten – nur eben nicht der Gratis-Tarif, den viele annehmen.

Vercel bekommt also ein geteiltes Urteil: Die Storefront dorthin, das Backend woandershin.

Eigener Server: billigstes Blech, größtes Betriebsbudget

Die rohen Zahlen lassen den eigenen Server unschlagbar aussehen. Hetzners CX23 – 2 vCPU, 4 GB RAM, 40 GB NVMe, 20 TB Traffic inklusive – kostet 5,99 € im Monat mit IPv4-Adresse und verdoppelt Medusas 2-GB-Anforderung für einen Bruchteil einer typischen Plattform-Rechnung. Der CX33 für 8,99 € bietet 8 GB, genug für Server, Worker, PostgreSQL und Redis auf einer Maschine mit Reserve.

Der Preis, den Sie stattdessen zahlen, ist eine Stellenbeschreibung. Auf dem eigenen Server installieren und patchen Sie PostgreSQL und Redis selbst, konfigurieren Reverse Proxy und TLS, bauen die Deploy-Strecke, testen Backups und werden rausgeklingelt, wenn nachts um zwei die Platte volläuft. Für ein Team, das ohnehin Linux-Server betreibt, ist nichts davon exotisch – für so ein Team ist Hetzner eine ausgezeichnete Antwort. Für Solo-Builder oder Produktteams ohne Ops-Erfahrung tauschen die gesparten 35 € im Monat aber Stunden zu einem miserablen Kurs. Meine eigene Entscheidung für Railway statt VPS war genau dieser Tausch, bewusst getroffen: Meine Wartungsstunden sollen in den Marktplatz fließen, nicht ins Fundament.

Ein Vorbehalt, den diese Zahlen verdienen: Medusa auf einer Hetzner-Maschine habe ich nicht in Produktion betrieben. Die Preise stammen von der veröffentlichten Liste, die Betriebsbeschreibung aus dem, was Linux-Server allgemein verlangen – nicht aus dem Betrieb genau dieses Stacks dort. Railway ist der einzige Weg in diesem Artikel, für den ich von innen bürgen kann; die anderen beiden sind bepreist und bewertet, nicht gelebt.

Können Sie später wechseln?

Ja, und das senkt den Einsatz dieser ganzen Entscheidung. Medusa ist eine normale Node.js-Anwendung über PostgreSQL: Der Produktions-Build ist ein eigenständiges Bundle, die Daten sind einen Postgres-Dump entfernt, und ein S3-kompatibler Bildspeicher wie R2 funktioniert von jedem Host aus identisch. Der Umzug von Railway auf einen eigenen Server (oder zurück) ist ein Redeploy plus Datenbank-Restore, kein Migrationsprojekt; nichts in der Architektur verheiratet Sie mit der Plattform. Echte Arbeit kostet nur eine Richtung: eine verwaltete Datenbank mit anbieterspezifischen Erweiterungen zu verlassen oder den Dateispeicher selbst umzuziehen – ein gutes Argument dafür, die Bilder von Tag eins an in einem neutralen Bucket zu halten. Wählen Sie die Option, die zum Team dieses Jahres passt; die Architektur zieht nächstes Jahr mit.

Der Vergleich in einer Tabelle

Preise am 27. August 2026 geprüft, jeweils in der Währung des Anbieters. Die vierte Option – Medusa Cloud ab 29 $ im Monat – ist der verwaltete Weg, den die Dokumentation empfiehlt, wenn Sie gar keine Infrastruktur wollen; Kontrolle gegen Betrieb ist für viele Teams ein fairer Tausch.

Wann welche Option gewinnt

Railway gewinnt, wenn Backend, Worker und Datenbanken auf eine Plattform sollen, mit nutzungsbasierter Abrechnung und nahezu ohne Betriebsaufwand – meine Standardempfehlung für Solo-Builder und kleine Produktteams, belegt durch die echte Rechnung im Praxisbericht. Der eigene Server gewinnt, wenn Linux-Betrieb im Team bereits eine Kompetenz ist und Infrastrukturkosten schwerer wiegen als Infrastrukturzeit; Hetzner für 5,99 € ist der ehrliche Budget-Champion. Vercel gewinnt die Hälfte, für die es gebaut ist – die Storefront – und sollte das Backend nie tragen. Und Medusa Cloud gewinnt, wenn das Team Commerce-Logik shippen und nie über Worker-Modi nachdenken will; die Plattform dafür zu bezahlen, die Rufbereitschaft zu übernehmen, ist eine legitime Strategie und kein gescheiterter Self-Hosting-Ehrgeiz.

Die Entscheidung schrumpft auf eine Frage: Wessen Zeit pflegt das Fundament? Lautet die Antwort „niemand, den wir dafür hergeben wollen“, bleiben Sie verwaltet – Railway oder Medusa Cloud. Lautet sie „unser Ops-Team, gern“, ist die VPS-Rechnung real. Die Entscheidungen darüber hinaus – welches Shopsystem überhaupt, was der ganze Aufbau kostet – stehen im Vergleich der Open-Source-Shopsysteme und im Themenbereich E-Commerce; die englische Fassung dieses Guides gibt es hier. Und wer den eigenen Stack lieber in zwei Wochen gegen echte Anforderungen entscheidet statt in einem Kommentar-Thread: Genau dafür gibt es den PoC-Sprint.