Die Headless-CMS-Landschaft hat sich 2026 in zwei Lager sortiert: Content-as-a-Service-Plattformen, die Inhalte in ihrer Cloud verwalten (Contentful, Sanity, Storyblok), und selbst betriebene Systeme, bei denen Daten und Laufzeit im eigenen Haus bleiben. Payload ist der prominenteste Vertreter einer dritten, jüngeren Idee: Das CMS ist kein separates System mehr, sondern Teil der Anwendung selbst – im selben Repository, im selben Deployment, in derselben Sprache. Für Entscheider ist das mehr als ein Entwickler-Komfortmerkmal: Es verändert Kostenstruktur, Datenhoheit und Betriebsmodell.
Was Payload technisch anders macht
Drei Architektur-Entscheidungen prägen Payload – und erklären, warum es sich so schnell im Next.js-Ökosystem etabliert hat:
- Config-as-Code: Collections, Felder, Validierungen und Zugriffsregeln werden als TypeScript-Konfiguration definiert – nicht zusammengeklickt. Das Datenmodell liegt im Git-Repository, durchläuft Code-Review und CI/CD und ist zwischen Umgebungen reproduzierbar. Für Governance-Prozesse ist das ein fundamentaler Unterschied zu Klick-Konfiguration: Jede Schemaänderung ist nachvollziehbar, testbar und rückrollbar.
- Next.js-nativ seit Version 3: Payload installiert sich in die Next.js-Anwendung hinein. Admin-Panel, APIs und Website teilen sich ein Deployment; die Local API erlaubt Datenzugriffe ohne HTTP-Umweg direkt im Server-Rendering. Praktisch heißt das: ein Repository, eine Pipeline, ein Hosting – statt CMS-Instanz plus Frontend plus Synchronisation.
- Ihre Datenbank statt Content-Cloud: Inhalte liegen in PostgreSQL (oder MongoDB) auf Ihrer Infrastruktur. Backups, Verschlüsselung, Aufbewahrung und Löschkonzepte folgen Ihren Regeln – nicht den Vertragsbedingungen eines Content-SaaS.
Welche Produkte ersetzt Payload CMS?
Payload besetzt die Schnittmenge aus Headless-CMS, Anwendungs-Backend und Admin-Framework. Je nach Ausgangslage ersetzt es damit unterschiedliche Systeme:
| System | Modell | Wann Payload die Alternative ist |
|---|---|---|
| Strapi | Open-Source-Headless-CMS (Node.js), Open Core | wenn TypeScript-Ende-zu-Ende, Next.js-Integration und Features ohne Enterprise-Gating gewünscht sind |
| Directus | datenbanknahes Open-Source-CMS/Backend | wenn das Datenmodell im Code statt in der Datenbank-UI leben soll |
| Contentful / Content-SaaS | Content-as-a-Service, nutzungs-/platzbasierte Tarife | wenn Abokosten, Datenhoheit oder API-Limits gegen die Cloud sprechen |
| WordPress + ACF (headless) | PHP-Ökosystem mit Feld-Plugins | wenn der PHP/Plugin-Stack einem typisierten TypeScript-Stack weichen soll |
| CMS-/Admin-Eigenbau | individuelles Backend mit Admin-UI | Payload ersetzt den Eigenbau: Admin, Auth und CRUD sind gelöst, Ihre Logik kommt als Hooks und Endpoints dazu |
| Firebase/Backend-Baukasten für Content-Apps | BaaS-Datenhaltung ohne Redaktions-UI | wenn Inhalte ein echtes Redaktions-Interface mit Rollen und Freigaben brauchen |
Bemerkenswert ist die letzte Zeile der Tabelle: Weil Payload Authentifizierung, Rollen und Zugriffskontrolle im Kern mitbringt, ersetzt es in vielen Projekten nicht nur das CMS, sondern auch das halbe Anwendungs-Backend – Kundenportale, Mitgliederbereiche oder interne Tools entstehen auf derselben Basis wie der Content.
Die Vorteile eines Code-first Open-Source-CMS
- Keine Lizenz- und keine Content-SaaS-Kosten: Die MIT-Lizenz kennt kein Feature-Gating – Localization, Versionierung, Auth und Zugriffskontrolle kosten nichts extra. Die Kostenkurve hängt an Ihrer Infrastruktur, nicht an Einträgen, API-Calls oder Redaktionsplätzen.
- Datenhoheit als Architektur: Inhalte, Nutzer und Medien liegen in Ihrer Datenbank auf EU-Infrastruktur. DSGVO-Fragen (Speicherort, Auftragsverarbeitung, Löschkonzepte) beantwortet die Architektur, nicht ein Vertragsanhang.
- Ein Stack, ein Deployment: CMS und Anwendung teilen sich TypeScript, Repository und Pipeline. Das reduziert Schnittstellen, Deployments und die Zahl der Systeme, die ein Team beherrschen muss.
- Erweiterbarkeit ohne Plattformgrenzen: Hooks, eigene Endpoints, eigene React-Komponenten im Admin – Geschäftslogik wird Teil des Systems statt Workaround daneben.
- Exit-Sicherheit: Standard-PostgreSQL plus MIT-Code im eigenen Repository – es gibt schlicht keinen Anbieter, der Ihnen den Betrieb entziehen oder Konditionen diktieren könnte.
- Auth inklusive: Login, Rollen, API-Keys und feldgenaue Zugriffsregeln gehören zum Kern – für viele Projekte entfällt ein separates Auth-System (die Abgrenzung zu vollwertigem IAM weiter unten).
Die Figma-Übernahme: Was sie für Entscheider bedeutet
2025 hat Figma Payload übernommen – für ein Open-Source-Projekt dieser Größe ein einschneidendes Ereignis, das in Auswahlprozessen zu Recht hinterfragt wird. Die nüchterne Einordnung: Kurzfristig bedeutet die Übernahme kommerzielles Rückgrat, Vollzeit-Entwicklung und wachsende Sichtbarkeit – Payload ist damit besser finanziert als die meisten Open-Source-CMS. Mittelfristig bleibt die strategische Unsicherheit, wie stark die Roadmap künftig auf Figma-Anwendungsfälle einzahlt. Die strukturelle Absicherung dagegen ist die MIT-Lizenz: Der gesamte Kern inklusive Admin-Panel ist quelloffen, forkbar und läuft auf Ihrer Infrastruktur weiter – zu Ihren Bedingungen, unabhängig von Produktentscheidungen in San Francisco. Wer Payload evaluiert, sollte die Übernahme als das behandeln, was sie ist: ein Governance-Faktum, das ins Entscheidungsprotokoll gehört – kein Ausschlusskriterium, aber auch kein Verkaufsargument ohne Kontext.
Payload vs. Sanity: die ehrliche Abgrenzung aus der Doppel-Praxis
Wir implementieren beide Systeme – und genau deshalb gehört die Abgrenzung in diesen Guide, ohne Lagerdenken. Die Systeme lösen unterschiedliche Schwerpunkte:
| Kriterium | Payload | Sanity |
|---|---|---|
| Grundmodell | Code-first, self-hosted, Teil der Next.js-App | Content Lake als Service, Studio als Oberfläche |
| Datenhaltung | Ihre PostgreSQL-/MongoDB-Instanz (EU, self-hosted) | Sanity-Cloud (Content Lake), vertraglich geregelt |
| Kostenmodell | 0 € Lizenz, Kosten = Infrastruktur + Projekt | Free-Tier; Teams ab ca. 15 $/Nutzer/Monat (Stand Juli 2026) |
| Redaktions-Kollaboration | solide (Versionen, Drafts, Live-Preview) | sehr stark (Echtzeit-Kollaboration, Presence, Kommentare) |
| Strukturierter Multi-Channel-Content | gut (Blocks, Relationen) | Referenzklasse (Portable Text, GROQ, Releases) |
| Auth & Zugriffskontrolle | im Kern enthalten, feldgenau | Studio-Rollen; App-Auth ist separat zu lösen |
| Typischer Sweet Spot | app-nahe Inhalte, Portale, Datenhoheit, Budget ohne SaaS-Abo | redaktionsgetriebene Websites, große Content-Teams, Mehrkanal |
Unsere Faustregel aus Projekten: Ist das Vorhaben eher eine Anwendung mit Inhalten (Portal, Produkt, interne Tools) oder verlangt es strikte Datenhoheit, führt der Weg zu Payload. Ist es eine redaktionsgetriebene Content-Plattform mit vielen Autoren und Kanälen, spielt Sanity seine Stärken aus – wie auf unserer Sanity-Leistungsseite beschrieben. Dazwischen entscheidet der Einzelfall – genau dafür gibt es unsere unabhängige CMS-Beratung.
Die Architektur in 90 Sekunden
Inhalte organisiert Payload in Collections (z. B. Seiten, Artikel, Produkte, Nutzer) und Globals (Singletons wie Navigation oder Einstellungen). Felder reichen von Primitiven über Relationen bis zu Blocks – wiederverwendbaren Inhaltsbausteinen für Pagebuilder-Muster. Hooks führen Logik bei Lese- und Schreiboperationen aus (Validierung, Anreicherung, Webhooks), Access-Control-Funktionen regeln Zugriffe pro Collection, Dokument oder Feld. Nach außen sprechen drei APIs: REST und GraphQL für externe Konsumenten, die Local API für latenzfreie Zugriffe im eigenen Next.js-Server. Das Admin-Panel ist React – anpassbar bis hin zu eigenen Feldkomponenten und Views. Versionierung, Drafts, geplante Veröffentlichung, Localization und Live-Preview gehören zum Kern.
Wann Payload passt – und wann nicht
Ehrlich bleibt ehrlich, auch bei einem System, das wir gern einsetzen. Payload passt nicht, wenn kein TypeScript-Know-how verfügbar ist und auch kein Partner den Betrieb trägt – ein Code-first-CMS ohne Code-Kompetenz verschenkt seinen Kernvorteil. Es passt ebenfalls nicht, wenn große Redaktionsteams Echtzeit-Kollaboration brauchen (dann Sanity) oder wenn eine reine Marketing-Site mit minimaler IT gesucht ist (dann sind auch verwaltete Plattformen legitim). Payload spielt seine Stärken aus bei: Kundenportalen und Anwendungen mit redaktionellen Anteilen, strikten Datenhoheits-Anforderungen, Next.js-Teams, die Systemgrenzen reduzieren wollen – und überall dort, wo Content-SaaS-Abos oder CMS-Lizenzmodelle wirtschaftlich nicht mehr tragen.
Betrieb und Kosten für Entscheider
Die Rechnung folgt dem bekannten Open-Source-Muster: Lizenz null, Kosten in Projekt und Betrieb. Ein fokussiertes Payload-Setup liegt in unserer Projektklassifikation bei 8.000–20.000 €, eine vollständige Anwendung mit Portal-Funktionen bei 20.000–60.000 €; der Betrieb auf EU-Infrastruktur (bei uns typischerweise Hetzner mit PostgreSQL) bewegt sich im niedrigen dreistelligen Monatsbereich. Der strukturelle Unterschied zu Content-SaaS: keine Kosten pro Redaktionsplatz, Eintrag oder API-Call – und die Datenbank gehört von Tag eins Ihnen. Wie sich solche Stack-Entscheidungen über Jahre rechnen, zeigt exemplarisch unser TCO-Vergleich WordPress vs. Sanity + Next.js – die Methodik überträgt sich eins zu eins auf Payload-Szenarien.
Für die Systemwahl im konkreten Fall: unabhängige CMS-Beratung – lizenzneutral, mit dokumentierten Trade-offs. Und wo Payloads eingebaute Auth endet und echtes IAM beginnt, erklärt unser Keycloak-Guide.
