Payload
Open-Source-Headless-CMS und App-Framework, Next.js-nativ, das sich in deinen bestehenden app-Ordner installiert
Payload ist ein quelloffenes Headless-CMS und Backend-Framework, das sich direkt in den app-Ordner eines bestehenden Next.js-Projekts installiert und ein TypeScript-Backend samt React-Adminoberfläche liefert, ohne dass ein eigener Dienst nötig wäre. Es hat Stand Juli 2026 43.792 Sterne, steht unter MIT-Lizenz und lässt sich serverless auf Vercel oder Cloudflare ebenso betreiben wie überall dort, wo Node läuft. Für Gründerinnen und Gründer beseitigt es den üblichen Grund, an dem Content-Arbeit hängen bleibt — endlich gibt es einen Ort zum Bearbeiten ohne Programmierkenntnisse. Ein CMS entscheidet aber, wie Seiten entstehen, nie ob sie jemand liest.
Was Payload ist
Payload (github.com/payloadcms/payload) bezeichnet sich als das erste Next.js-native CMS, das sich direkt in den bereits vorhandenen app-Ordner installiert. Statt einen separaten CMS-Dienst zu betreiben und Inhalte über eine API zu holen, leben Backend und Adminoberfläche innerhalb der Next.js-App, die es ohnehin schon gibt — die Datenbank lässt sich damit direkt aus React Server Components abfragen. Geschrieben ist es in TypeScript, lizenziert unter MIT, mit 43.792 Sternen Stand Juli 2026.
Das Projekt versteht sich als App-Framework und Headless-CMS zugleich und richtet sich danach aus: Die Adminoberfläche wird aus der eigenen Collection-Konfiguration erzeugt und mit eigenen Server Components erweitert. Der Einstieg ist ein einzelner create-payload-app-Befehl, und die Maintainer verweisen Neulinge auf das Website-Template, weil es den vollen Umfang zeigt — Rich-Text-Blöcke, On-Demand-Revalidierung, Live-Vorschau — mit einem Tailwind-Frontend im selben app-Ordner.
Was von Haus aus dabei ist
Die folgende Liste ist das, was das Repository selbst angibt, keine Wunschliste.
- Eine generierte React-Adminoberfläche — aus der eigenen Collection-Konfiguration gebaut, mit eigenen Server Components erweiterbar, sodass Redakteurinnen eine echte Oberfläche bekommen, die niemand entwerfen musste.
- Auth, Versionen und Entwürfe — Authentifizierung, Dokumentversionierung, Entwürfe, ein blockbasierter Layout-Builder, ein Lexical-Rich-Text-Editor, bedingte Feldlogik und feingranulare Zugriffskontrolle sind enthalten statt angeflanscht.
- Typen, die den Daten folgen — eine durchgängig in TypeScript geschriebene Codebasis mit automatisch erzeugten Typen für die eigenen Inhalte, dazu REST und GraphQL, wenn man sie will, und direkte Datenbankabfragen in Server Components, wenn nicht.
- Deploy, wo du willst — Ein-Klick-Serverless-Templates für Vercel und Cloudflare oder Self-Hosting auf eigener Infrastruktur; das Projekt betont, dass es keine Bindung an einen Anbieter gibt.
Wo Payload in den Wachstums-Stack passt
Ein CMS ist der Unterbau für content-getriebenes Wachstum. Sobald man mehr als eine Handvoll Seiten will — einen Blog, einen Vergleichsbereich, Seiten pro Standort oder pro Integration — verschiebt sich der Engpass vom Design zum Veröffentlichen: Wer kann ohne Entwicklerin eine Seite anlegen, und wie schnell? Das ist die Mechanik hinter SEO-Seiten in großem Umfang und programmatischem SEO, und Payloads offizielle Templates für Website, Blog und Shop zielen genau darauf. Im Vergleich zu den Nachbarn überschneidet es sich mit Ghost beim Publizieren und mit Medusa beim Shop, bleibt aber ein allgemeines Content-Backend statt eines von beiden.
Die Grenze, die man ehrlich benennen sollte: Ein CMS entscheidet, wie eine Seite entsteht, nie ob sie einen Besuch verdient. Publikationsfähigkeit ist notwendig und nicht hinreichend. Was bleibt, ist die Arbeit, lohnende Themen auszuwählen, etwas zu schreiben, das man nicht aus den oberen Suchergebnissen bekommt, und die Links und Erwähnungen zu verdienen, die davon überhaupt etwas ranken lassen. Es kommt regelmäßig vor, dass jemand ein CMS installiert und Monate später schließt, Content funktioniere nicht — obwohl nie das Werkzeug gefehlt hat.
CMS oder Inhalte im Code?
Nicht jede Site braucht ein CMS, und falsch zu wählen ist in beide Richtungen teuer. Die Frage ist, wer bearbeitet, wie oft, und was wahr sein muss, bevor eine Seite live geht.
| Ansatz | Am besten, wenn | Worauf du verzichtest |
|---|---|---|
| Headless-CMS wie Payload | Nicht-technische Leute veröffentlichen, Inhalte ändern sich oft, und du brauchst Entwürfe, Versionen und Rollen | Ein Schema und ein Deployment zum Pflegen; Änderungen laufen über eine Oberfläche statt über Code-Review |
| Inhalte im Code, in typisierten Datendateien | Wer bearbeitet, liefert auch aus, und jede Änderung soll vor dem Livegang getestet werden | Wer keinen Pull Request öffnen kann, kann nicht veröffentlichen |
| Ein gehostetes SaaS-CMS | Du willst gar keine Infrastruktur und kommst mit dem Modell des Anbieters zurecht | Portabilität und eine Rechnung, die mit deinen Inhalten wächst |
Anmerkung aus erster Hand aus dem Bau von AgentCeres — dem AI Growth Officer auf agentceres.com: Unsere eigenen Marketingseiten gehen den zweiten Weg. Jede Antwort-, Glossar- und Projektseite dieser Site ist ein Eintrag in einer typisierten TypeScript-Datei und kein CMS-Datensatz — eine bewusste Abwägung. Weil die Seiten Code sind, läuft für jede eine Testsuite und lässt den Build scheitern, wenn eine Seite einen Link zerbricht, ohne interne Verlinkung dasteht oder eine Zahl fest einträgt, die veralten wird — Prüfungen, die ein CMS strukturell nicht leisten kann, weil seine Aufgabe darin besteht, das anzunehmen, was jemand eingetippt hat. Der Preis ist real und wir zahlen ihn: Wer keinen Pull Request öffnen kann, veröffentlicht hier nicht. Wären unsere Redakteure nicht dieselben Leute, die die App ausliefern, wäre Payloads Modell das richtige.
FAQ
- Ist Payload kostenlos?
- Das Framework ist kostenlos und quelloffen unter MIT-Lizenz, du kannst es also ohne Softwarekosten selbst hosten und zahlst nur die Infrastruktur, auf der es läuft. Die Maintainer verkaufen zusätzlich Payload Cloud, ein gemanagtes Hosting für Teams, die es nicht selbst betreiben wollen, und das Repository wirbt mit Ein-Klick-Serverless-Deploys auf Vercel und Cloudflare, die eigene Preise haben. Prüfe die Lizenzdatei des Repositorys für die Version, die du installierst.
- Payload oder ein gehostetes CMS wie Contentful oder Sanity?
- Nimm ein gehostetes CMS, wenn du keine Infrastruktur willst und das Inhaltsmodell des Anbieters zu deiner Arbeitsweise passt. Nimm Payload, wenn du ohnehin auf Next.js baust und das CMS in deiner eigenen App, deine Daten in deiner eigenen Datenbank und keine Obergrenze pro Sitz oder pro Datensatz einplanen willst. Der Tausch ist operativ: Payload ist Code, den du pflegst und deployst, ein gehostetes CMS ein Dienst, den du konfigurierst und bezahlst.
- Brauche ich Entwickler, um Payload zu nutzen?
- Für die Einrichtung ja: Collections, Felder und Zugriffsregeln werden im Code definiert, und die App wird wie jedes andere Next.js-Projekt deployt. Danach nein — der Sinn der Adminoberfläche ist gerade, dass nicht-technische Leute Inhalte anlegen, bearbeiten, als Entwurf halten und veröffentlichen können, ohne die Codebasis anzufassen. Die Entwicklerkosten liegen vorn in der Einrichtung statt verteilt über jede Seite.
- Hilft ein CMS beim SEO?
- Indirekt, indem es Reibung entfernt. Ein CMS lässt keine Seite ranken, aber es beseitigt den Grund, an dem die meisten Content-Programme hängen bleiben: dass Veröffentlichen eine Entwicklerin erfordert. Schnelleres Veröffentlichen bedeutet mehr Versuche, und über mehr Versuche findet ein Content-Programm heraus, was funktioniert. Das Ranking selbst kommt weiterhin daher, Themen ordentlich abzudecken, echte Fragen zu beantworten und Links zu verdienen — nichts davon liefert ein CMS.
You built it. Now grow it.
AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $19/month.