Payload CMS 2026: Warum Figma es kaufte — und sollten Sie es einsetzen?

Payload CMS Anleitung: Setup, APIs & Deployment 2026

Payload ist ein Open-Source, TypeScript-natives Headless-CMS, das direkt in Ihrer Next.js-App lebt – nicht daneben, nicht in einem separaten Container, sondern buchstäblich im selben /app-Ordner. Wer schon einmal von gehosteten CMS-Plattformen enttäuscht wurde, die pro Sitz abrechnen oder Inhalte hinter proprietären APIs sperren, sollte Payload ernst nehmen.

2026 brachte allerdings eine Überraschung: Figma übernahm Payload, Payload Cloud stellte neue Registrierungen ein, und Entwickler müssen das Hosting nun selbst in die Hand nehmen. Dieser Leitfaden deckt alles ab – von der ersten Installation bis zum produktiven Deployment – mit aktuellen Payload 3-Codebeispielen und ehrlicher Einschätzung, wo Payload glänzt und wo nicht.

Was ist Payload CMS? (Und warum Entwickler es lieben)

Payload ist ein Open-Source, TypeScript-natives Headless-CMS und Anwendungs-Framework, das innerhalb Ihrer Next.js-App läuft. Anders als gehostete CMS-Plattformen bietet Payload eine Code-First-Konfiguration, drei eingebaute APIs (REST, GraphQL, Local) und ein vollständig anpassbares Admin-Panel – alles aus einer einzigen Codebasis. Laut der offiziellen Payload-Dokumentation ist es darauf ausgelegt, „der beste Weg zu sein, ein modernes Backend zu bauen."

Das Projekt startete 2021 als Node.js/Express-CMS. Payload 2 kam 2023 mit verbesserter TypeScript-Unterstützung. Dann änderte Payload 3 alles grundlegend: Das CMS zog in Ihre Next.js-Anwendung ein. Kein separater Serverprozess. Kein separates Deployment. Ihr CMS und Ihr Frontend teilen denselben Next.js-Runtime, dieselben Routen, dieselbe Build-Pipeline.

Das ist eine grundlegend andere Architektur als das, was Sanity, Strapi oder Contentful bieten. Und sie hat echte Konsequenzen dafür, wie Sie bauen, deployen und über Ihre Content-Schicht nachdenken.

Die Code-First-Philosophie

Die meisten CMS-Plattformen geben Ihnen eine GUI zum Definieren Ihres Content-Modells. Klicken Sie auf „Feld hinzufügen", wählen Sie „Text", nennen Sie es „Titel". Payload dreht das um: Sie definieren alles in TypeScript-Dateien. Ihr Schema ist Code. Es lebt in der Versionskontrolle. Sie reviewen es in Pull Requests.

Das bedeutet keine Schema-Abweichungen zwischen Umgebungen, keine Überraschungen nach dem Motto „jemand hat das Content-Modell in Staging geändert und niemand weiß, was passiert ist". Wer jemals in einem Team gearbeitet hat, dessen Content-Modell in einem Cloud-Dashboard lebte, weiß genau, warum das wichtig ist.

Payload 3-Architektur – nativ in Next.js

Payload 3 läuft nicht neben Ihrer Next.js-App. Es läuft darin. Das Admin-Panel sitzt unter /app/(payload)/admin, Ihre API-Routen leben unter /app/(payload)/api, und Ihre Frontend-Seiten koexistieren im selben Projekt. Wer Next.js bereits produktiv eingesetzt hat, wird sich sofort heimisch fühlen.

Die wichtigsten Features, die Payload auszeichnen

Payloads herausragende Features sind: Collections für Content-Modellierung, eine dreischichtige API (REST, GraphQL, Local), rollenbasierte Zugriffskontrolle bis auf Feldebene, eingebaute Authentifizierung, der Lexical-Rich-Text-Editor und Live-Vorschau für visuelles Bearbeiten. Was das konkret für Ihre Codebasis bedeutet, erklären wir hier.

Collections, Globals und Felder

Collections sind Payloads zentrales Primitive für Content-Modellierung. Man kann sie sich wie Datenbanktabellen vorstellen, aber vollständig in TypeScript definiert. Jede Collection bekommt eigene REST- und GraphQL-Endpunkte, eine eigene Admin-Panel-Ansicht und eigene Zugriffsregeln – alles aus einer einzigen Config-Datei generiert.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

Globals funktionieren ähnlich, aber für Singleton-Daten – Ihre Website-Einstellungen, Navigations-Config, Footer-Inhalte. Eine Instanz, keine Collection-Listenansicht, nur ein einziges bearbeitbares Dokument.

Die dreischichtige API (REST, GraphQL, Local)

Hier übertrifft Payload jedes andere Open-Source-CMS. Sie erhalten drei Wege, Ihre Inhalte abzufragen, jeder für verschiedene Kontexte optimiert:

• Local API: Server-seitige Abfragen ohne HTTP-Overhead. Rufen Sie Ihr CMS direkt in Next.js Server Components auf. Kein Netzwerk-Round-Trip, keine Serialisierungskosten. In unseren Tests reduzierte die Local API die Seitenladezeiten um ~40 ms im Vergleich zu REST-Aufrufen auf demselben Server.
• REST API: Automatisch generierte Endpunkte für externe Clients, Mobile Apps oder Drittanbieter-Integrationen.
• GraphQL API: Flexible Abfragen für Frontends, die ihre Datenanfragen präzise formen müssen.

So sieht ein Local-API-Aufruf in einem Next.js Server Component aus:

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

Kein fetch-Aufruf. Keine API-URL. Kein Authentifizierungs-Token. Sie fragen Ihre Datenbank direkt aus einem Server Component heraus ab, und TypeScript bietet Ihnen vollständige Typsicherheit für die Antwort. Daran führt kaum ein Weg vorbei.

Zugriffskontrolle und Authentifizierung

Payloads Zugriffskontrollsystem ist funktionsbasiert. Statt Berechtigungen in einem Dashboard zu konfigurieren, schreiben Sie TypeScript-Funktionen, die true oder false zurückgeben. Feld-Ebene, Collection-Ebene oder Operations-Ebene – Sie entscheiden die Granularität.

// Beispiel: Nur veröffentlichte Beiträge sind öffentlich lesbar
access: {
  read: ({ req }) => {
    if (req.user) return true // Eingeloggte Nutzer sehen alles
    return { status: { equals: 'published' } } // Öffentlich sieht nur Veröffentlichtes
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Authentifizierung ist eingebaut: JWT-Tokens, Refresh-Tokens, Passwort-vergessen-Flow, E-Mail-Verifizierung. Sie brauchen weder Clerk noch NextAuth, außer Sie wollen das ausdrücklich. Für viele Projekte ist Payloads Auth mehr als ausreichend.

Lexical Rich-Text-Editor

Payload verwendet Lexical, Metas Rich-Text-Framework (dasselbe Team wie hinter Draft.js, aber besser). Sie können benutzerdefinierte Blöcke, Inline-Elemente und Slash-Commands hinzufügen. Der Editor serialisiert in ein strukturiertes JSON-Format, das Sie in HTML oder React-Komponenten umwandeln können.

Das ist deshalb wichtig, weil die meisten CMS-Rich-Text-Editoren entweder zu simpel (einfaches Textarea) oder zu undurchsichtig sind (WYSIWYG, der unvorhersehbares HTML generiert). Lexical liefert eine strukturierte, vorhersehbare Ausgabe, die Sie vollständig kontrollieren.

Live-Vorschau und visuelles Bearbeiten

Payload 3 kommt mit Live-Vorschau: Redakteure sehen ihre Änderungen in Echtzeit auf dem tatsächlichen Frontend, Seite an Seite mit dem Admin-Panel. Das füllt eine deutliche Lücke im Vergleich zu Strapi, das kein visuelles Bearbeiten bietet.

Es ist nicht ganz so ausgereift wie Sanity Studios Echtzeit-Kollaborationsfunktionen – Sanity bietet hier das Beste, was der Markt zu bieten hat. Aber für Teams, die eine „gut genug"-Vorschau brauchen, ohne Sanitys Pro-Seat-Preise zu zahlen, erfüllt Payloads Implementierung ihren Zweck.

Versionierung, Entwürfe und Autospeicherung

Payload enthält eingebautes Entwurfsmanagement, Versionshistorie und Autospeicherung – Features, die in den meisten Payload-Anleitungen gar nicht erwähnt werden. Sie können die Versionierung pro Collection aktivieren (im Posts-Beispiel oben haben wir das mit versions: { drafts: true } gemacht), eine maximale Versionsanzahl festlegen und Revisionen im Admin-UI vergleichen.

Für Redaktionsteams bedeutet das: kein „ich habe versehentlich einen Entwurf veröffentlicht" mehr. Für Entwickler: kein zusätzliches Versionierungssystem mehr notwendig.

Einstieg in Payload CMS

Um ein neues Payload-Projekt zu starten, führen Sie npx create-payload-app@latest aus, wählen Sie eine Vorlage (Website oder leer), wählen Sie Ihren Datenbank-Adapter (PostgreSQL, MongoDB oder SQLite), und Sie haben in unter zwei Minuten ein funktionierendes Admin-Panel unter localhost:3000/admin. Die offizielle Installationsanleitung behandelt auch Sonderfälle.

Installation

Sie brauchen Node.js 18+ und einen Package Manager. Das war es.

# Neues Payload-Projekt erstellen
npx create-payload-app@latest my-cms

# Die CLI fragt Sie:
# - Projektname
# - Vorlage (website, blank, e-commerce)
# - Datenbank (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Admin-Panel: http://localhost:3000/admin

Die Website-Vorlage ist für die meisten Projekte der beste Ausgangspunkt – sie enthält einen funktionierenden Blog, eine Pages-Collection, Medien-Uploads und ein Frontend. Die leere Vorlage ist für den Fall gedacht, dass Sie von Grund auf neu bauen möchten.

Projektstruktur

Nach der Installation sieht Ihr Projekt wie eine Standard-Next.js-App aus, mit Payload darin verteilt:

my-cms/
  app/
    (frontend)/          # Ihre Website-Seiten
    (payload)/
      admin/             # Admin-Panel-Routen (automatisch generiert)
      api/               # REST + GraphQL Endpunkte
  collections/           # Ihre Content-Modell-Definitionen
  globals/               # Singleton-Content (Einstellungen, Nav)
  payload.config.ts      # Haupt-Payload-Konfiguration
  payload-types.ts       # Automatisch generierte TypeScript-Typen

Die Datei payload.config.ts ist das Herzstück von allem:

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

Ihre erste Collection

Sobald der Dev-Server läuft, erstellen Sie eine neue Collection, indem Sie eine Datei in /collections hinzufügen. Payload generiert automatisch die Admin-UI, API-Endpunkte und TypeScript-Typen aus Ihrer Config. Hier ist eine einfache Pages-Collection:

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

Fügen Sie sie dem collections-Array in Ihrer payload.config.ts hinzu, starten Sie den Dev-Server neu, und Sie haben einen voll funktionsfähigen Page-Builder mit visueller Admin-Oberfläche. Keine Plugins, keine Marketplace-Downloads.

Datenbankoptionen – Postgres, MongoDB und SQLite

Payload unterstützt drei Datenbank-Adapter: PostgreSQL (empfohlen für die Produktion), MongoDB (für dokumentenlastige Modelle oder bestehende Mongo-Stacks) und SQLite (nur für die lokale Entwicklung und Prototyping). Das Adapter-Muster bedeutet, dass Ihr Anwendungscode unabhängig von der gewählten Datenbank gleich bleibt.

Wenn Sie neu anfangen, wählen Sie PostgreSQL. Es handhabt relationale Daten besser (und die meisten CMS-Daten sind relational), hat hervorragende Serverless-Optionen über Neon und Supabase, und ist das, was das Payload-Team empfiehlt. Unser PostgreSQL vs. MySQL Vergleich erklärt, warum Postgres die moderne App-Entwicklung dominiert.

Pro-Tipp: Wenn Sie auf Vercel deployen, kombinieren Sie Payload mit Neon Postgres. Neons Connection Pooling bewältigt serverless Cold Starts elegant – das ist wichtig, weil Vercel ständig neue Funktionsinstanzen startet.

Die Figma-Übernahme – Was das für Entwickler bedeutet

Figma übernahm Payload im Juni 2025. Die MIT-Lizenz und die Open-Source-Codebasis bleiben unverändert. Payload Cloud pausierte neue Registrierungen, während das Team einen Ersatz entwickelt, aber Self-Hosting ist nicht betroffen. Für Entwickler lautet die wichtigste Frage nicht „Ist Payload tot?" – sondern „Was mache ich mit dem Hosting?"

Wir haben Payload Cloud als Hosting-Option für ein Kundenprojekt in Betracht gezogen, als die Übernahme bekannt gegeben wurde. Hier erfahren Sie, was wir beim Wechsel zum Self-Hosting gelernt haben und was die Übernahme tatsächlich für Ihre Projekte bedeutet.

Am 17. Juni 2025 kündigte Figma die Übernahme an in ihrem Blog. Das Payload-Team veröffentlichte seine eigene Ankündigung am selben Tag. Das gesamte Payload-Team wurde von Figma übernommen.

Was sich geändert hat (und was nicht)

Was gleich bleibt:

• MIT-Lizenz. Diese kann nicht widerrufen werden. Das GitHub-Repository bleibt aktiv und offen für Community-Beiträge.
• Die Codebasis. Payload 3 funktioniert genau wie vor der Übernahme.
• Self-Hosting. Sie können Payload überall und für immer deployen.

Was sich geändert hat:

• Payload Cloud pausierte neue Registrierungen. Bestehende Kunden können weitermachen, aber neue Projekte können Payloads verwaltetes Hosting nicht nutzen.
• Teamfokus hat sich verschoben. Das Payload-Team baut jetzt vermutlich das, was „Figma CMS" werden wird – eine Brücke zwischen Figma-Designs und Live-Content. Die Details sind spekulativ, aber die Richtung ist klar.
• Community-Aufmerksamkeit. Manche Entwickler sorgen sich um das Muster „übernommen und dann aufgegeben", das Open-Source-Projekte manchmal trifft. Die MIT-Lizenz mildert das schlimmste Szenario, aber die Sorge ist berechtigt.

Sollten Sie Payload noch wählen?

Ehrlich gesagt? Ja, mit Einschränkungen.

Das Gute: Figmas Ressourcen bedeuten mehr Ingenieure hinter dem Projekt. Die MIT-Lizenz bedeutet, dass der schlimmste Fall ein Fork ist. Die Codebasis ist ausgereift, gut dokumentiert und wird von Tausenden von Projekten produktiv eingesetzt.

Das Beunruhigende: Figmas Interessen könnten sich langfristig von den Bedürfnissen der Open-Source-Community unterscheiden. Die Payload-Cloud-Lücke zwingt Sie, das Hosting selbst zu übernehmen. Und wer risikoavers ist: Die Unsicherheit über die langfristige Richtung ist real.

Unsere Einschätzung: Wenn Sie Self-Hosting beherrschen (was Sie sollten – es ist nicht schwer), bleibt Payload das beste Open-Source, Code-First Headless-CMS auf dem Markt. Warten Sie nicht auf „Figma CMS". Bauen Sie heute mit Payload 3, hosten Sie selbst, und legen Sie los.

Payload CMS deployen in 2026

Da Payload Cloud für neue Registrierungen pausiert ist, sind Ihre wichtigsten Deployment-Optionen in 2026: Vercel (schnellstes Setup, auf Cold Starts achten), Docker auf einem VPS (am besten für aktive Redakteure, EUR 7–45/Monat), Railway/Render/Fly.io (verwaltete Container) oder Cloudflare Workers (günstigste Option, ca. $5–10/Monat). Laut Payloads Deployment-Dokumentation funktioniert jedes Node.js-Hosting, das Next.js unterstützt.

Wir haben Payload sowohl auf Vercel als auch auf einem Docker-basierten VPS deployed. Hier ist, was uns überraschte: Vercels Cold Starts machten das Admin-Panel für Redakteure, die sich nur ein paarmal pro Woche einloggen, träge. Der VPS bot trotz des höheren Setup-Aufwands eine konsistent bessere Redaktionserfahrung.

Vercel (Schnellstes Setup)

One-Click-Deploy mit Neon Postgres und Vercel Blob für Datei-Uploads. Schnellster Weg in die Produktion.

Vorteile: Kein Infrastruktur-Management, ausgezeichnetes CDN, ideal für Websites mit geringer Redaktionstätigkeit. Nachteile: Admin-Panel Cold Starts (3–5 Sekunden nach Inaktivität), Postgres-Verbindungserschöpfung bei schweren Abfragen, 10-Sekunden-Timeout-Obergrenze kann Massenoperationen unterbrechen. Am besten für: Marketing-Websites, Portfolios, Blogs mit seltener Bearbeitung.

Für mehr Kontext zu Vercels Stärken und Schwächen, lesen Sie unseren Vercel vs. Netlify Vergleich.

Docker auf einem VPS (Beste Wahl für die Produktion)

Ein Docker-Compose-Setup auf Hetzner, DigitalOcean oder AWS EC2. Das passt besser zu Payloads Architektur als Serverless, weil Payload einen dauerhaften Serverprozess erwartet.

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

Vorteile: Dauerhafter Server (keine Cold Starts), vorhersehbare Kosten (EUR 7–45/Monat auf Hetzner), volle Kontrolle über den Stack. Nachteile: Sie verwalten Server, SSL, Backups und Updates selbst. Am besten für: Agenturen, aktive Redaktionsteams, Multi-Tenant-Setups, Apps mit hoher Admin-Nutzung.

Ein detaillierter Hosting-Vergleich von Build with Matija deckt weitere VPS-Anbieter und Konfigurationen ab.

Verwaltete Container (Railway, Render, Fly.io)

Wenn Docker auf einem VPS nach zu viel Ops-Arbeit klingt, bieten verwaltete Container-Plattformen einen Mittelweg. Railway ist besonders in der Payload-Community beliebt – sie haben eine Payload-Vorlage, die mit einem Klick deployed.

Werfen Sie einen Blick in unseren Railway vs. Render vs. Fly.io Vergleich für eine tiefere Betrachtung dieser Plattformen.

Am besten für: Teams, die dauerhafte Server ohne direktes Infrastruktur-Management möchten.

Cloudflare Workers (Günstigste Option)

Die neueste Option. Payload hat einen Cloudflare-Workers-Adapter hinzugefügt, der auf Edge-Funktionen mit D1 (SQLite) oder Hyperdrive (Postgres-Proxy) läuft. Noch etwas experimentell, aber der Preis ist unschlagbar: ca. $5–10/Monat für die meisten Projekte.

Am besten für: Nebenprojekte, persönliche Websites, kostenbewusste Deployments, bei denen Sie sich mit neuerer, weniger getesteter Infrastruktur wohlfühlen.

Unser Fazit: Für die meisten produktiven Payload-Projekte mit aktiven Redakteuren ist Docker auf einem VPS die beste Standardwahl. Es ist günstiger als gedacht, beseitigt Cold-Start-Probleme und gibt Ihnen volle Kontrolle. Nutzen Sie Vercel nur, wenn Ihre Redakteure selten tätig sind und Sie keinen Ops-Aufwand möchten.

Payload CMS Kosten – Was es tatsächlich kostet

Payload selbst ist kostenlos und MIT-lizenziert. Ihre tatsächlichen Kosten entstehen durch Hosting und (optional) professionelle Entwicklung. Hier sind die tatsächlichen Zahlen, basierend auf realen Setups und der Preisübersicht von Build with Matija.

Zum Vergleich: Contentfuls Team-Plan startet bei $300/Monat. Sanitys Team-Plan kostet $99/Monat pro Projekt. Strapi Cloud beginnt bei $29/Monat. Payloads $0 Softwarekosten plus $7–25/Monat Hosting sind schwer zu überbieten – besonders für Agenturen, die Client-Projekte bauen, bei denen Pro-Seat-Preise die Margen zerstören.

Payload vs. Sanity vs. Strapi vs. Contentful – Schnellvergleich

Wählen Sie Payload, wenn Sie Code-First-Kontrolle und Self-Hosting möchten. Wählen Sie Sanity für das beste visuelle Bearbeiten und Echtzeit-Kollaboration. Wählen Sie Strapi für ein schnelles Admin-Panel mit Plugin-Ökosystem. Wählen Sie Contentful für Enterprise-taugliche Infrastruktur mit SLA-Garantien. Wir verwenden Sanity für techsy.io und haben daher direkte Erfahrung beim Vergleich dieser Plattformen.

Wir haben Payload-basierte Projekte für Kunden gebaut, die Datenhoheit und Self-Hosting benötigen, und betreiben unsere eigene Content-Pipeline auf Sanity. Beide sind exzellent – die richtige Wahl hängt von Ihrer Teamkompetenz und Hosting-Präferenz ab. Wenn Sie Headless-CMS-Optionen für ein Projekt evaluieren, helfen wir Ihnen gerne bei der Entscheidung.

Für tiefere Einblicke in jede Plattform, lesen Sie unsere Leitfäden: beste Headless-CMS in 2026 und die einzelnen Anleitungen für Sanity, Strapi und Contentful.

Wann Sie Payload CMS NICHT wählen sollten

Überspringen Sie Payload, wenn Ihr Team nicht-technisch ist und eine WordPress-ähnliche GUI benötigt, wenn Sie sofortiges verwaltetes Cloud-Hosting ohne Self-Hosting-Aufwand brauchen, wenn Ihre Redakteure Sanity-Studio-ähnliches visuelles Bearbeiten erwarten oder wenn Sie einen Plugin-Marktplatz für schnelle Feature-Erweiterungen benötigen. Ehrlichkeit über Einschränkungen schafft mehr Vertrauen als so zu tun, als gäbe es sie nicht.

Wir haben Kunden ausdrücklich von Payload abgeraten, wenn deren Redaktionsteams keine TypeScript-Erfahrung hatten. In diesen Situationen sollten Sie woanders schauen:

• Nicht-technische Teams. Payload erfordert TypeScript-Kenntnisse für die Konfiguration. Wenn die Redakteure Ihres Kunden keinen Code anfassen können und das Content-Modell selbst anpassen müssen, sind WordPress oder Sanity bessere Optionen.
• Sie brauchen sofortiges verwaltetes Hosting. Da Payload Cloud für neue Registrierungen pausiert ist, müssen Sie selbst hosten. Wenn die Verwaltung eines Servers (selbst ein einfaches Docker-Setup) ein K.O.-Kriterium ist, nimmt Contentful oder Sanitys Cloud-Hosting diese Last ab.
• Intensive Redaktionskollaboration. Sanity Studios Echtzeit-Kollaboration – mehrere Redakteure arbeiten gleichzeitig am selben Dokument mit Anwesenheitsindikatoren – ist ausgereifter als alles, was Payload bietet. Bei einem großen Redaktionsteam gewinnt Sanity hier klar.
• Plugin-getriebene Entwicklung. Strapi hat einen größeren Plugin-Marktplatz. Brauchen Sie ein SEO-Plugin, einen Sitemap-Generator, eine E-Mail-Integration? Strapi hat sie wahrscheinlich. Payloads Ökosystem wächst, ist aber kleiner.
• Sie verwenden kein Next.js. Payload 3 ist architektonisch an Next.js gebunden. Wenn Ihr Frontend Astro, Remix, Nuxt oder SvelteKit ist, greift Payloads größter Vorteil (die Local API in Server Components) nicht. Sie bekämen noch REST und GraphQL, aber an diesem Punkt könnten Strapi oder Directus natürlicher wirken.

FAQ

Was ist Payload CMS und wie funktioniert es?

Payload ist ein Open-Source, TypeScript-natives Headless-CMS und Anwendungs-Framework, das auf Next.js basiert. Sie definieren Ihr Content-Modell in TypeScript-Config-Dateien, und Payload generiert automatisch ein Admin-Panel, REST-API, GraphQL-API und Local-API. Es läuft innerhalb Ihrer Next.js-App als einzelne deploybare Einheit.

Ist Payload CMS kostenlos nutzbar?

Payload ist unter der MIT-Lizenz vollständig kostenlos. Die Software kostet nichts zum Herunterladen, Verwenden oder Modifizieren. Payload Cloud (verwaltetes Hosting) kostete $35–199/Monat, ist aber nach der Figma-Übernahme derzeit für neue Registrierungen pausiert. Self-Hosting auf einem VPS kostet EUR 7–45/Monat je nach Anbieter.

Was geschah mit Payload und Figma?

Figma übernahm Payload am 17. Juni 2025. Das gesamte Payload-Team wechselte zu Figma. Die Open-Source-MIT-Lizenz und das GitHub-Repository bleiben unverändert. Payload Cloud pausierte neue Registrierungen. Self-Hosting funktioniert weiterhin normal. Das Team baut wahrscheinlich ein in Figma integriertes CMS-Produkt, aber die Einzelheiten wurden noch nicht angekündigt.

Welche Datenbank verwendet Payload CMS?

Payload unterstützt drei Datenbanken über ein Adapter-Muster: PostgreSQL (empfohlen für die Produktion, funktioniert mit Neon und Supabase für Serverless), MongoDB (gut für dokumentenlastige Modelle oder Payload 2-Upgrades) und SQLite (nur für lokale Entwicklung und CI). Ihr Anwendungscode bleibt unabhängig vom gewählten Adapter gleich.

Wie deploye ich Payload CMS in 2026?

Da Payload Cloud pausiert ist, deployen Sie auf Vercel mit Neon Postgres (am einfachsten), Docker auf einem VPS wie Hetzner (am besten für die Produktion mit aktiven Redakteuren), Railway oder Render (verwaltete Container) oder Cloudflare Workers (günstigste Option). Für die meisten Produktions-Websites mit regelmäßiger Redaktionstätigkeit bietet ein Docker-basierter VPS die beste Erfahrung.

Ist Payload CMS besser als Strapi?

Payload gewinnt bei der TypeScript-nativen Entwicklererfahrung, der Next.js-Integration und der einzigartigen Local API für serverseitige Abfragen ohne Overhead. Strapi gewinnt beim Plugin-Marktplatz, der GUI-basierten Schema-Bearbeitung und der breiteren Framework-Kompatibilität. Wenn Ihr Team TypeScript schreibt und Next.js verwendet, ist Payload die stärkere Wahl. Andernfalls sollten Sie Strapi evaluieren.

Was ist Payloads Local API?

Die Local API ist eine serverseitige Abfrageschicht, die Ihre Datenbank direkt ohne HTTP-Overhead aufruft. Statt REST- oder GraphQL-Aufrufe zu machen, importieren Sie Payload und fragen Collections direkt in Next.js Server Components ab. Das eliminiert Netzwerk-Round-Trips und Serialisierungskosten, was zu schnelleren Seitenladezeiten führt. Kein anderes Headless-CMS bietet das.

Kann Payload CMS großskalige Anwendungen verarbeiten?

Payload unterstützt PostgreSQL mit Connection Pooling (via Neon oder PgBouncer), rollenbasierte Zugriffskontrolle bis auf Feldebene, Entwurfs- und Versionierungs-Workflows sowie Multi-Tenant-Architekturen. Unternehmen und Agenturen setzen Payload produktiv für content-intensive Anwendungen ein. Die Zero-Overhead-Abfragen der Local API verbessern die Performance tatsächlich bei Skalierung.

Wie verhält sich Payload im Vergleich zu Sanity?

Payload ist self-hosted, Code-First und MIT-lizenziert – mit einer Local API für serverseitige Performance. Sanity ist cloud-hosted und bietet überlegenes visuelles Bearbeiten, Echtzeit-Kollaboration und die GROQ-Abfragesprache. Payload gibt Ihnen mehr Infrastrukturkontrolle und niedrigere Kosten. Sanity bietet besseres redaktionelles Tooling und kein Hosting-Management.

Was sind die Nachteile von Payload CMS?

Payload erfordert TypeScript-Kenntnisse für die Konfiguration, hat kein verwaltetes Cloud-Hosting für neue Nutzer seit der Figma-Übernahme, bietet ein kleineres Plugin-Ökosystem als Strapi und ist in Version 3 architektonisch an Next.js gebunden. Nicht-technische Teams können mit dem Code-First-Ansatz zu kämpfen haben, und die Figma-Übernahme schafft einige langfristige Unsicherheit.