Payload CMS – Erfahrungen aus Hostcraft

Ich habe Payload für Hostcraft verwendet, eine SaaS-App, mit der Gastgeber von Ferienunterkünften eine eigene Buchungsseite bekommen (mehr dazu in der Fallstudie). Payload 3 läuft dort zusammen mit Next.js 16 und Postgres. Zeit für ein ehrliches Fazit.

Was ist Payload?

Payload ist ein Open-Source-CMS (MIT-Lizenz), das komplett in TypeScript konfiguriert wird. Collections, Felder, Zugriffsrechte und Hooks werden nicht im Backend zusammengeklickt, sondern als Code im Projekt definiert. Aus dieser Konfiguration erzeugt Payload automatisch das Admin-Panel, eine REST- und GraphQL-API und eine typisierte Local API für den direkten Zugriff vom Server aus.

Seit Version 3 ist Payload kein eigener Server mehr, sondern wird direkt in eine Next.js-App installiert. Admin-Panel, API und Frontend laufen im selben Projekt und im selben Prozess. Als Datenbank stehen Postgres, MongoDB und SQLite zur Verfügung, bei Hostcraft ist es Postgres.

Vorteile

Moderne Oberfläche

Das Admin-Panel ist schnell, aufgeräumt und bringt Dark Mode, Tabs, Relationship-Felder, Medien-Bibliothek, Versionen und Mehrsprachigkeit mit. Bei Hostcraft sind viele Texte pro Sprache (Deutsch, Englisch, Kroatisch) pflegbar, dafür reicht ein localized: true am Feld, und im Backend erscheint automatisch der Sprachumschalter.

Die Oberfläche stammt aus der Konfiguration, es gibt also keinen separaten Admin-Code, der gepflegt werden muss. Neue Felder erscheinen sofort im Backend.

Anpassungsfähigkeit

Payload gibt kaum Struktur vor. Man baut die Inhaltsmodelle selbst, und alles lässt sich erweitern:

• Collections und Felder (Gruppen, Tabs, Relationen, Selects, Uploads …)
• Access Control auf Collection- und Feld-Ebene, auch mit Filtern pro Benutzer
• Hooks, die vor und nach dem Speichern laufen
• Eigene React-Komponenten im Admin-Panel, zum Beispiel Dashboards oder komplett eigene Views
• Auth mit Rollen, Sperre nach Fehlversuchen und Passwort-Reset, bereits eingebaut

Bei Hostcraft hat jeder Gastgeber nur Zugriff auf seine eigenen Unterkünfte, Webseiten und Buchungen. Das ist keine eigene Berechtigungslogik, sondern ein paar Zeilen Access Control:

export const ownSiteOrOperator: Access = ({ req: { user } }) => {
  if (!user) return false
  if (isOperator(user)) return true

  const hostId = getUserHostId(user)
  if (!hostId) return false

  // Hosts only see sites that belong to them
  return { host: { equals: hostId } }
}

Die Funktion gibt entweder true/false oder einen Filter zurück, den Payload direkt in die Datenbankabfrage übernimmt. Für ein Multi-Tenant-System wie Hostcraft ist das sehr praktisch.

Weil man die Local API auch außerhalb des Admin-Panels nutzen kann, sind Payload und die eigene App nicht getrennt. Das öffentliche Frontend, das Gastgeber-Dashboard und die Buchungslogik lesen und schreiben direkt in dieselben Collections. Das Admin-Panel selbst nutze ich nur als Betreiber. Die Gastgeber bekommen ein eigenes, einfacheres Dashboard, das ich selbst gebaut habe.

KI-Kompatibilität

Auch hier hat mich der Code-First-Ansatz überzeugt. Das ganze Datenmodell steht in TypeScript-Dateien im Repository. Ein KI-Assistent im Editor sieht Collections, Felder, Access Control und Hooks, ohne dass er ein Backend bedienen oder eine Datenbank untersuchen muss. Neue Felder, Collections oder Berechtigungen lassen sich per Prompt ergänzen, und alles ist als Git-Diff nachvollziehbar.

Dazu kommt payload generate:types: Aus der Konfiguration entsteht eine payload-types.ts mit allen Typen. Der Assistent bekommt damit präzises Feedback vom TypeScript-Compiler, wenn er ein Feld falsch benutzt. Das ist ein großer Unterschied zu CMS-Systemen, bei denen das Schema irgendwo in der Datenbank steckt.

Außerdem gibt es ein offizielles MCP-Plugin, über das KI-Clients Inhalte lesen und anlegen können, natürlich unter Beachtung der Access Control. Das habe ich bisher nicht ausprobiert, es ist aber ein gutes Zeichen, dass Payload den Weg ernsthaft weitergeht.

Kostenlos, ohne Lizenzmodell

Payload ist MIT-lizenziert. Es gibt keine Pro-Version, keine Preise pro Site und keine Einschränkung auf einen Benutzer. Für ein SaaS-Produkt, bei dem viele Gastgeber auf derselben Installation arbeiten, ist das ein echtes Argument.

Nachteile

Serveranforderungen

Payload ist keine statische Seite und kein klassisches PHP-CMS. Es braucht einen dauerhaft laufenden Node.js-Prozess und eine Datenbank. Billiges Shared Hosting ist damit raus, ein VPS (bei Hostcraft ein Server bei Hetzner) ist das Minimum.

• Node.js 22, bei mir mit pm2 als Prozess-Manager
• Postgres (oder MongoDB bzw. SQLite)
• Ein Reverse Proxy, der SSL übernimmt
• Genug Arbeitsspeicher für next build, denn bei mir wird auf dem Server gebaut und das Admin-Panel kommt zum Build noch dazu
• Persistenter Speicher für hochgeladene Dateien (bei mir ein media/-Ordner), solange man keinen S3-Speicher anbindet

Auch lokal ist der Aufwand höher als bei einer Markdown-basierten Seite. Ich starte Postgres per Container, und allein die node_modules sind rund 2 GB groß. Für eine kleine Visitenkarten-Seite ist Payload deshalb überdimensioniert.

Deploy – ein bedingter Nachteil

Im Alltag läuft das Deployment bei mir per GitHub Actions: Code holen, Abhängigkeiten installieren, Datenbank sichern, Migrationen ausführen, bauen, Prozess neu laden. Das ist kein Payload-spezifisches Problem, sondern normaler Alltag bei einer Node-App mit Datenbank. Trotzdem gab es Punkte, die man kennen sollte:

• Schema-Push vs. Migrationen: Im Entwicklungsmodus gleicht Payload die Datenbank automatisch an die Konfiguration an. Produktion braucht dagegen echte Migrationen (payload migrate:create und payload migrate). Wer das vergisst, merkt es erst beim Deploy.
• Der Marker aus dem Dev-Push: Der lokale Push hinterlässt einen Eintrag in payload_migrations (mit batch = -1). Danach fragt payload migrate interaktiv nach einer Bestätigung und hängt im SSH-Deploy, bis der Timeout greift. Bei mir entfernt das Deploy-Skript diesen Eintrag vor der Migration.
• Inhalte gehören zur Datenbank: Anders als bei einem Flat-File-CMS lassen sich Inhalte nicht per Git verschieben. Für den Start habe ich ein Skript, das Datenbank und media/-Ordner lokal sichert und auf den Server überträgt. Dafür müssen Git-Revision und PAYLOAD_SECRET zusammenpassen.
• Content Security Policy: Das Admin-Panel braucht in Produktion unsafe-eval. Die strenge CSP für die öffentliche Seite muss man für /admin deshalb getrennt konfigurieren.

Hat man das einmal sauber aufgesetzt, läuft es zuverlässig. Neue Projekte sollten Migrationen aber von Anfang an einplanen und nicht erst vor dem ersten Release.

Abhängigkeit von Next.js

Payload 3 ist eng mit Next.js verzahnt. Das Admin-Panel ist eine Next-App, die Konfiguration wird über withPayload in next.config.ts eingebunden, und die Versionen von Payload und Next müssen zusammenpassen. Dadurch gilt:

• Next-Updates und Payload-Updates müssen zusammenpassen. Next bringt regelmäßig Breaking Changes mit, und Payload veröffentlicht sehr häufig neue Versionen. Updates sollte man deshalb bewusst einplanen.
• React ist Pflicht. Wer sonst Vue und Nuxt nutzt, so wie ich bei den meisten Projekten, kann Payload zwar headless verwenden, betreibt dann aber trotzdem eine Next-App nur für das Backend.
• Der Lock-in ist spürbar. Die Local API und die Admin-Komponenten sind eng mit der Next-App verzahnt. Ein späterer Wechsel des Frontends ist möglich, aber nicht trivial.

Wer ohnehin mit Next.js arbeitet, hat davon dagegen fast nur Vorteile: ein Repository, ein Deployment, geteilte Typen.

Unsicherheit durch die Übernahme von Figma

Im Juni 2025 hat Figma das Payload-Team übernommen (Ankündigung von Figma, Ankündigung von Payload). Beide Seiten versprechen, dass Payload Open Source und selbst hostbar bleibt, dass das Team weiter an Payload arbeitet und dass sich für bestehende Nutzer zunächst nichts ändert.

Das ist beruhigend, aber „zunächst“ ist das entscheidende Wort. Figma entwickelt ein eigenes CMS, und Payload soll dafür die Grundlage liefern. Die Roadmap von Payload hängt damit künftig auch von den Interessen eines großen Unternehmens ab, und das lässt sich von außen nicht einschätzen:

• Entwickelt Figma den Open-Source-Kern weiter oder wandert der Fokus in kommerzielle Produkte?
• Bleibt die MIT-Lizenz auf Dauer bestehen?
• Wie lange werden Funktionen, die ich heute nutze, im Kern weiterentwickelt?

Bisher gibt es keinen Grund zur Panik, denn der Kern ist weiterhin MIT-lizenziert und wird aktiv gepflegt. Trotzdem sollte man diese Unsicherheit bei der Wahl für ein langlebiges Projekt mit einkalkulieren. Das Risiko ist überschaubar, weil Daten in Postgres und die Konfiguration in TypeScript liegen und sich im Zweifel auch ohne Payload weiterverwenden lassen. Aufwand wäre ein Wechsel trotzdem.

Fazit

Payload ist für mich das CMS, das am besten zu Next.js-Projekten passt und das ich für Web-Apps mit echter Logik, Benutzerrollen und mehreren Mandanten wieder einsetzen würde. Das Admin-Panel ist modern, das Datenmodell lässt sich beliebig anpassen, und weil alles in TypeScript liegt, arbeitet man hervorragend mit KI-Assistenten.

Die Nachteile sind überschaubar, aber real: ein eigener Server mit Node.js und Datenbank, ein Deployment mit sauberen Migrationen, die enge Bindung an Next.js und die offene Frage, wohin sich Payload unter Figma entwickelt. Für einfache Seiten, bei denen die Redaktion nur ein paar Texte ändert, gibt es leichtere Lösungen. Für ein Produkt wie Hostcraft war Payload die richtige Wahl.