Ein Kunde rief mich letzten Oktober in leichter Panik an. Sie hatten ihre gesamte Marketing-Plattform auf einem gehosteten CMS aufgebaut und der Anbieter hatte gerade eine Preisumstrukturierung angekündigt. Über Nacht stieg ihre Rechnung von 180 £/Monat auf über 900 £. Der Content war nicht komplex. Ein Blog, ein Produktkatalog, vielleicht vierzig Custom Fields über drei Collections verteilt. Nichts, das diese Summe rechtfertigte. Dieser Anruf ist der Grund, warum ich die nächsten drei Monate damit verbrachte, zwei Seahawk-Projekte zu Payload CMS zu migrieren und ein vernünftiges Kostenmodell dafür zu entwickeln.
Lass mich dir erzählen, was ich wirklich herausgefunden habe.
Was Payload CMS wirklich ist (und nicht ist)
Payload ist ein TypeScript-erstes, code-getriebenes Headless CMS. Du definierst deine Collections, Globals und Fields komplett in Konfigurationsdateien. Keine GUI zum Herumklicken für das Schema-Design. Das Admin-Panel wird aus deinem Code generiert, nicht umgekehrt. Diese Umkehrung ist der ganze Sinn – und sie wird dich auch stolpern lassen, wenn du von WordPress oder Contentful kommst.
Es ist keine SaaS. Es gibt keinen Payload-gehosteten Service, für den du monatlich zahlst. Du hast die vollständige Kontrolle über die Bereitstellung. Das ist je nach Situation ein Feature und eine Einschränkung.
Payload 2.0 wurde mit vollständiger PostgreSQL-Unterstützung neben MongoDB ausgeliefert – das war der Durchbruch, der es wirklich machbar machte für Clients, die relationale Daten ohne NoSQL-Kunststücke wollen. Anfang 2026 ist das Ökosystem drum herum reif genug, dass ich es für Produktion empfehlen kann, ohne die Vorbehalte, die ich früher anfügen musste.
Worauf es wirklich aufgebaut ist
Unter der Haube: Next.js 15 für die Admin-UI, TypeScript überall, und deine Wahl zwischen Drizzle ORM (für Postgres) oder Mongoose (für MongoDB). Die REST- und GraphQL-APIs werden aus deinem Schema auto-generiert. Du bekommst auch eine lokale API für serverseitige Anfragen, die auf eine Weise schnell ist, die mich jedes Mal noch überrascht.
Wo es 2026 passt
Ehrlich gesagt sitzt Payload in einer bestimmten Nische. Nicht jedes Projekt gehört dort hin. Nach dem Betrieb auf einem Dutzend Builds bei Seahawk habe ich folgendes Muster bemerkt.
Es ist ein guter Fit, wenn:
- Das Projekt ist von Anfang an developer-led. Das bedeutet, ein echter Engineer konfiguriert es, nicht ein Client, dem man gesagt hat, sie könnten „alles selbst verwalten".
- Du brauchst Custom-Field-Logik, bedingte Fields oder komplexe Beziehungsketten, die dich bei etwas wie Contentful teuer zu stehen kämen.
- Der Client ist kostenorientiert über einen Horizont von 2-3 Jahren. Die Rechnung schlägt fast immer zugunsten von Payload nach Monat 14 aus.
- Du betreibst bereits eine Next.js- oder Node-Anwendung und möchtest das CMS co-located oder zumindest infrastruktur-mäßig geteilt.
Es ist ein schlechter Fit, wenn:
- Der Client braucht eine nicht-technische Person, um neue Content Types ohne Engineering-Support zu erstellen.
- Du baust etwas, das komplett abgegeben werden muss und der Empfänger hat keinen Developer im Team.
- Der Launch steht in weniger als zwei Wochen an und du hast kein Payload-Projekt-Gerüst zum Klonen bereit.
Den zweiten Punkt habe ich auf die harte Tour gelernt. 2022 habe ich eine kleine Charity-Website mit Payload (damals v1) geplant. Der Plan war, sie an ihren internen Volunteer Coordinator zu übergeben. Drei Monate später beantwortete ich noch immer WhatsApp-Nachrichten, warum das Feld nicht angezeigt wurde. Das CMS war technisch nicht falsch für das Projekt. Es war falsch für das Übergabe-Modell.
Die echten Kosten für die Ausführung von Payload im Jahr 2026
Das ist der Teil, den die meisten Blog-Posts auslassen oder mit vagen Bandbreiten aufhübschen. Hier gebe ich dir echte Zahlen von dem, was ich betrieben habe.
Infrastruktur
Du brauchst irgendwo, um den Node-Server zu hosten, und irgendwo, um deine Datenbank zu speichern. Das sind deine zwei Hardkosten.
Option A: Railway Ich nutze Railway für die meisten Payload-Projekte bei mittlerem Traffic. Eine typische Payload-App (Node-Service + Postgres-Instanz) kostet zwischen 12 und 35 Euro pro Monat je nach Nutzung. Für eine Marketing-Website mit redaktionellen Inhalten bist du fast sicher im 15–20-Euro-Band. Deploys laufen unkompliziert aus einem GitHub-Repo, und die Postgres-Backups sind automatisch.
Option B: Render Ähnliche Preisgestaltung wie Railway. Ein kostenloses Tier existiert, aber nutze es nicht für die Produktion (Cold Starts werden dich vor Clients blamieren). Bezahlte Pläne beginnen bei 7 Euro pro Monat für den Web-Service plus 7 Euro pro Monat für das verwaltete Postgres. Also ~14 Euro pro Monat Minimum, skalierend mit CPU und Speicher, wenn der Traffic wächst.
Option C: Selbstverwalteter VPS Bei mehreren Payload-Projekten wird ein DigitalOcean- oder Hetzner-VPS attraktiv. Ein Hetzner CX32 (4 vCPU, 8 GB RAM) kostet 8,29 Euro pro Monat und kann drei bis vier Payload-Instanzen hinter einem Nginx-Proxy komfortabel ausführen. Ich betreibe eine gemeinsame Postgres-Instanz auf derselben Box für kleinere Clients. Nicht für schwache Nerven, aber völlig stabil.
Medienspeicher
Payload verwaltet deine Bilder nicht automatisch, es sei denn, du konfigurierst einen Storage-Adapter. Die beiden, die ich in der Produktion genutzt habe:
- AWS S3 + CloudFront für alles im größeren Maßstab. Rechne mit etwa 5–15 Euro pro Monat für eine typische Marketing-Website.
- Cloudflare R2 als S3-kompatibler Speicher ohne Egress-Gebühren. Das ist jetzt mein Standard. Für eine Website mit ~50 GB Medien-Assets zahle ich praktisch nichts für Egress und etwa 1,50 Euro pro Monat für Storage. Nutze das payload-cloud-storage-Plugin und richte es auf R2 aus.
Entwicklerzeit (der Kostenfaktor, den Leute vergessen)
Initiales Setup eines Payload-Projekts, richtig mit Auth, Media, den Collections, die dein Client braucht, und einem vernünftigen Access-Control-Modell: Budget 12–20 Stunden für einen erfahrenen Entwickler. Das ist keine optionale Komplexität, das ist einfach die Natur eines Code-First-CMS. Bei einem Tagessatz von £400–600 (London Mid-Market Freelancer) sind das £4.800–12.000 vor der ersten Frontend-Codezeile.
Vergleich das damit, einen Contentful-Space in 3 Stunden über ihre UI zu konfigurieren. Die Initialkosten sind real. Bei den laufenden Kosten gewinnt Payload.
Gesamtbetriebskosten, Jahr 1 gegenüber Jahr 3
Hier ist ein grobe Modellrechnung für eine mittlere Marketing-Website und vergleicht Payload auf Railway mit Contentfuls Growth-Plan:
- Payload auf Railway, Jahr 1: £18/Monat Infra + ~£5.000 Setup-Zeit = ~£5.216 insgesamt
- Payload auf Railway, Jahr 3: £18/Monat Infra + minimale Wartung = ~£648 Infra über Jahr 3
- Contentful Growth-Plan, Jahr 1: £320/Monat = £3.840, ohne Custom-Setup-Kosten
- Contentful Growth-Plan, Jahr 3: £320/Monat = £3.840 erneut
Der Wendepunkt liegt irgendwo zwischen Monat 20–22, je nach deinem Tagessatz. Danach ist Payload substanziell günstiger. Für einen Client, der dieselbe Website 2028 noch betreiben wird, ist das relevant.
Die Developer Experience in ehrlichen Worten
Ich arbeite wirklich gerne mit Payload. Der Config-as-Code-Ansatz bedeutet, dass dein Schema versionskontrolliert ist, in Pull Requests überprüft werden kann und sich wie jede andere Code-Änderung deployen lässt. Das allein stellt es bereits vor CMS-Tools in den Schatten, bei denen ein Content-Modeller in einer GUI herumklickt und niemand wirklich weiß, was sich geändert hat oder wann.
Die TypeScript-Inferenz ist hervorragend. Deine Collection-Typen fließen direkt in deine lokalen API-Abfragen, ohne dass du einen separaten Typ-Generierungsschritt durchführen musst. Seahawk hatte letztes Jahr ein Fintech-Content-Projekt, bei dem wir tiefe verschachtelte Relationship-Daten abgefragt haben, und die Typsicherheit hat zwei Daten-Shape-Bugs gefunden, bevor sie jemals in Staging landeten. Das ist nicht nichts.
Die Admin-UI ist sauber und schnell. Nicht glänzend, nur funktional. Nicht-technische Editoren werden sich normalerweise innerhalb von ein oder zwei Sessions damit vertraut machen, sobald die Felder gut beschriftet sind. Hooks sind das andere, das ich hervorheben möchte: before-change, after-read und ähnliche Lifecycle-Hooks ermöglichen es dir, Dinge auf der Data-Layer zu tun, die du sonst als Custom-API-Middleware bauen müsstest.
Die rauen Kanten
Migrationen. Falls du Postgres nutzt und dein Schema änderst, musst du Drizzle-Migrationen ausführen. Das ist in Ordnung, wenn du weißt, was du tust, und mildtätig angespannt, wenn du das nicht tust. Ich habe gesehen, wie ein Junior-Dev bei einem Seahawk-Subauftrag eine Spalte gelöscht hat, weil er den Migration-Diff nicht sorgfältig gelesen hat. Immer überprüfen, immer vorher sichern.
Das Plugin-Ökosystem ist kleiner als WordPress, offensichtlich. Aber das Payload-Plugin-Verzeichnis ist bedeutsam gewachsen. Form Builder, verschachtelte Docs, SEO-Felder, Weiterleitungen. Die wichtigen Basics sind abgedeckt. Du wirst trotzdem mehr Custom Code schreiben als auf einer etablierteren Plattform.
Wie es sich zu den anderen Headless-Optionen verhält
Lass mich deutlich sein, wo ich mich für etwas anderes entscheiden würde.
Sanity.io, wenn dein Content-Team groß ist und nicht-technische Editoren ihre eigenen Content-Strukturen erstellen. Sanity's Studio ist benutzerfreundlicher für diese Zielgruppe, das gehostete Backend ist zuverlässig, und die GROQ-Abfragesprache macht echten Spaß beim Schreiben. Du zahlst $99+/Monat bei einem echten Plan, aber für manche Kunden lohnt sich das.
Strapi war jahrelang die Payload-Alternative. Es ist immer noch brauchbar und das Self-Hosted-Modell ist ähnlich, aber ich finde die TypeScript-Erfahrung schwerfälliger und der Upgrade-Pfad zwischen Major Versions war historisch schmerzhaft. Payload's Codebase fühlt sich für mich absichtlicher an.
WordPress mit ACF oder ein Block-basiertes Setup für alles, das an einen nicht-technischen Betreuer übergeben werden muss, der sich bereits mit WordPress auskennt. Immer noch die richtige Antwort für große Teile dessen, was Agenturen bauen. Lass dich von niemandem etwas anderes erzählen.
Directus als dunkles Pferd, das sich einen Blick lohnt, besonders wenn du mit einem bestehenden Datenbankschema arbeitest, das du mit einem CMS umhüllen musst. Andere Philosophie als Payload, aber wirklich gut für diesen spezifischen Job.
FAQ
Ist Payload CMS kostenlos zu nutzen?
Ja. Payload ist Open-Source unter der MIT-Lizenz. Es gibt keine Lizenzgebühr. Du zahlst für deine eigene Hosting-Infrastruktur, was der Kompromiss gegenüber einem gehosteten SaaS-CMS ist.
Können nicht-technische Clients das Admin-Panel von Payload nutzen?
Mit gut beschrifteten Feldern, vernünftigen Defaults und etwas grundlegender Schulung, ja. Die Admin-UI ist sauber genug, dass Editoren sie relativ schnell aufgreifen. Was sie nicht können, ist neue Collections erstellen oder das Schema ohne einen Developer ändern. Das ist eine harte Beschränkung aus Designgründen.
Funktioniert Payload mit Next.js?
Ja, und besonders gut. Payload 2.x wurde auf Next.js neu aufgebaut, daher kannst du das CMS und dein Frontend aus derselben Next.js-App ausführen. Dieses „Monorepo in einem einzigen Repo"-Setup funktioniert gut für kleine bis mittelgroße Projekte und reduziert deinen Infrastruktur-Overhead.
Welche Datenbank sollte ich mit Payload nutzen?
Für neue Projekte 2026 setze ich standardmäßig auf PostgreSQL via Drizzle ORM. Es ist gut getestet, du bekommst richtige relationale Constraints, und die Migration-Tools sind solide, wenn sie sorgfältig genutzt werden. MongoDB bleibt eine Option und ist immer noch eine gute Wahl, wenn deine Daten von Natur aus dokumentförmig sind, aber Postgres ist meine erste Empfehlung.
Wie handhabt Payload Media-Uploads?
Standardmäßig speichert Payload Uploads lokal im Server-Dateisystem, was für die Entwicklung in Ordnung ist, aber nicht für Production. Für Production solltest du einen Storage-Adapter konfigurieren, der auf S3, Cloudflare R2 oder ähnliches zeigt. Das offizielle @payloadcms/plugin-cloud-storage-Paket handhabt das und dauert beim ersten Mal etwa eine Stunde zum ordnungsgemäßen Einrichten.
Ist Payload bereit für große Production-Sites?
Es läuft mit ernsthaftem Produktionsverkehr bei einer Reihe von Unternehmen. Das heißt aber nicht, dass ich es für eine Website mit 10 Millionen monatlichen Besuchern und einem 20-köpfigen Redaktionsteam wählen würde. In diesem Maßstab brauchst du Enterprise-Lösungen mit dedizierten Support-Verträgen. Für die agenturgebauten Mittelmarkt-Projekte, die den Großteil unserer Seahawk-Arbeit ausmachen, ist Payload stabil und leistungsfähig.
Die ehrliche Einschätzung
Payload CMS 2026 ist ein ausgereiftes, gut konstruiertes Tool für Entwickler-geführte Projekte, wo langfristige Kosten wichtig sind und du die technische Kapazität hast, den Stack selbst zu verwalten. Die anfängliche Investition in Setup-Zeit ist real. Die laufenden Infrastrukturkosten sind niedrig. Die Developer Experience ist gut.
Es ist kein WordPress-Ersatz. Das versucht es auch gar nicht zu sein. Aber für das richtige Projekt, mit dem richtigen Team, ist es die kostengünstigste Headless-CMS-Option, die ich bei über 12.000 Projekten nutzen konnte. Die Frage ist nicht, ob es gut ist. Die Frage ist, ob es für deine Situation gut ist.