Payload CMS in Kürze
Die Headless-CMS-Landschaft hat sich 2026 in zwei Lager sortiert: Content-as-a-Service-Plattformen wie Contentful, Sanity oder Storyblok verwalten Inhalte in ihrer Cloud. Selbst betriebene Systeme halten Daten und Laufzeit dagegen im eigenen Haus.
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 dich als Entscheider ist das mehr als Entwickler-Komfort: 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 definierst du als TypeScript-Konfiguration, nicht per Klick. Das Datenmodell liegt im Git-Repository, durchläuft Code-Review und CI/CD und ist zwischen Umgebungen reproduzierbar. Für deine Governance-Prozesse ist das der fundamentale Unterschied: Jede Schemaänderung ist nachvollziehbar, testbar und rückrollbar.
- Next.js-nativ seit Version 3: Payload installiert sich in deine 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.
- Deine Datenbank statt Content-Cloud: Inhalte liegen in PostgreSQL (oder MongoDB) auf deiner Infrastruktur. Backups, Verschlüsselung, Aufbewahrung und Löschkonzepte folgen deinen 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 deiner 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, deine 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: Payload bringt Authentifizierung, Rollen und Zugriffskontrolle im Kern mit. In vielen Projekten ersetzt es deshalb 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
Vorab die Übersicht: Sechs Punkte machen in der Praxis den Unterschied.
- 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 deiner Infrastruktur, nicht an Einträgen, API-Calls oder Redaktionsplätzen.
- Datenhoheit als Architektur: Inhalte, Nutzer und Medien liegen in deiner Datenbank auf EU-Infrastruktur. DSGVO-Fragen wie Speicherort, Auftragsverarbeitung und 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 dein Team beherrschen muss.
- Erweiterbarkeit ohne Plattformgrenzen: Hooks, eigene Endpoints, eigene React-Komponenten im Admin – deine Geschäftslogik wird Teil des Systems statt Workaround daneben.
- Exit-Sicherheit: Standard-PostgreSQL plus MIT-Code in deinem eigenen Repository. Es gibt schlicht keinen Anbieter, der dir 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 damit ein separates Auth-System (die Abgrenzung zu vollwertigem IAM findest du 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 deiner Infrastruktur weiter – zu deinen Bedingungen, unabhängig von Produktentscheidungen in San Francisco.
Wenn du Payload evaluierst, behandle die Übernahme als das, 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 | Deine 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 dein 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 (zum Beispiel 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 in deinem 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 in deinem Team 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 du eine reine Marketing-Site mit minimaler IT suchst (dann sind auch verwaltete Plattformen legitim).
Seine Stärken spielt Payload aus bei Kundenportalen und Anwendungen mit redaktionellen Anteilen, bei strikten Datenhoheits-Anforderungen und in 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 zwischen 8.000 und 20.000 €, eine vollständige Anwendung mit Portal-Funktionen zwischen 20.000 und 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 dir. 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.
Nächste Schritte
Für die Systemwahl in deinem konkreten Fall gibt es unsere unabhängige CMS-Beratung: lizenzneutral, mit dokumentierten Trade-offs. Und wo Payloads eingebaute Auth endet und echtes IAM beginnt, erklärt dir unser Keycloak-Guide.
Du willst die Frage direkt an deinem Vorhaben klären? Dann buch dir ein unverbindliches Beratungsgespräch: Wir schauen gemeinsam auf Redaktionsmodell, Datenhoheit und Stack – und du bekommst eine ehrliche Empfehlung, welches System dein Projekt trägt.
