Was ist Payload?

Payload ist ein Content-Management-System der Headless-Bauart. Headless heißt: das CMS bringt keine fertige Webseite mit, es verwaltet Inhalte und stellt sie bereit, die Darstellung entsteht getrennt. Bei Payload ist diese Trennung allerdings kleiner als sonst üblich, denn das System läuft innerhalb einer Next.js-Anwendung mit. Webseite und CMS teilen sich ein Projekt, einen Server und ein Deployment, und die Seite kann Inhalte direkt aus der Datenbank lesen, ohne Umweg über eine Schnittstelle.

Die zweite Eigenheit: Payload wird im Code eingerichtet, nicht in einer Klickoberfläche. Welche Inhaltstypen es gibt, welche Felder sie haben und wer was darf, steht in TypeScript-Dateien, die mit im Projekt liegen. Das klingt nach einem Nachteil und ist für viele Projekte das Gegenteil: jede Änderung an der Struktur ist in der Versionsverwaltung dokumentiert, lässt sich auf einer Testumgebung ausprobieren und im Zweifel rückgängig machen. Bei einem System, das per Klick verwaltet wird, weiß nach zwei Jahren niemand mehr, wer wann was umgestellt hat.

So sieht ein Inhaltstyp in Payload aus, hier eine Stellenanzeige mit drei Feldern:

Aus dieser Beschreibung erzeugt Payload alles Weitere von selbst: die Eingabemasken für die Redaktion, die Datenbanktabellen und die Schnittstellen nach außen. Die Redaktion sieht davon nichts, sie arbeitet in einer normalen Verwaltungsoberfläche mit Listen, Formularen und Vorschau.

Technisch ist Payload ein Baustein, der in eine Next.js-Anwendung eingehängt wird. Die Verwaltungsoberfläche liegt dann zum Beispiel unter der Adresse der Webseite mit dem Zusatz /admin, geschützt durch die eingebaute Benutzerverwaltung. Als Speicher dient eine gewöhnliche Datenbank, wahlweise MongoDB oder PostgreSQL, die auf eurem Server oder bei einem Hoster eurer Wahl läuft. Eine Abrechnung nach Abfragen oder Nutzern gibt es nicht.

Der eigentliche Gewinn steckt im Zusammenspiel mit der Webseite. Weil beide im selben Projekt leben, liest die Seite ihre Inhalte direkt aus der Datenbank, ohne den Umweg über eine externe Schnittstelle. Das spart Ladezeit und eine ganze Fehlerquelle. Für alles außerhalb des Projekts, etwa eine App, stellt Payload trotzdem Schnittstellen bereit, REST und GraphQL inklusive. Rechte, Prüfregeln und Abläufe wie eine Freigabe vor der Veröffentlichung werden ebenfalls im Code definiert und gelten damit überall gleich.

Für den Betrieb heißt das: es gibt genau ein System, das aktuell gehalten werden muss. Kein CMS-Server hier und Webseiten-Server dort, sondern ein Deployment, das beides enthält. Updates, Backups und Überwachung bleiben trotzdem Pflicht, wie bei jeder selbst betriebenen Software.

Payload passt zu Projekten, die mehr sind als eine Inhaltsseite, aber kein Konzernbudget haben. Typische Einsatzgebiete sind:

• Firmenwebseiten mit Next.js, bei denen die Redaktion Inhalte pflegt und das CMS gleich mitläuft
• Seiten mit geschützten Bereichen, etwa Preislisten oder Downloads hinter einem Login
• Anwendungen mit Formularen, Prüfregeln und Freigaben, bei denen Inhalte und Logik zusammengehören
• Projekte mit Rechten je Rolle, die nachvollziehbar im Code stehen sollen statt in Klicklisten
• Inhalte für Webseite und App aus einer Quelle, über die eingebauten Schnittstellen

Für uns ist Payload eine naheliegende Wahl, weil es genau auf dem Stapel aufsetzt, mit dem wir täglich arbeiten: Next.js und TypeScript. Wo wir es einsetzen und wo bewusst nicht, steht auf unserer Seite zur Payload-Entwicklung.

Payload ist das jüngste der bekannten Headless-Systeme. Es wurde 2021 von einem kleinen Team in den USA veröffentlicht, mit einer klaren Haltung: Konfiguration gehört in den Code, und ein CMS soll Entwicklern nicht im Weg stehen. Die Idee traf einen Nerv, denn viele Teams bauten ihre Webseiten längst mit Next.js und suchten ein CMS, das sich in diese Welt einfügt, statt daneben zu stehen.

Payload verlangt eine Vorentscheidung, die man kennen sollte: es ist ein CMS für Projekte, in denen Entwickler die Struktur pflegen. Daraus ergeben sich klare Grenzen:

• Neue Felder oder Inhaltstypen brauchen einen Entwickler, die Redaktion kann die Struktur nicht selbst umbauen
• Es ist jünger als WordPress oder Strapi, das Ökosystem an fertigen Erweiterungen ist entsprechend kleiner
• Ohne Next.js- und TypeScript-Kenntnisse im Team ist der Einstieg steil, das System richtet sich an Profis
• Für eine kleine Seite ohne Logik ist der Einrichtungsaufwand höher als der Nutzen

Wer eine Seite will, deren Struktur die eigene Redaktion per Klick verändert, ist bei WordPress besser aufgehoben. Payload spielt seine Stärken dort aus, wo Struktur, Rechte und Abläufe verlässlich sein müssen und ohnehin ein Entwicklerteam am Projekt arbeitet.

Der Vergleich liegt nahe, denn beide sind quelloffene Headless-Systeme auf Node.js, beide laufen auf eigenen Servern, und beide erzeugen aus Inhaltstypen automatisch Verwaltung und Schnittstellen. Der Unterschied steckt in der Arbeitsweise. Strapi wird über eine Oberfläche eingerichtet und läuft als eigener Dienst neben der Webseite. Payload wird im Code eingerichtet und läuft in der Webseite mit. Payload ist die bessere Wahl, wenn:

• die Webseite ohnehin mit Next.js und TypeScript entsteht, denn dann entfällt ein komplettes zweites System
• Struktur und Rechte in der Versionsverwaltung nachvollziehbar sein sollen
• Inhalte und eigene Logik eng zusammenspielen, etwa bei Logins, Freigaben und Formularen mit Prüfung
• ein Deployment statt zwei betrieben werden soll

Strapi punktet dagegen, wenn das CMS bewusst unabhängig von der Webseite stehen soll, etwa weil mehrere sehr unterschiedliche Systeme darauf zugreifen, oder wenn die Struktur ohne Programmierung über eine Oberfläche gepflegt werden soll. Es ist außerdem einige Jahre länger am Markt, was für manche Firmen ein eigenes Argument ist. Beides sind gute Werkzeuge, die Entscheidung hängt am Team und am Projekt.

Für Auftraggeber zählen bei Payload drei Dinge. Erstens die Kosten: die Software ist kostenlos, es gibt keine Gebühren nach Nutzern oder Abfragen, bezahlt werden Entwicklung, Server und Pflege. Zweitens die Unabhängigkeit: Inhalte liegen in einer normalen Datenbank auf einem Server eurer Wahl und lassen sich jederzeit herausholen. Drittens die Wartbarkeit: weil die gesamte Einrichtung im Code steht, kann ein neues Team den Stand vollständig nachvollziehen, ein unterschätzter Vorteil bei jedem Dienstleisterwechsel.

Ehrlich gehört dazu: ihr bindet euch an ein vergleichsweise junges System und an Dienstleister, die Next.js und TypeScript beherrschen. Beides ist tragbar, die Technik dahinter ist Industriestandard und die Inhalte bleiben portabel, aber es ist eine andere Abhängigkeit als bei WordPress, wo an jeder Ecke jemand helfen kann. Für Fragen zu Betrieb und Folgekosten lohnt ein Blick auf unsere Seite zu Hosting und Wartung.

Payload steht für eine Richtung, die sich abzeichnet: CMS und Webseite wachsen wieder zusammen, diesmal aber auf moderner Grundlage. Statt eines Systems, das alles vorgibt, ein Baukasten aus Code, der sich exakt an das Projekt anpasst. Die Übernahme durch Figma hat dem Projekt zusätzlich Rückenwind gegeben, denn dahinter steht jetzt ein großes Unternehmen mit eigenem Interesse an der Weiterentwicklung.

Ob Payload die etablierten Systeme einholt, ist offen, und für die Entscheidung heute auch nicht entscheidend. Relevant ist: die Software ist quelloffen, die Inhalte liegen in einer normalen Datenbank, und die Bauweise passt zu dem, was im Web ohnehin Standard wird. Wer mit Next.js baut und ein CMS mit Logik braucht, bekommt mit Payload schon jetzt eine sehr runde Lösung. Wer maximale Verbreitung und das größte Ökosystem will, wählt ein älteres System und verliert dabei nichts.