Medusa self-hosted auf Hetzner: TCO und Datensouveränität ehrlich gerechnet

Der größte Kostenblock im E-Commerce steht in keinem Angebot einer SaaS-Plattform als Zeile: die Transaktionsgebühr, die mit jedem Euro Umsatz mitwächst. Wer sie ernst nimmt, kommt bei einem PostgreSQL-nativen Stack wie Medusa heraus, den man vollständig selbst betreibt.

Medusa ist Open-Source unter MIT-Lizenz und erhebt als Software keine Umsatz- oder Transaktionsgebühr. Es fallen nur Infrastruktur- und Payment-Provider-Kosten an. Das klingt nach einer Detailfrage der Buchhaltung, ist aber eine strategische Weichenstellung: Du entscheidest damit, ob deine Kostenkurve mit dem Umsatz nach oben zieht oder ob sie flach bleibt und pro Bestellung sogar sinkt.

Und du entscheidest, wo deine Bestell- und Kundendaten liegen – in einer selbst kontrollierten Datenbank in Deutschland oder bei einem US-Anbieter. Beide Fragen hängen zusammen, und beide beantwortest du am ehrlichsten mit einer echten Rechnung statt mit einem Versprechen.

Fangen wir mit der Realität des Betriebs an, nicht mit dem Marketing. Ein produktiver Medusa-Stack braucht zwingend zwei Datenbanken: PostgreSQL als Commerce-Store und Redis für Cache, Event Bus, Locking und die Workflow-Engine. Der offizielle Docker-Guide referenziert postgres:15-alpine und redis:7-alpine auf einem node:20-alpine-Basisimage. Das ist kein exotischer Stack, sondern Standardhandwerk, das jeder Ops-Mensch kennt.

Dazu kommt eine Eigenheit, die viele beim ersten TCO-Vergleich übersehen: Medusa muss in Produktion in zwei Modi laufen. Der Server-Modus bedient API und Admin, der Worker-Modus arbeitet Background-Jobs und Subscriber ab, gesteuert über MEDUSA_WORKER_MODE. Beide Prozesse brauchen dieselben Secrets und dieselbe Datenbankverbindung. Die offizielle Empfehlung liegt bei mindestens 2 GB RAM und Node.js v20+ als LTS.

Für diese Anforderung ist ein Hetzner AX41 für rund 39 €/Monat kein Kompromiss, sondern großzügig dimensioniert. Er trägt PostgreSQL, Redis, beide Medusa-Prozesse und die Next.js-Storefront mit Reserve. Wir orchestrieren das über Coolify und Docker – Coolify ist bei Medusa nur über Community-Guides dokumentiert, nicht offiziell, aber das Muster ist geradlinig: Container definieren, Predeploy-Migration via medusa db:migrate, deployen. Offiziell dokumentiert ist als Deployment-Ziel Railway; wer die Kontrolle über die eigene Maschine will, landet aber bei einem Root-Server.

Jetzt die Zahlen, und zwar ehrlich mit Bandbreite statt mit erfundener Präzision. Eine saubere Erstimplementierung eines self-hosted Medusa-Stacks liegt einmalig bei 5.000–20.000 €, je nach Individualisierung von Storefront, Modulen und Integrationen. Der laufende Betrieb kostet realistisch 2–5 Stunden pro Monat an Wartung – Updates, Monitoring, Backups prüfen.

Bei einem Mischsatz von rund 120 € pro Entwicklerstunde und der Infrastruktur landet ein mittelständischer Shop im 3-Jahres-Gesamtbild bei etwa 40.000–80.000 €. Das ist der ehrliche TCO, inklusive der Stunden, die viele Rechnungen unterschlagen.

Dem stellst du die SaaS-Seite gegenüber. Shopify Plus startet laut offizieller Preisseite (Stand Juli 2026, in EUR geolokalisiert) bei 2.250 €/Monat im 1-Jahres-Term beziehungsweise 2.100 €/Monat bei 3 Jahren – als reine Base-Fee. Das sind über drei Jahre grob 75.000–81.000 € allein an Grundgebühr, bevor eine einzige Transaktionsgebühr anfällt.

Genau die ist der Punkt: Nutzt du einen Fremd-PSP, zahlst du dessen Gebühr plus 0,20 % pro Transaktion an Shopify. Mit Shopify Payments entfällt dieser Aufschlag, dafür bindest du dich an ein Gateway. Die vollständige Rechnung mit allen Fußnoten haben wir im direkten Vergleich Medusa gegen Shopify Plus aufgemacht.

Der entscheidende Effekt ist die Richtung der Kurven. Self-hosted Fixkosten sind weitgehend konstant; pro Bestellung sinken sie mit steigendem Volumen. Umsatzabhängige SaaS-Gebühren tun das Gegenteil: Sie explodieren mit dem Erfolg. Bei niedrigem GMV liegt Managed vorn, weil die Grundlast erdrückend wirkt. Ab einem bestimmten Umsatz kreuzen sich die Linien, und danach zahlst du bei SaaS für deinen eigenen Erfolg.

Dieselbe Mechanik wiederholt sich über die Anbieter hinweg, von der Datenbank bis zum Commerce-Backend: konstante Infrastruktur gegen Managed-Gebühren, die mit dem Verbrauch skalieren.

TCO ist die eine Hälfte der Entscheidung, die andere ist Kontrolle. Bei Self-Hosting liegen Bestellungen, Kundenprofile und die gesamte PII in einer PostgreSQL-Instanz, die du kontrollierst, in einem Rechenzentrum, das du wählst – bei Hetzner also in Deutschland.

Für die Kerndaten deines Shops gibt es damit keinen Drittstaatentransfer, keine Diskussion über den CLOUD Act, keine Abhängigkeit von der jeweils aktuellen Rechtslage zum transatlantischen Datenverkehr. Das ist Datensouveränität E-Commerce im wörtlichen Sinn: Die Daten verlassen deinen Kontrollbereich nicht.

Ehrlich bleibt: Vollständig entkommt niemand externen Verarbeitern. Zahlungsdaten liegen beim Payment-Provider. Mit dem Stripe-Provider berühren Kartendaten den Medusa-Server nicht – die Eingabe läuft clientseitig über Stripe Elements, das Backend erhält nur Tokens und Payment-Intents. Das qualifiziert die Kartenverarbeitung nach PCI-DSS-Logik in der Regel für den kleinsten Fragebogen, SAQ A, sofern du selbst keine Kartendaten speicherst oder überträgst.

Die konkrete Einstufung hängt von der Integrationsart ab, und beim self-hosted Betrieb bleibst du für Scoping, jährliche Attestierung und Serverabsicherung selbst verantwortlich. Für Stripe und jedes externe Modul (Analytics, File-Storage, Notifications) brauchst du einen AVV. Das ist eine architektonische Einordnung, keine Rechtsberatung.

Warum das mehr ist als eine Compliance-Fußnote, haben wir in Sind unsere Daten in den USA noch sicher? ausführlicher begründet. Die Kurzfassung: Wer die Kerndaten seines Geschäfts auf fremder Infrastruktur in einem Drittstaat hält, kauft sich ein Risiko ein, das keine Preisliste ausweist – und das im Ernstfall teurer wird als jede Transaktionsgebühr. Ein DSGVO Shop, dessen Datenhaltung du selbst verantwortest, ist kein Ideologieprojekt, sondern gelebtes Vendor-Risk-Management.

Jetzt der Teil, den die Souveränitäts-Rhetorik gern überspringt. Ein Shop ist keine interne Anwendung, bei der ein Ausfall am Freitagabend niemanden stört. Ausfall heißt kein Verkauf. Jede Minute Downtime ist unmittelbar entgangener Umsatz, und die Verantwortung dafür trägst du, nicht ein SLA von Shopify.

Das hat konkrete Folgen. Sale-Traffic-Spitzen (Black Friday, ein erfolgreicher Newsletter, ein viraler Moment) musst du selbst abfangen. Uptime-Monitoring, Failover, Backup-Restore-Tests, Security-Patching von Node, PostgreSQL und Redis: All das liegt bei dir. Payment bringt zusätzlich PCI-Scope, den du aktiv managen musst.

Ein einzelner AX41 ist für den Normalbetrieb großzügig, aber ein Single Point of Failure; echte Resilienz bedeutet Redundanz, separate Datenbank, Read-Replicas – und die kostet. Ein hochverfügbares Setup liegt eher bei 150–400 €/Monat statt bei 39 €.

Deshalb ist die Ersparnis kein Automatismus. Sie ist nur echt, wenn zwei Bedingungen erfüllt sind. Erstens: Es gibt Ops-Kompetenz im Haus oder bei einem verlässlichen Partner – jemanden, der um drei Uhr nachts weiß, warum der Worker-Prozess hängt. Zweitens: Die eigenen Stunden sind ehrlich eingepreist.

Wer den Betrieb als „macht der Kollege nebenbei" verbucht, vergleicht eine geschönte Self-Hosting-Rechnung mit einer vollständigen SaaS-Rechnung und wundert sich später. Für einen einfachen Standard-B2C-Katalog ohne dediziertes Team ist der Baukasten schlicht überdimensioniert; da ist Managed die vernünftige Wahl.

Rechne den Break-even mit deinen echten Zahlen, nicht mit einem Foliensatz. Nimm deinen erwarteten GMV der nächsten drei Jahre, trag die umsatzabhängigen Gebühren als steigende Kurve ein und stell die flache Self-Hosting-Linie daneben – inklusive Setup, Wartungsstunden zum vollen Satz und der 150–400 €/Monat für ein resilientes Setup, nicht nur der 39 € für die Bastelmaschine. Der Kreuzungspunkt ist deine Entscheidungsgrenze, und er liegt für jeden anders.

Liegst du oberhalb dieser Grenze und ist die Ops-Kompetenz vorhanden, ist der Fall klar: Medusa ist PostgreSQL-nativ, vollständig self-hostbar und läuft auf Hetzner mit Coolify und Docker DSGVO-konform in Deutschland. Du sparst die Transaktionsgebühr, die mit deinem Erfolg wächst, und du behältst deine Bestell- und Kundendaten unter eigener Kontrolle.

Liegst du darunter oder fehlt das Team, ist Managed die ehrlichere Antwort – kein Gesichtsverlust, sondern Betriebsökonomie. Die technische Tiefe zu Architektur, Modulen und Workflows, die diese Souveränität überhaupt tragbar macht, findest du in unserer Pillar-Übersicht zu Medusa als Headless-Commerce-Plattform.

Die eigentliche Frage ist nicht „Self-hosted oder SaaS?", sondern: Willst du, dass deine Kostenkurve und deine Datenhoheit dem Interesse deines Dienstleisters folgen – oder deinem eigenen? Wer diese Frage nicht stellt, hat sie trotzdem beantwortet.

Du willst wissen, wo dein Kreuzungspunkt liegt? Dann rechnen wir das gemeinsam durch: mit deinem GMV, deinem Team und deinem Stack. Buch dir ein unverbindliches Erstgespräch, und wir klären ehrlich, ob Self-Hosting bei dir trägt oder Managed die bessere Antwort bleibt.