Payload CMS 2026: waarom Figma het kocht (en of jij het moet gebruiken)

Payload CMS Gids: Installatie, API's & Deployment in 2026

Payload is een open-source, TypeScript-native headless CMS dat in je Next.js-app leeft — niet ernaast, niet in een aparte container, maar letterlijk in dezelfde /app-map. Als je ooit last hebt gehad van gehoste CMS-platforms die per seat rekenen of je content achter propriëtaire API's vergrendelen, is Payload het bekijken waard.

Maar 2026 bracht een complicatie: Figma nam Payload over, Payload Cloud pauzeerde nieuwe aanmeldingen, en developers moeten nu zelf hosting regelen. Deze gids behandelt alles van de eerste installatie tot deployment in productie, met actuele Payload 3-codevoorbeelden en eerlijke oordelen over waar Payload uitblinkt en waar niet.

Wat Is Payload CMS? (En Waarom Developers Het Geweldig Vinden)

Payload is een open-source, TypeScript-native headless CMS en applicatieframework dat in je Next.js-app draait. In tegenstelling tot gehoste CMS-platforms geeft Payload je een code-first configuratie, drie ingebouwde API's (REST, GraphQL, Local), en een volledig aanpasbaar adminpaneel — allemaal vanuit één codebase. Volgens de officiële Payload-documentatie is het ontworpen als "de beste manier om een moderne backend te bouwen."

Het project startte in 2021 als een Node.js/Express-CMS. Payload 2 verscheen in 2023 met verbeterde TypeScript-ondersteuning. Daarna veranderde Payload 3 alles: het CMS verhuisde naar binnen je Next.js-applicatie. Geen apart serverproces. Geen aparte deployment. Je CMS en je frontend delen dezelfde Next.js-runtime, dezelfde routes, dezelfde build-pipeline.

Dat is een fundamenteel andere architectuur dan wat Sanity, Strapi of Contentful bieden. En dat heeft echte gevolgen voor hoe je bouwt, deployt en nadenkt over je contentlaag.

De Code-First Filosofie

De meeste CMS-platforms geven je een GUI om je contentmodel te definiëren. Klik op "veld toevoegen", kies "tekst", geef het de naam "titel". Payload draait dit om: je definieert alles in TypeScript-bestanden. Je schema is code. Het leeft in versiebeheer. Je reviewt het in pull requests.

Dit betekent geen schema-drift meer tussen omgevingen, geen verrassingen als "iemand heeft het contentmodel in staging aangepast en niemand weet wat er is gebeurd". Als je ooit in een team hebt gewerkt waar het contentmodel in een cloud-dashboard stond, weet je precies waarom dit belangrijk is.

Payload 3-Architectuur — Native Next.js

Payload 3 draait niet naast je Next.js-app. Het draait erbinnen. Het adminpaneel zit op /app/(payload)/admin, je API-routes leven in /app/(payload)/api, en je frontend-pagina's staan in hetzelfde project. Als je Next.js al in productie hebt gebruikt, voelt dit meteen vertrouwd.

Belangrijkste Functies Die Payload Onderscheiden

Payload's opvallendste functies zijn Collections voor contentmodellering, een drievoudige API-laag (REST, GraphQL, Local), op rollen gebaseerde toegangscontrole met granulariteit op veldniveau, ingebouwde authenticatie, de Lexical rich text-editor en live preview voor visuele bewerking. Dit is wat elk van deze functies concreet betekent voor je codebase.

Collections, Globals & Velden

Collections zijn het kernprimitieve van Payload voor contentmodellering. Zie ze als databasetabellen, maar volledig gedefinieerd in TypeScript. Elke Collection krijgt zijn eigen REST- en GraphQL-endpoints, zijn eigen adminpaneel-weergave en zijn eigen toegangscontroleregels — allemaal gegenereerd vanuit één configuratiebestand.

// 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 werken vergelijkbaar, maar voor singleton-data — je site-instellingen, navigatieconfiguratie, footer-content. Één instantie, geen collection-lijstweergave, gewoon één bewerkbaar document.

De Drievoudige API-Laag (REST, GraphQL, Local)

Dit is waar Payload echt alle andere open-source CMS-en overtreft. Je krijgt drie manieren om je content te bevragen, elk geoptimaliseerd voor verschillende contexten:

• Local API: Queries aan de serverzijde met nul HTTP-overhead. Roep je CMS rechtstreeks aan in Next.js server components. Geen netwerkreis, geen serialisatiekosten. In onze tests reduceerde de Local API paginalaadtijden met ~40ms ten opzichte van REST-calls op dezelfde server.
• REST API: Automatisch gegenereerde endpoints voor externe clients, mobiele apps of integraties van derden.
• GraphQL API: Flexibele queries voor frontends die hun dataverzoeken precies willen vormgeven.

Zo ziet een Local API-call eruit in een Next.js server component:

// 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>
}

Geen fetch-call. Geen API-URL. Geen authenticatietoken. Je bevraagt je database rechtstreeks vanuit een server component, en TypeScript geeft je volledige type-veiligheid op het antwoord. Dat is moeilijk te overtreffen.

Toegangscontrole & Authenticatie

Payload's toegangscontrolesysteem is op functies gebaseerd. In plaats van rechten te configureren in een dashboard, schrijf je TypeScript-functies die true of false retourneren. Op veldniveau, collection-niveau of operatieniveau — jij bepaalt de granulariteit.

// Voorbeeld: Alleen gepubliceerde posts zijn publiekelijk leesbaar
access: {
  read: ({ req }) => {
    if (req.user) return true // Ingelogde gebruikers zien alles
    return { status: { equals: 'published' } } // Publiek ziet alleen gepubliceerd
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Authenticatie is ingebouwd: JWT-tokens, refresh tokens, wachtwoord-vergeten-flow, e-mailverificatie. Je hebt Clerk of NextAuth niet nodig, tenzij je ze specifiek wilt. Voor veel projecten is Payload's auth meer dan genoeg.

Lexical Rich Text-Editor

Payload gebruikt Lexical, Meta's rich text-framework (hetzelfde team achter Draft.js, maar beter). Je kunt aangepaste blokken, inline-elementen en slash-commando's toevoegen. De editor serialiseert naar een gestructureerd JSON-formaat dat je kunt omzetten naar HTML of React-componenten.

Dit maakt uit omdat de meeste CMS rich text-editors ofwel te basic zijn (gewone textarea) of te ondoorzichtig (WYSIWYG die onvoorspelbare HTML genereert). Lexical geeft je een gestructureerde, voorspelbare output die jij volledig beheert.

Live Preview & Visuele Bewerking

Payload 3 wordt geleverd met live preview: redacteuren zien hun contentwijzigingen in realtime weerspiegeld op de daadwerkelijke frontend, naast het adminpaneel. Dit vult een aanzienlijke lacune ten opzichte van Strapi, dat helemaal geen visuele bewerking heeft.

Het is niet zo gepolijst als Sanity Studio's realtime samenwerkingsfuncties — Sanity's visuele bewerking is echt de beste in zijn klasse. Maar voor teams die "goed genoeg" visuele preview nodig hebben zonder Sanity's per-seat-prijzen te betalen, doet Payload's implementatie het werk.

Versiebeheer, Concepten & Automatisch Opslaan

Payload bevat ingebouwd conceptbeheer, versiegeschiedenis en automatisch opslaan — functies die geen van de best-scorende Payload-gidsen zelfs maar vermelden. Je kunt versiebeheer per collection inschakelen (zoals we deden in het Posts-voorbeeld hierboven met versions: { drafts: true }), een maximaal aantal versies instellen en revisies vergelijken in de admin-UI.

Voor redactionele teams betekent dit geen "ik heb per ongeluk een concept gepubliceerd"-rampen meer. Voor developers betekent het dat je geen apart versiebeheersysteem hoeft te bouwen.

Aan de Slag met Payload CMS

Om een nieuw Payload-project te starten, voer je npx create-payload-app@latest uit, selecteer je een template (website of leeg), kies je je database-adapter (PostgreSQL, MongoDB of SQLite) en heb je binnen twee minuten een werkend adminpaneel op localhost:3000/admin. De officiële installatiegids behandelt randgevallen.

Installatie

Je hebt Node.js 18+ en een pakketbeheerder nodig. Dat is alles.

# Maak een nieuw Payload-project
npx create-payload-app@latest my-cms

# De CLI vraagt je:
# - Projectnaam
# - Template (website, leeg, e-commerce)
# - Database (postgres, mongodb, sqlite)

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

De website-template is het beste startpunt voor de meeste projecten — het wordt geleverd met een werkende blog, pagina's-collection, media-uploads en een frontend. De lege template is voor wanneer je vanaf nul wilt bouwen.

Projectstructuur

Na de installatie ziet je project eruit als een standaard Next.js-app met Payload erin verwerkt:

my-cms/
  app/
    (frontend)/          # Je websitepagina's
    (payload)/
      admin/             # Adminpaneel-routes (automatisch gegenereerd)
      api/               # REST + GraphQL-endpoints
  collections/           # Je contentmodeldefinities
  globals/               # Singleton-content (instellingen, nav)
  payload.config.ts      # Hoofdconfiguratie van Payload
  payload-types.ts       # Automatisch gegenereerde TypeScript-typen

Het bestand payload.config.ts is het hart van alles:

// 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' },
})

Je Eerste Collection

Zodra de dev-server draait, maak je een nieuwe collection aan door een bestand toe te voegen aan /collections. Payload genereert automatisch de admin-UI, API-endpoints en TypeScript-typen vanuit je configuratie. Hier is een eenvoudige 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' },
          ],
        },
      ],
    },
  ],
}

Voeg het toe aan de collections-array in je payload.config.ts, herstart de dev-server en je hebt een volledig functionele pagina-bouwer met een visuele admin-interface. Geen plugins, geen marketplace-downloads.

Database-Opties — Postgres, MongoDB & SQLite

Payload ondersteunt drie database-adapters: PostgreSQL (aanbevolen voor productie), MongoDB (voor documentzware modellen of bestaande Mongo-stacks) en SQLite (alleen voor lokale ontwikkeling en prototyping). Het adapter-patroon betekent dat je applicatiecode hetzelfde blijft ongeacht welke database je kiest.

Als je van nul begint, kies dan voor PostgreSQL. Het verwerkt relationele data beter (en de meeste CMS-data is relationeel), heeft uitstekende serverless-opties via Neon en Supabase, en is wat het Payload-team aanbeveelt. Bekijk onze PostgreSQL vs MySQL-vergelijking voor meer context over waarom Postgres moderne app-ontwikkeling domineert.

Pro-tip: Als je naar Vercel deployt, koppel Payload dan aan Neon Postgres. Neon's connection pooling verwerkt serverless cold starts netjes, wat belangrijk is omdat Vercel constant nieuwe functie-instanties opstart.

De Figma-Overname — Wat Dit Betekent voor Developers

Figma nam Payload over in juni 2025. De MIT-licentie en open-source codebase blijven ongewijzigd. Payload Cloud pauzeerde nieuwe aanmeldingen terwijl het team een vervanger bouwt, maar self-hosting wordt niet beïnvloed. Voor developers is de grootste vraag niet "is Payload dood?" — maar "wat doe ik met hosting?"

We volgden Payload Cloud als hostingoptie voor een klantproject toen de overname werd aangekondigd. Dit is wat we leerden door over te stappen op self-hosting, en wat de overname eigenlijk betekent voor jouw projecten.

Op 17 juni 2025 kondigde Figma de overname aan op hun blog. Het Payload-team publiceerde hun eigen aankondiging dezelfde dag. Het volledige Payload-team is bij Figma terechtgekomen.

Wat Veranderde (En Wat Niet)

Wat hetzelfde blijft:

• MIT-licentie. Deze kan niet worden ingetrokken. De GitHub-repository blijft actief en open voor bijdragen vanuit de community.
• De codebase. Payload 3 werkt precies hetzelfde als voor de overname.
• Self-hosting. Je kunt Payload overal deployen, voor altijd.

Wat veranderde:

• Payload Cloud pauzeerde nieuwe aanmeldingen. Bestaande klanten kunnen doorgaan, maar nieuwe projecten kunnen Payload's beheerde hosting niet gebruiken.
• De teamfocus verschoof. Het Payload-team bouwt nu waarschijnlijk wat "Figma CMS" zal worden — de kloof overbruggen tussen Figma-designs en live content. De specifieke details zijn speculatief, maar de richting is duidelijk.
• Aandacht van de community. Sommige developers maken zich zorgen over het patroon van "overgenomen-en-dan-verlaten" dat open-source projecten teistert. De MIT-licentie beperkt het slechtste scenario, maar het is een legitieme zorg.

Moet Je Nog Steeds Kiezen voor Payload?

Eerlijk gezegd? Ja, met kanttekeningen.

Het goede: Figma's middelen betekenen meer technisch talent achter het project. De MIT-licentie betekent dat het ergste geval is dat je het forkt. De codebase is volwassen, goed gedocumenteerd en actief gebruikt in productie door duizenden projecten.

Het zorgwekkende: Figma's belangen kunnen na verloop van tijd afwijken van de behoeften van de open-source community. Het Payload Cloud-gat dwingt je om hosting zelf te regelen. En als je risicomijdend bent, is de onzekerheid over de langetermijnrichting reëel.

Onze mening: als je zelf kunt hosten (wat je zou moeten kunnen — het is niet moeilijk), blijft Payload het beste open-source, code-first headless CMS beschikbaar. Wacht niet op "Figma CMS". Bouw vandaag met Payload 3, host het zelf en ga verder.

Hoe Je Payload CMS Deployt in 2026

Nu Payload Cloud gepauzeerd is voor nieuwe aanmeldingen, zijn je belangrijkste deployment-opties in 2026: Vercel (snelste setup, let op cold starts), Docker op een VPS (beste voor actieve redacteuren, €7-45/mo), Railway/Render/Fly.io (beheerde containers) of Cloudflare Workers (goedkoopst, ~$5-10/mo). Volgens Payload's deployment-documentatie werkt elke Node.js-hosting die Next.js ondersteunt.

We hebben Payload gedeployd naar zowel Vercel als een Docker-gebaseerde VPS. Dit verraste ons: Vercel's cold starts maakten het adminpaneel traag voor redacteuren die maar een paar keer per week inlogden. De VPS, ondanks meer setup-werk, bood een consistent betere redactionele ervaring.

Vercel (Snelste Setup)

One-click deploy met Neon Postgres en Vercel Blob voor bestandsuploads. Snelste weg naar productie.

Voordelen: Nul infrastructuurbeheer, uitstekend CDN, geweldig voor sites met weinig redactionele activiteit. Nadelen: Adminpaneel cold starts (3-5 seconden na inactiviteit), Postgres-verbindingsuitputting bij zware queries, time-out-plafond van 10 seconden kan bulk-operaties breken. Het beste voor: Marketingsites, portfolio's, blogs met weinig bewerkingen.

Voor meer context over Vercel's sterke en zwakke punten, zie onze Vercel vs Netlify-vergelijking.

Docker op een VPS (Beste voor Productie)

Een Docker Compose-setup op Hetzner, DigitalOcean of AWS EC2. Dit past beter bij Payload's architectuur dan serverless, omdat Payload een persistent serverproces verwacht.

# 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:

Voordelen: Persistent server (geen cold starts), voorspelbare kosten (€7-45/mo op Hetzner), volledige controle over de stack. Nadelen: Jij beheert de server, SSL, back-ups en updates. Het beste voor: Bureaus, actieve redactionele teams, multi-tenant-setups, apps met intensief admingebruik.

Een gedetailleerde hostingvergelijking van Build with Matija behandelt extra VPS-providers en configuraties.

Beheerde Containers (Railway, Render, Fly.io)

Als Docker op een VPS te veel ops-werk klinkt, splitsen beheerde containerplatforms het verschil. Railway is bijzonder populair in de Payload-community — ze hebben een Payload-template dat met één klik deployt.

Bekijk onze Railway vs Render vs Fly.io-vergelijking voor een diepere blik op deze platforms.

Het beste voor: Teams die persistente servers willen zonder infrastructuur rechtstreeks te beheren.

Cloudflare Workers (Goedkoopst)

De nieuwste optie. Payload heeft een Cloudflare Workers-adapter toegevoegd die draait op edge-functies met D1 (SQLite) of Hyperdrive (Postgres-proxy). Nog een beetje experimenteel, maar de kosten zijn onverslaanbaar: ~$5-10/mo voor de meeste projecten.

Het beste voor: Zijprojecten, persoonlijke sites, budgetbewuste deploys waarbij je comfortabel bent met nieuwere, minder geteste infrastructuur.

Ons oordeel: Voor de meeste productie Payload-projecten met actieve redacteuren is Docker op een VPS de beste standaard. Het is goedkoper dan je zou denken, elimineert cold start-problemen en geeft je volledige controle. Gebruik Vercel alleen als je redacteuren zelden werken en je nul ops-overhead wilt.

Payload CMS Prijzen — Wat Het Werkelijk Kost

Payload zelf is gratis en MIT-gelicentieerd. Je echte kosten zijn hosting en (optioneel) professionele ontwikkeling. Dit zijn de werkelijke cijfers, gebaseerd op echte setups en de prijsanalyse van Build with Matija.

Ter vergelijking: Contentful's Team-plan begint op $300/mo. Sanity's Team-plan is $99/mo per project. Strapi Cloud begint op $29/mo. Payload's $0 softwarekosten plus $7-25/mo hosting zijn moeilijk te overtreffen — zeker voor bureaus die klantprojecten bouwen waarbij per-seat-prijzen de marges doden.

Payload vs Sanity vs Strapi vs Contentful — Snelle Vergelijking

Kies Payload als je code-first controle en self-hosting wilt. Kies Sanity voor de beste visuele bewerking en realtime samenwerking. Kies Strapi voor een snel adminpaneel met plugin-ecosysteem. Kies Contentful voor enterprise-grade infrastructuur met SLA-garanties. We gebruiken Sanity voor techsy.io, dus we hebben uit de eerste hand ervaring met het vergelijken van deze platforms.

We hebben Payload-gebaseerde projecten gebouwd voor klanten die data-eigendom en self-hosting nodig hebben, en we draaien onze eigen contentpipeline op Sanity. Beide zijn uitstekend — de juiste keuze hangt af van de technische comfortzone van je team en hostingvoorkeuren. Als je headless CMS-opties evalueert voor een project, helpen we je graag kiezen.

Voor diepere duiken in elk platform, bekijk onze gidsen: beste headless CMS in 2026, en afzonderlijke gidsen voor Sanity, Strapi en Contentful komen binnenkort.

Wanneer Payload CMS NIET Te Gebruiken

Sla Payload over als je team niet-technisch is en een WordPress-achtige GUI nodig heeft, als je onmiddellijk beheerde cloud-hosting nodig hebt zonder self-hosting, als je redacteuren visuele bewerking op Sanity Studio-niveau willen, of als je een plugin-marketplace nodig hebt voor snelle functie-uitbreiding. Eerlijk zijn over beperkingen wekt meer vertrouwen dan doen alsof ze niet bestaan.

We hebben Payload afgeraden aan klanten wier redactionele teams geen TypeScript-ervaring hadden. Dit zijn de gevallen waarbij je elders moet kijken:

• Niet-technische teams. Payload vereist TypeScript-kennis om te configureren. Als de redacteuren van je klant geen code kunnen aanraken en zelf het contentmodel moeten kunnen wijzigen, zijn WordPress of Sanity betere keuzes.
• Je hebt nu beheerde hosting nodig. Nu Payload Cloud gepauzeerd is voor nieuwe aanmeldingen, moet je zelf hosten. Als het beheren van een server (zelfs een eenvoudige Docker-setup) een dealbreaker is, neemt de cloud-aanpak van Contentful of Sanity die last weg.
• Intensieve redactionele samenwerking. Sanity Studio's realtime samenwerking — meerdere redacteuren die tegelijkertijd aan hetzelfde document werken met aanwezigheidsindicatoren — is gepolijster dan alles wat Payload biedt. Als je een groot redactioneel team hebt, wint Sanity hier.
• Plugin-gedreven ontwikkeling. Strapi heeft een grotere plugin-marketplace. Heb je een SEO-plugin nodig, een sitemap-generator, een e-mailintegratie? Strapi heeft waarschijnlijk een. Payload's ecosysteem groeit, maar is kleiner.
• Je gebruikt Next.js niet. Payload 3 is architecturaal gekoppeld aan Next.js. Als je frontend Astro, Remix, Nuxt of SvelteKit is, is het grootste voordeel van Payload (de Local API in server components) niet van toepassing. Je krijgt nog steeds REST en GraphQL, maar op dat punt voelen Strapi of Directus misschien natuurlijker aan.

FAQ

Wat is Payload CMS en hoe werkt het?

Payload is een open-source, TypeScript-native headless CMS en applicatieframework gebouwd op Next.js. Je definieert je contentmodel in TypeScript-configuratiebestanden, en Payload genereert automatisch een adminpaneel, REST API, GraphQL API en Local API. Het draait binnen je Next.js-app als één deploybare eenheid.

Is Payload CMS gratis te gebruiken?

Payload is volledig gratis onder de MIT-licentie. De software kost niets om te downloaden, te gebruiken of te wijzigen. Payload Cloud (beheerde hosting) was $35-199/mo maar is momenteel gepauzeerd voor nieuwe aanmeldingen na de Figma-overname. Self-hosting op een VPS kost €7-45/mo afhankelijk van je provider.

Wat is er gebeurd met Payload en Figma?

Figma nam Payload over op 17 juni 2025. Het volledige Payload-team trad toe tot Figma. De open-source MIT-licentie en GitHub-repository blijven ongewijzigd. Payload Cloud pauzeerde nieuwe aanmeldingen. Self-hosting werkt normaal door. Het team bouwt waarschijnlijk een Figma-geïntegreerd CMS-product, maar details zijn nog niet aangekondigd.

Welke database gebruikt Payload CMS?

Payload ondersteunt drie databases via een adapter-patroon: PostgreSQL (aanbevolen voor productie, werkt met Neon en Supabase voor serverless), MongoDB (goed voor documentzware modellen of Payload 2-upgrades), en SQLite (alleen lokale ontwikkeling en CI). Je applicatiecode blijft hetzelfde ongeacht welke adapter je kiest.

Hoe deploy ik Payload CMS in 2026?

Nu Payload Cloud gepauzeerd is, deploy je naar Vercel met Neon Postgres (makkelijkst), Docker op een VPS zoals Hetzner (beste voor productie met actieve redacteuren), Railway of Render (beheerde containers), of Cloudflare Workers (goedkoopst). Voor de meeste productiesites met regelmatige redactionele activiteit biedt een Docker-gebaseerde VPS de beste ervaring.

Is Payload CMS beter dan Strapi?

Payload wint op TypeScript-native developer-ervaring, Next.js-integratie en de unieke Local API voor queries zonder overhead aan de serverzijde. Strapi wint op zijn plugin-marketplace, GUI-gebaseerde schema-bewerking en bredere framework-compatibiliteit. Als je team TypeScript schrijft en Next.js gebruikt, is Payload de sterkere keuze. Evalueer anders Strapi.

Wat is Payload's Local API?

De Local API is een query-laag aan de serverzijde die je database rechtstreeks aanroept met nul HTTP-overhead. In plaats van REST- of GraphQL-calls te maken, importeer je Payload en bevraag je collections direct in Next.js server components. Dit elimineert netwerkreisen en serialisatiekosten, wat resulteert in snellere paginalaadtijden. Geen enkel ander headless CMS biedt dit.

Kan Payload CMS grootschalige applicaties aan?

Payload ondersteunt PostgreSQL met connection pooling (via Neon of PgBouncer), op rollen gebaseerde toegangscontrole met granulariteit op veldniveau, concept- en versiebeheerworkflows, en multi-tenant-architecturen. Enterprises en bureaus gebruiken Payload in productie voor contentintensieve applicaties. De nul-overhead-queries van de Local API verbeteren de prestaties op schaal.

Hoe vergelijkt Payload met Sanity?

Payload is self-hosted, code-first en MIT-gelicentieerd met een Local API voor serverzijde-prestaties. Sanity is cloud-hosted met superieure visuele bewerking, realtime samenwerking en de GROQ-querytaal. Payload geeft je meer infrastructuurcontrole en lagere kosten. Sanity geeft je betere redactionele tools en nul hostingbeheer.

Wat zijn de nadelen van Payload CMS?

Payload vereist TypeScript-kennis voor configuratie, heeft geen beheerde cloud-hosting voor nieuwe gebruikers na de Figma-overname, biedt een kleiner plugin-ecosysteem dan Strapi, en is architecturaal gebonden aan Next.js in versie 3. Niet-technische teams kunnen moeite hebben met de code-first aanpak, en de Figma-overname creëert enige langetermijn-onzekerheid.