Payload CMS 2026: Hvorfor Figma købte det (og bør du adoptere det?)

Payload CMS 2026: Hvorfor Figma købte det (og bør du adoptere det?)

Payload er et open source, TypeScript-native headless CMS, der lever inde i din Next.js-app – ikke ved siden af den, ikke i en separat container, men bogstaveligt talt i samme /app-mappe. Hvis du er blevet brændt af hosted CMS-platforme, der tager betaling pr. bruger eller låser dit indhold bag proprietære API'er, er Payload værd at kigge nærmere på.

Men 2026 bød på en overraskelse: Figma opkøbte Payload, Payload Cloud stoppede nye tilmeldinger, og udviklere skal pludselig finde ud af hosting selv. Denne guide dækker alt fra første installation til produktion-deployment med aktuelle kodeeksempler fra Payload 3 og ærlige vurderinger af, hvor Payload skinner, og hvor det ikke gør.

Hvad er Payload CMS? (Og hvorfor udviklere elsker det)

Payload er et open source, TypeScript-native headless CMS og applikationsframework, der kører inde i din Next.js-app. I modsætning til hosted CMS-platforme giver Payload dig en code-first konfiguration, tre indbyggede API'er (REST, GraphQL, Local) og et fuldt tilpasseligt adminpanel, alt sammen fra én kodebase. Ifølge den officielle Payload-dokumentation er det designet til at være "den bedste måde at bygge en moderne backend på."

Projektet startede i 2021 som et Node.js/Express CMS. Payload 2 ankom i 2023 med forbedret TypeScript-support. Derefter ændrede Payload 3 spillet fuldstændigt: CMS'et flyttede ind i din Next.js-applikation. Ingen separat serverproces. Ingen separat deployment. Dit CMS og din frontend deler samme Next.js-runtime, samme ruter og samme build-pipeline.

Det er en genuint anderledes arkitektur end det, Sanity, Strapi eller Contentful tilbyder. Og det har reelle konsekvenser for, hvordan du bygger, deployer og tænker på dit indholdslag.

Code-first-filosofien

De fleste CMS-platforme giver dig et GUI til at definere din indholdsmodel. Klik på "tilføj felt", vælg "tekst", navngiv det "titel". Payload vender dette på hovedet: du definerer alt i TypeScript-filer. Dit skema er kode. Det lever i versionskontrol. Du gennemgår det i pull requests.

Det betyder ingen skema-drift mellem miljøer, ingen overraskelser af typen "nogen ændrede indholdsmodellen i staging, og ingen ved, hvad der skete". Hvis du har arbejdet på et team, hvor indholdsmodellen levede i et cloud-dashboard, ved du præcis, hvorfor dette er vigtigt.

Payload 3-arkitektur, native til Next.js

Payload 3 kører ikke ved siden af din Next.js-app. Det kører inde i den. Adminpanelet sidder på /app/(payload)/admin, dine API-ruter ligger i /app/(payload)/api, og dine frontend-sider eksisterer side om side i samme projekt. Hvis du har brugt Next.js i produktion før, vil du føle dig hjemme.

Nøglefunktioner, der adskiller Payload

Payloads fremtrædende funktioner inkluderer Collections til indholdsmodellering, et tredobbelt API-lag (REST, GraphQL, Local), rollebaseret adgangskontrol med felt-niveau granularitet, indbygget godkendelse, Lexical rich text-editoren og live preview til visuel redigering. Her er hvad hver af disse faktisk betyder for din kodebase.

Collections, Globals & Fields

Collections er Payloads kerne-primitiv for indholdsmodellering. Tænk på dem som databasetabeller, men defineret udelukkende i TypeScript. Hver Collection får sine egne REST- og GraphQL-endpoints, sit eget adminpanel-view og sine egne adgangskontrolregler, alt genereret fra en enkelt konfigurationsfil.

// 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 fungerer på samme måde, men for singleton-data som dine site-indstillinger, navigationskonfiguration eller footer-indhold. Én instans, ingen collections-listevisning, bare et enkelt redigerbart dokument.

Det tredobbelte API-lag (REST, GraphQL, Local)

Her skiller Payload sig virkelig ud fra alle andre open source CMS'er. Du får tre måder at forespørge dit indhold på, hver optimeret til forskellige kontekster:

• Local API: Server-side queries uden HTTP-overhead. Kald dit CMS direkte i Next.js server-komponenter. Ingen netværks-round-trip, ingen serialiseringsomkostninger. I vores tests reducerede Local API sideindlæsningstider med ~40 ms sammenlignet med REST-kald på samme server.
• REST API: Auto-genererede endpoints til eksterne klienter, mobilapps eller tredjepartsintegrationer.
• GraphQL API: Fleksible queries til frontends, der har brug for at forme deres dataforespørgsler præcist.

Sådan ser et Local API-kald ud i en Next.js server-komponent:

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

Intet fetch-kald. Ingen API-URL. Ingen autentificeringstoken. Du forespørger din database direkte fra en server-komponent, og TypeScript giver dig fuld typesikkerhed på svaret. Det er svært at slå.

Adgangskontrol og godkendelse

Payloads adgangskontrolsystem er funktionsbaseret. I stedet for at konfigurere tilladelser i et dashboard skriver du TypeScript-funktioner, der returnerer true eller false. På felt-niveau, collections-niveau eller operations-niveau bestemmer du granulariteten.

// Example: Only published posts are publicly readable
access: {
  read: ({ req }) => {
    if (req.user) return true // Logged-in users see everything
    return { status: { equals: 'published' } } // Public sees only published
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Godkendelse kommer indbygget: JWT-tokens, refresh tokens, glemt-adgangskode-flow, e-mailbekræftelse. Du behøver ikke Clerk eller NextAuth, medmindre du specifikt ønsker det. For mange projekter er Payloads auth mere end rigeligt.

Lexical Rich Text Editor

Payload bruger Lexical, Metas rich text-framework (samme team bag Draft.js, men bedre). Du kan tilføje custom blocks, inline-elementer og slash-kommandoer. Editoren serialiserer til et struktureret JSON-format, som du kan konvertere til HTML eller React-komponenter.

Dette er vigtigt, fordi de fleste CMS rich text-editorer enten er for basale (almindelig textarea) eller for uigennemskuelige (WYSIWYG, der genererer uforudsigelig HTML). Lexical giver dig et struktureret, forudsigeligt output, som du har fuld kontrol over.

Live Preview og visuel redigering

Payload 3 leveres med live preview: redaktører ser deres indholdsændringer afspejlet på den faktiske frontend i realtid, side om side med adminpanelet. Dette udfylder et betydeligt hul sammenlignet med Strapi, som slet ikke har visuel redigering.

Det er ikke helt så poleret som Sanity Studios realtidssamarbejdsfunktioner – Sanitys visuelle redigering er genuint i verdensklasse. Men for teams, der har brug for "god nok" visuel preview uden at betale Sanitys pris pr. bruger, får Payloads implementation jobbet gjort.

Versionering, kladder og autosave

Payload inkluderer indbygget kladdehåndtering, versionshistorik og autosave – funktioner, som nul af de topplacerede Payload-guides overhovedet nævner. Du kan aktivere versionering pr. collection (vi gjorde det i Posts-eksemplet ovenfor med versions: { drafts: true }), sætte et maksimalt antal versioner og sammenligne revisioner i admin-UI'en.

For redaktionelle teams betyder det ikke flere "jeg udgav utilsigtet en kladde"-katastrofer. For udviklere betyder det, at du ikke skal bolt på et separat versioneringssystem.

Kom i gang med Payload CMS

For at starte et nyt Payload-projekt skal du køre npx create-payload-app@latest, vælge en skabelon (website eller blank), vælge din databaseadapter (PostgreSQL, MongoDB eller SQLite), og så har du et fungerende adminpanel på localhost:3000/admin på under to minutter. Den officielle installationsguide dækker edge cases.

Installation

Du skal bruge Node.js 18+ og en package manager. Det er det.

# Create a new Payload project
npx create-payload-app@latest my-cms

# The CLI asks you:
# - Project name
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

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

Website-skabelonen er det bedste udgangspunkt for de fleste projekter; den leveres med en fungerende blog, pages-collection, medieuploads og en frontend. Den blanke skabelon er til, når du vil bygge fra bunden.

Projektstruktur

Efter installationen ligner dit projekt en standard Next.js-app med Payload drysset indover:

my-cms/
  app/
    (frontend)/          # Your website pages
    (payload)/
      admin/             # Admin panel routes (auto-generated)
      api/               # REST + GraphQL endpoints
  collections/           # Your content model definitions
  globals/               # Singleton content (settings, nav)
  payload.config.ts      # Main Payload configuration
  payload-types.ts       # Auto-generated TypeScript types

Filen payload.config.ts er hjertet i alt:

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

Din første Collection

Når dev-serveren kører, skal du oprette en ny collection ved at tilføje en fil til /collections. Payload auto-genererer admin-UI'en, API-endpoints og TypeScript-typer fra din konfiguration. Her er en simpel 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' },
          ],
        },
      ],
    },
  ],
}

Tilføj den til din payload.config.ts collections-array, genstart dev-serveren, og så har du en fuldt funktionel page builder med et visuelt admin-interface. Ingen plugins, ingen marketplace-downloads.

Databasevalg: PostgreSQL, MongoDB og SQLite

Payload understøtter tre databaseadaptere: PostgreSQL (anbefales til produktion), MongoDB (til dokument-tunge modeller eller eksisterende Mongo-stacks) og SQLite (kun til lokal udvikling og prototyping). Adapter-mønsteret betyder, at din applikationskode forbliver den samme uanset hvilken database du vælger.

Hvis du starter fra bunden, så vælg PostgreSQL. Det håndterer relationelle data bedre (og de fleste CMS-data er relationelle), har fremragende serverless-muligheder gennem Neon og Supabase, og er hvad Payload-teamet anbefaler. Tjek vores PostgreSQL vs MySQL-sammenligning for mere kontekst om, hvorfor Postgres dominerer moderne app-udvikling.

Pro-tip: Hvis du deployer til Vercel, så par Payload med Neon Postgres. Neons connection pooling håndterer serverless cold starts elegant, hvilket er vigtigt, fordi Vercel konstant spinner nye function-instances op.

Figma-opkøbet: Hvad det betyder for udviklere

Figma opkøbte Payload i juni 2025. MIT-licensen og open source-kodebasen forbliver uændrede. Payload Cloud har pauset nye tilmeldinger, mens teamet bygger en erstatning, men self-hosting er upåvirket. For udviklere er det største spørgsmål ikke "er Payload dødt?", men "hvad gør jeg ved hosting?"

Vi holdt øje med Payload Cloud som en hostingmulighed for et klientprojekt, da opkøbet blev annonceret. Her er hvad vi lærte ved at skifte til self-hosting, og hvad opkøbet faktisk betyder for dine projekter.

Den 17. juni 2025 annoncerede Figma opkøbet på deres blog. Payload-teamet publicerede deres egen annonce samme dag. Hele Payload-teamet blev absorberet i Figma.

Hvad ændrede sig (og hvad der ikke gjorde)

Hvad der forbliver det samme:

• MIT-licens. Denne kan ikke trækkes tilbage. GitHub-repositoriet forbliver aktivt og åbent for community-bidrag.
• Kodebasen. Payload 3 fungerer nøjagtigt som før opkøbet.
• Self-hosting. Du kan deploye Payload hvor som helst, for evigt.

Hvad der ændrede sig:

• Payload Cloud har pauset nye tilmeldinger. Eksisterende kunder kan fortsætte, men nye projekter kan ikke bruge Payloads managed hosting.
• Teamets fokus skiftede. Payload-teamet bygger nu det, der sandsynligvis vil blive til "Figma CMS", som skal binde hullet mellem Figma-designs og live-indhold. Specifikkerne er spekulative, men retningen er klar.
• Community-opmærksomhed. Nogle udviklere bekymrer sig om mønsteret "opkøbt-og-så-forladt", der plager open source-projekter. MIT-licensen afbøder det værste scenarie, men det er en legitim bekymring.

Bør du stadig vælge Payload?

Ærligt talt? Ja, med forbehold.

Det gode: Figmas ressourcer betyder mere engineering-talent bag projektet. MIT-licensen betyder, at det værste scenarie er, at du fork'er det. Kodebasen er moden, veldokumenteret og aktivt brugt i produktion af tusindvis af projekter.

Det bekymrende: Figmas incitamenter kan divergere fra open source-communityets behov over tid. Hullet efter Payload Cloud tvinger dig til at håndtere hosting selv. Og hvis du er risikoavers, er usikkerheden omkring den langsigtede retning reel.

Vores vurdering: Hvis du er komfortabel med self-hosting (hvilket du bør være, det er ikke svært), forbliver Payload det bedste open source, code-first headless CMS tilgængeligt. Vent ikke på "Figma CMS". Byg med Payload 3 i dag, self-host, og kom videre.

Sådan deployer du Payload CMS i 2026

Med Payload Cloud pauset for nye tilmeldinger er dine primære deploymentsmuligheder i 2026: Vercel (hurtigst opsætning, pas på cold starts), Docker på en VPS (bedst til aktive redaktører, EUR 7-45/md.), Railway/Render/Fly.io (managed containers) eller Cloudflare Workers (billigst ved ~$5-10/md.). Ifølge Payloads deploymentsdocs vil enhver Node.js-hosting, der understøtter Next.js, fungere.

Vi har deployet Payload til både Vercel og en Docker-baseret VPS. Her er hvad der overraskede os: Vercels cold starts gjorde adminpanelet sløvt for redaktører, der kun loggede ind et par gange om ugen. VPS'en, trods krævet mere opsætning, gav en konsekvent bedre redaktionel oplevelse.

Vercel (Hurtigst opsætning)

One-click deploy med Neon Postgres og Vercel Blob til filuploads. Hurtigste vej til produktion.

Fordele: Nul infrastrukturstyring, fremragende CDN, godt til sites med let redaktionel aktivitet. Ulemper: Cold starts i adminpanel (3-5 sekunder efter inaktivitet), Postgres-connection exhaustion under tunge queries, 10-sekunders timeout-loft kan bryde bulk-operationer. Bedst til: Marketingsites, portfolios, blogs med sjælden redigering.

For mere kontekst om Vercels styrker og begrænsninger, se vores Vercel vs Netlify-sammenligning.

Docker på en VPS (Bedst til produktion)

En Docker Compose-opsætning på Hetzner, DigitalOcean eller AWS EC2. Dette matcher Payloads arkitektur bedre end serverless, fordi Payload forventer en persistent serverproces.

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

Fordele: Persistent server (ingen cold starts), forudsigelige omkostninger (EUR 7-45/md. på Hetzner), fuld kontrol over stacken. Ulemper: Du styrer serveren, SSL, backups og opdateringer. Bedst til: Bureauer, aktive redaktionelle teams, multi-tenant opsætninger, apps med tung admin-brug.

En detaljeret hosting-sammenligning fra Build with Matija dækker yderligere VPS-udbydere og konfigurationer.

Managed Containers (Railway, Render, Fly.io)

Hvis Docker på en VPS lyder som for meget ops-arbejde, deler managed container-platforme forskellen. Railway er særligt populært i Payload-communityet; de har en Payload-skabelon, der deployer med ét klik.

Tjek vores Railway vs Render vs Fly.io-sammenligning for et dybere kig på disse platforme.

Bedst til: Teams, der vil have persistente servere uden at styre infrastrukturen direkte.

Cloudflare Workers (Billigst)

Den nyeste mulighed. Payload tilføjede en Cloudflare Workers-adapter, der kører på edge-funktioner med D1 (SQLite) eller Hyperdrive (Postgres-proxy). Stadig lidt eksperimentel, men prisen kan ikke slås: ~$5-10/md. for de fleste projekter.

Bedst til: Sideprojekter, personlige sites, budgetbevidste deploys hvor du er komfortabel med nyere, mindre testet infrastruktur.

Vores dom: For de fleste produktions-Payload-projekter med aktive redaktører er Docker på en VPS den bedste standard. Det er billigere end du tror, eliminerer cold start-problemer og giver dig fuld kontrol. Brug kun Vercel, hvis dine redaktører er sjældne, og du vil have nul ops-overhead.

Payload CMS-priser: Hvad det faktisk koster

Payload selv er gratis og MIT-licenseret. Dine reelle omkostninger er hosting og (valgfrit) professionel udvikling. Her er hvad tallene faktisk ser ud, baseret på virkelige opsætninger og prisoversigten fra Build with Matija.

Til sammenligning: Contentfuls Team-plan starter ved $300/md. Sanitys Team-plan er $99/md. pr. projekt. Strapi Cloud starter ved $29/md. Payloads $0 softwareomkostning plus $7-25/md. hosting er svær at argumentere imod, især for bureauer, der bygger klientprojekter, hvor pris pr. bruger dræber marginerne.

Payload vs Sanity vs Strapi vs Contentful: Hurtig sammenligning

Vælg Payload, hvis du vil have code-first kontrol og self-hosting. Vælg Sanity for den bedste visuelle redigering og realtidssamarbejde. Vælg Strapi for et hurtigt adminpanel med plugin-økosystem. Vælg Contentful for enterprise-grade infrastruktur med SLA-garantier. Vi bruger Sanity til techsy.io, så vi har førstehåndserfaring med at sammenligne disse platforme.

Vi har bygget Payload-baserede projekter for klienter, der har brug for dataejerskab og self-hosting, og vi kører vores egen content pipeline på Sanity. Begge er fremragende; det rigtige valg afhænger af dit teams tekniske komfort og hostingpræferencer. Hvis du evaluerer headless CMS-muligheder til et projekt, kan vi hjælpe dig med at vælge.

For dybere dyk i hver platform, tjek vores guides: bedste headless CMS i 2026, og individuelle guides til Sanity, Strapi og Contentful kommer snart.

Hvornår du IKKE bør bruge Payload CMS

Spring Payload over, hvis dit team er ikke-teknisk og har brug for et WordPress-lignende GUI, hvis du har brug for instant managed cloud-hosting uden self-hosting-arbejde, hvis dine redaktører ønsker visuel redigering på Sanity Studio-niveau, eller hvis du har brug for et plugin-markedsplads til hurtig funktionsudvidelse. At være ærlig om begrænsninger skaber mere tillid end at lade som om, de ikke eksisterer.

Vi har frarådet Payload til klienter, hvis redaktionelle teams havde nul TypeScript-erfaring. Her er hvornår du bør kigge andetsteds:

• Ikke-tekniske teams. Payload kræver TypeScript-viden for konfiguration. Hvis din klients redaktører ikke kan røre kode og har brug for at modificere indholdsmodellen selv, er WordPress eller Sanity bedre pasformer.
• Du har brug for managed hosting lige nu. Med Payload Cloud pauset for nye tilmeldinger skal du self-hoste. Hvis styring af en server (selv en simpel Docker-opsætning) er en dealbreaker, fjerner Contentful eller Sanitys cloud-hosted tilgang den byrde.
• Tungt redaktionelt samarbejde. Sanity Studios realtidssamarbejde, hvor flere redaktører arbejder på samme dokument samtidigt med presence-indikatorer, er mere poleret end noget, Payload tilbyder. Hvis du har et stort redaktionelt team, vinder Sanity her.
• Plugin-drevet udvikling. Strapi har et større plugin-markedsplads. Har du brug for et SEO-plugin, en sitemap-generator, en e-mail-integration? Strapi har sandsynligvis en. Payloads økosystem vokser, men er mindre.
• Du bruger ikke Next.js. Payload 3 er arkitektonisk bundet til Next.js. Hvis din frontend er Astro, Remix, Nuxt eller SvelteKit, gælder Payloads største fordel (Local API i server-komponenter) ikke. Du ville stadig få REST og GraphQL, men på det tidspunkt vil Strapi eller Directus måske føles mere naturlige.

FAQ

Hvad er Payload CMS, og hvordan virker det?

Payload er et open source, TypeScript-native headless CMS og applikationsframework bygget på Next.js. Du definerer din indholdsmodel i TypeScript-konfigurationsfiler, og Payload genererer automatisk et adminpanel, REST API, GraphQL API og Local API. Det kører inde i din Next.js-app som en enkelt deploybar enhed.

Er Payload CMS gratis at bruge?

Payload er helt gratis under MIT-licensen. Softwaren koster ingenting at downloade, bruge eller modificere. Payload Cloud (managed hosting) kostede $35-199/md., men er i øjeblikket pauset for nye tilmeldinger efter Figma-opkøbet. Self-hosting på en VPS koster EUR 7-45/md. afhængigt af din udbyder.

Hvad skete der med Payload og Figma?

Figma opkøbte Payload den 17. juni 2025. Hele Payload-teamet joinede Figma. Den open source MIT-licens og GitHub-repositoriet forbliver uændrede. Payload Cloud har pauset nye tilmeldinger. Self-hosting fortsætter med at fungere normalt. Teamet bygger sandsynligvis på et Figma-integreret CMS-produkt, men specifikker er endnu ikke annonceret.

Hvilken database bruger Payload CMS?

Payload understøtter tre databaser gennem et adapter-mønster: PostgreSQL (anbefales til produktion, fungerer med Neon og Supabase til serverless), MongoDB (godt til dokument-tunge modeller eller Payload 2-opgraderinger) og SQLite (kun lokal udvikling og CI). Din applikationskode forbliver den samme uanset hvilken adapter du vælger.

Hvordan deployer jeg Payload CMS i 2026?

Med Payload Cloud pauset skal du deploye til Vercel med Neon Postgres (nemmest), Docker på en VPS som Hetzner (bedst til produktion med aktive redaktører), Railway eller Render (managed containers) eller Cloudflare Workers (billigst). For de fleste produktionssites med regelmæssig redaktionel aktivitet giver en Docker-baseret VPS den bedste oplevelse.

Er Payload CMS bedre end Strapi?

Payload vinder på TypeScript-native developer experience, Next.js-integration og den unikke Local API til zero-overhead server-side queries. Strapi vinder på sit plugin-markedsplads, GUI-baseret schema-redigering og bredere framework-kompatibilitet. Hvis dit team skriver TypeScript og bruger Next.js, er Payload det stærkere valg. Ellers bør du evaluere Strapi.

Hvad er Payloads Local API?

Local API er et server-side query-lag, der kalder din database direkte uden HTTP-overhead. I stedet for at lave REST- eller GraphQL-kald importerer du Payload og forespørger collections direkte i Next.js server-komponenter. Dette eliminerer netværks-round-trips og serialiseringsomkostninger, hvilket resulterer i hurtigere sideindlæsninger. Intet andet headless CMS tilbyder dette.

Kan Payload CMS håndtere store applikationer?

Payload understøtter PostgreSQL med connection pooling (via Neon eller PgBouncer), rollebaseret adgangskontrol med felt-niveau granularitet, kladde- og versioneringsworkflows og multi-tenant arkitekturer. Virksomheder og bureauer bruger Payload i produktion til indholdstunge applikationer. Local APIs zero-overhead queries forbedrer faktisk ydeevnen i stor skala.

Hvordan sammenligner Payload sig med Sanity?

Payload er self-hosted, code-first og MIT-licenseret med en Local API til server-side ydeevne. Sanity er cloud-hosted med overlegen visuel redigering, realtidssamarbejde og GROQ query-sprog. Payload giver dig mere infrastrukturkontrol og lavere omkostninger. Sanity giver dig bedre redaktionelle værktøjer og nul hostingstyring.

Hvad er ulemperne ved Payload CMS?

Payload kræver TypeScript-viden til konfiguration, har ingen managed cloud-hosting til nye brugere siden Figma-opkøbet, tilbyder et mindre plugin-økosystem end Strapi og er arkitektonisk bundet til Next.js i version 3. Ikke-tekniske teams kan kæmpe med code-first-tilgangen, og Figma-opkøbet skaber en vis langsigtet usikkerhed.