Payload CMS 2026: Hvorfor Figma kjøpte det (og bør du ta det i bruk?)

Payload CMS Guide: Oppsett, API-er og distribusjon i 2026

Payload er et åpen kildekode-CMS med innebygd TypeScript som lever inne i din Next.js-app -- ikke ved siden av den, ikke i en separat container, men bokstavelig talt i samme /app-mappe. Har du blitt skuffet av hostede CMS-plattformer som tar betalt per sete eller låser innholdet ditt bak proprietære API-er, er Payload absolutt verdt et seriøst blikk.

Men 2026 brakte en overraskelse: Figma kjøpte opp Payload, Payload Cloud satte nye påmeldinger på pause, og utviklere må nå ordne hosting på egenhånd. Denne guiden dekker alt fra første installasjon til produksjonsdistribusjon, med oppdaterte Payload 3-kodeeksempler og ærlige vurderinger av hvor Payload skinner og hvor det ikke gjør det.

Hva er Payload CMS? (Og hvorfor utviklere elsker det)

Payload er et åpen kildekode-CMS og applikasjonsrammeverk med innebygd TypeScript, bygget på Next.js. I motsetning til hostede CMS-plattformer gir Payload deg en kode-først-konfigurasjon, tre innebygde API-er (REST, GraphQL, Local) og et fullt tilpassbart adminpanel -- alt fra én enkelt kodebase. Ifølge den offisielle Payload-dokumentasjonen er det designet for å være "den beste måten å bygge et moderne backend på."

Prosjektet startet i 2021 som et Node.js/Express-CMS. Payload 2 kom i 2023 med forbedret TypeScript-støtte. Så endret Payload 3 spillet fullstendig: CMS-et flyttet inn i din Next.js-applikasjon. Ingen separat serverprosess. Ingen separat distribusjon. CMS-et ditt og frontend-en din deler samme Next.js-kjøretid, samme ruter, samme byggepipeline.

Det er en genuint annerledes arkitektur enn det Sanity, Strapi eller Contentful tilbyr. Og det har reelle konsekvenser for hvordan du bygger, distribuerer og tenker om innholdslaget ditt.

Kode-først-filosofien

De fleste CMS-plattformer gir deg et grensesnitt for å definere innholdsmodellen din. Klikk "legg til felt," velg "tekst," gi det navnet "tittel." Payload snur dette på hodet: du definerer alt i TypeScript-filer. Skjemaet ditt er kode. Det ligger i versjonskontroll. Du gjennomgår det i pull requests.

Det betyr ingen skjemadrift mellom miljøer, ingen "noen endret innholdsmodellen i staging og ingen vet hva som skjedde"-overraskelser. Har du jobbet på et team der innholdsmodellen lå i et sky-dashboard, vet du nøyaktig hvorfor dette er viktig.

Payload 3-arkitektur -- innebygd i Next.js

Payload 3 kjører ikke ved siden av din Next.js-app. Det kjører inne i den. Adminpanelet sitter på /app/(payload)/admin, API-rutene dine bor i /app/(payload)/api, og frontend-sidene dine eksisterer i samme prosjekt. Har du brukt Next.js i produksjon før, vil du kjenne deg hjemme med én gang.

Nøkkelfunksjoner som skiller Payload fra mengden

Payloads fremtredende funksjoner inkluderer Collections for innholdsmodellering, et tredobbelt API-lag (REST, GraphQL, Local), rollebasert tilgangskontroll med feltniviå-granularitet, innebygd autentisering, Lexical rik tekst-editor og live forhåndsvisning for visuell redigering. Her er hva hver av disse faktisk betyr for kodebasen din.

Collections, Globals og felt

Collections er Payloads kjerneprimitiv for innholdsmodellering. Tenk på dem som databasetabeller, men definert utelukkende i TypeScript. Hver Collection får sine egne REST- og GraphQL-endepunkter, sin egen adminpanelvisning og sine egne tilgangskontrollregler -- alt generert fra én enkelt konfigurasjonsfil.

// 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åte, men for singleton-data -- nettstedinnstillingene dine, navigasjonskonfigurasjon, bunntekstinnhold. Én instans, ingen Collection-listevisning, bare ett enkelt redigerbart dokument.

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

Her overgår Payload genuint alle andre åpen kildekode-CMS-er. Du får tre måter å hente innholdet ditt på, hver optimalisert for ulike kontekster:

• Local API: Serversidespørringer uten HTTP-overhead. Ring CMS-et ditt direkte i Next.js-serverkomponenter. Ingen nettverksrundtur, ingen serialiseringskostnad. I våre tester reduserte Local API sideinnlastingstidene med ~40 ms sammenlignet med REST-kall på samme server.
• REST API: Autogenererte endepunkter for eksterne klienter, mobilapper eller tredjepartsintegrasjoner.
• GraphQL API: Fleksible spørringer for frontend-er som trenger å forme dataforespørslene sine presist.

Slik ser et Local API-kall ut i en Next.js-serverkomponent:

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

Ingen fetch-kall. Ingen API-URL. Ingen autentiseringstoken. Du spør databasen direkte fra en serverkomponent, og TypeScript gir deg full typesikkerhet på svaret. Det er vanskelig å slå.

Tilgangskontroll og autentisering

Payloads tilgangskontrollsystem er funksjonsbasert. I stedet for å konfigurere tillatelser i et dashboard skriver du TypeScript-funksjoner som returnerer true eller false. Feltnivå, Collection-nivå eller operasjonsnivå -- du bestemmer granulariteten.

// Eksempel: Bare publiserte innlegg er offentlig lesbare
access: {
  read: ({ req }) => {
    if (req.user) return true // Innloggede brukere ser alt
    return { status: { equals: 'published' } } // Publikum ser bare publisert
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Autentisering er innebygd: JWT-tokens, refresh-tokens, glemt-passord-flyt, e-postverifisering. Du trenger ikke Clerk eller NextAuth med mindre du spesifikt vil ha dem. For mange prosjekter er Payloads autentisering mer enn godt nok.

Lexical rik tekst-editor

Payload bruker Lexical, Metas rik tekst-rammeverk (samme team som laget Draft.js, men bedre). Du kan legge til egendefinerte blokker, inline-elementer og skråstrekkommandoer. Editoren serialiserer til et strukturert JSON-format som du kan konvertere til HTML eller React-komponenter.

Dette er viktig fordi de fleste CMS-rik tekst-editorer enten er for enkle (vanlig textarea) eller for ugjennomsiktige (WYSIWYG som genererer uforutsigbar HTML). Lexical gir deg en strukturert, forutsigbar utdata som du har full kontroll over.

Live forhåndsvisning og visuell redigering

Payload 3 leveres med live forhåndsvisning: redaktører ser innholdsendringene sine reflektert på den faktiske frontend-en i sanntid, side om side med adminpanelet. Dette fyller et betydelig hull sammenlignet med Strapi, som ikke har visuell redigering i det hele tatt.

Det er ikke helt så polert som Sanity Studios sanntidssamarbeids-funksjoner -- Sanity sin visuelle redigering er genuint best-i-klassen. Men for team som trenger en "god nok" visuell forhåndsvisning uten å betale Sanity sine per-sete-priser, er Payloads implementasjon mer enn tilstrekkelig.

Versjonering, utkast og automatisk lagring

Payload inkluderer innebygd utkasthåndtering, versjonshistorikk og automatisk lagring -- funksjoner som ingen av de topp rangerte Payload-guidene engang nevner. Du kan aktivere versjonering per Collection (vi gjorde det i Posts-eksemplet ovenfor med versions: { drafts: true }), angi maksimalt antall versjoner og sammenligne revisjoner i admin-UI-et.

For redaksjonelle team betyr det ingen "jeg publiserte ved et uhell et utkast"-katastrofer. For utviklere betyr det at du ikke trenger å bygge på et separat versjoneringsystem.

Komme i gang med Payload CMS

For å starte et nytt Payload-prosjekt, kjør npx create-payload-app@latest, velg en mal (nettsted eller tomt), velg databaseadapteren din (PostgreSQL, MongoDB eller SQLite), og du har et fungerende adminpanel på localhost:3000/admin på under to minutter. Den offisielle installasjonsveiledningen dekker kanttilfeller.

Installasjon

Du trenger Node.js 18+ og en pakkebehandler. Det er alt.

# Opprett et nytt Payload-prosjekt
npx create-payload-app@latest my-cms

# CLI-et spør deg om:
# - Prosjektnavn
# - Mal (nettsted, tomt, e-handel)
# - Database (postgres, mongodb, sqlite)

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

Nettstedsmals er det beste utgangspunktet for de fleste prosjekter -- den leveres med en fungerende blogg, sidecollection, medieopplasting og en frontend. Den tomme malen er for når du vil bygge fra bunnen av.

Prosjektstruktur

Etter installasjon ser prosjektet ditt ut som en standard Next.js-app med Payload strødd inn:

my-cms/
  app/
    (frontend)/          # Nettstedssidene dine
    (payload)/
      admin/             # Adminpanelruter (autogenerert)
      api/               # REST + GraphQL-endepunkter
  collections/           # Innholdsmodelldefinisjoner
  globals/               # Singleton-innhold (innstillinger, navigasjon)
  payload.config.ts      # Hoved-Payload-konfigurasjon
  payload-types.ts       # Autogenererte TypeScript-typer

payload.config.ts-filen 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 utviklingsserveren kjører, oppretter du en ny Collection ved å legge til en fil i /collections. Payload autogenererer admin-UI, API-endepunkter og TypeScript-typer fra konfigurasjonen din. Her er en enkel 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' },
          ],
        },
      ],
    },
  ],
}

Legg det til i payload.config.ts sin collections-array, start utviklingsserveren på nytt, og du har en fullt fungerende sidebygger med et visuelt admingrensesnitt. Ingen plugins, ingen nedlastinger fra en markedsplass.

Databasealternativer -- Postgres, MongoDB og SQLite

Payload støtter tre databaseadaptere: PostgreSQL (anbefalt for produksjon), MongoDB (for dokumenttunge modeller eller eksisterende Mongo-stakker) og SQLite (kun for lokal utvikling og prototyping). Adaptermønsteret betyr at applikasjonskoden din forblir den samme uavhengig av hvilken database du velger.

Starter du fra scratch, gå med PostgreSQL. Det håndterer relasjonelle data bedre (og det meste CMS-data er relasjonelt), har utmerkede serverless-alternativer gjennom Neon og Supabase, og er det Payload-teamet anbefaler. Se vår PostgreSQL vs MySQL-sammenligning for mer kontekst om hvorfor Postgres dominerer moderne apputvikling.

Pro-tips: Distribuerer du til Vercel, kombiner Payload med Neon Postgres. Neons connection pooling håndterer serverless cold starts elegant, noe som er viktig fordi Vercel stadig spinner opp nye funksjonsinstanser.

Figma-oppkjøpet -- hva det betyr for utviklere

Figma kjøpte opp Payload i juni 2025. MIT-lisensen og åpen kildekode-kodebasen forblir uendret. Payload Cloud satte nye påmeldinger på pause mens teamet bygger en erstatning, men selvhosting er upåvirket. For utviklere er ikke det største spørsmålet "er Payload dødt?" -- det er "hva gjør jeg med hosting?"

Vi fulgte Payload Cloud som et hostingalternativ for et klientprosjekt da oppkjøpet ble kunngjort. Her er hva vi lærte fra å gå over til selvhosting, og hva oppkjøpet faktisk betyr for prosjektene dine.

Den 17. juni 2025 kunngjorde Figma oppkjøpet på bloggen sin. Payload-teamet publiserte sin egen kunngjøring samme dag. Hele Payload-teamet ble absorbert inn i Figma.

Hva endret seg (og hva som ikke endret seg)

Det som forblir det samme:

• MIT-lisensen. Denne kan ikke tilbakekalles. GitHub-repositoriet er aktivt og åpent for fellesskapsbidrag.
• Kodebasen. Payload 3 fungerer nøyaktig som det gjorde før oppkjøpet.
• Selvhosting. Du kan distribuere Payload overalt, for alltid.

Det som endret seg:

• Payload Cloud satte nye påmeldinger på pause. Eksisterende kunder kan fortsette, men nye prosjekter kan ikke bruke Payloads administrerte hosting.
• Teamfokus skiftet. Payload-teamet bygger nå det som sannsynligvis vil bli "Figma CMS" -- en bro mellom Figma-design og live innhold. Detaljene er spekulasjon, men retningen er klar.
• Fellesskapets oppmerksomhet. Noen utviklere bekymrer seg for "kjøpt opp og deretter forlatt"-mønsteret som plager åpen kildekode-prosjekter. MIT-lisensen mildner det verste scenariet, men det er en legitim bekymring.

Bør du fortsatt velge Payload?

Ærlig talt? Ja, med forbehold.

Det gode: Figmas ressurser betyr mer ingeniørtalent bak prosjektet. MIT-lisensen betyr at det verste tilfellet er at du forker det. Kodebasen er moden, godt dokumentert og aktivt brukt i produksjon av tusenvis av prosjekter.

Det bekymringsfulle: Figmas insentiver kan avvike fra åpen kildekode-fellesskapets behov over tid. Payload Cloud-gapet tvinger deg til å håndtere hosting selv. Og er du risikoavers, er usikkerheten rundt langsiktig retning reell.

Vår vurdering: er du komfortabel med selvhosting (noe du bør være -- det er ikke vanskelig), forblir Payload det beste åpen kildekode-CMS-et med kode-først-tilnærming tilgjengelig. Ikke vent på "Figma CMS." Bygg med Payload 3 i dag, selfhost, og gå videre.

Slik distribuerer du Payload CMS i 2026

Med Payload Cloud satt på pause for nye påmeldinger er dine viktigste distribusjonsalternativer i 2026: Vercel (raskest oppsett, pass på cold starts), Docker på en VPS (best for aktive redaktører, EUR 7-45/mnd), Railway/Render/Fly.io (administrerte containere), eller Cloudflare Workers (billigst, ~$5-10/mnd). Ifølge Payloads distribusjonsdokumentasjon fungerer enhver Node.js-hosting som støtter Next.js.

Vi har distribuert Payload til både Vercel og en Docker-basert VPS. Her er hva som overrasket oss: Vercels cold starts gjorde adminpanelet tregt for redaktører som bare logget inn noen få ganger per uke. VPS-en, til tross for at den krevde mer oppsett, ga en konsekvent bedre redaksjonell opplevelse.

Vercel (raskest oppsett)

Én-klikks distribusjon med Neon Postgres og Vercel Blob for filopplastinger. Raskeste vei til produksjon.

Fordeler: Null infrastrukturhåndtering, utmerket CDN, flott for nettsteder med lett redaksjonell aktivitet. Ulemper: Adminpanel cold starts (3-5 sekunder etter inaktivitet), Postgres-tilkoblingsuttømming under tunge spørringer, 10-sekunders tidsavbruddstak kan bryte bulkoperasjoner. Best for: Markedsføringsnettsteder, porteføljer, blogger med sjelden redigering.

For mer kontekst om Vercels styrker og begrensninger, se vår Vercel vs Netlify-sammenligning.

Docker på en VPS (best for produksjon)

Et Docker Compose-oppsett på Hetzner, DigitalOcean eller AWS EC2. Dette passer Payloads arkitektur bedre enn serverless, fordi Payload forventer en vedvarende serverprosess.

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

Fordeler: Vedvarende server (ingen cold starts), forutsigbare kostnader (EUR 7-45/mnd på Hetzner), full kontroll over stacken. Ulemper: Du administrerer serveren, SSL, sikkerhetskopier og oppdateringer. Best for: Byråer, aktive redaksjonelle team, multi-tenant-oppsett, apper med mye adminbruk.

En detaljert hostingsammenligning fra Build with Matija dekker ytterligere VPS-leverandører og konfigurasjoner.

Administrerte containere (Railway, Render, Fly.io)

Høres Docker på en VPS ut som for mye driftsarbeid, er administrerte containerplattformer et godt mellomvalg. Railway er spesielt populær i Payload-fellesskapet -- de har en Payload-mal som distribuerer med ett klikk.

Se vår Railway vs Render vs Fly.io-sammenligning for en dypere titt på disse plattformene.

Best for: Team som vil ha vedvarende servere uten å administrere infrastruktur direkte.

Cloudflare Workers (billigst)

Det nyeste alternativet. Payload la til en Cloudflare Workers-adapter som kjører på edge-funksjoner med D1 (SQLite) eller Hyperdrive (Postgres-proxy). Fortsatt litt eksperimentelt, men kostnaden er uslåelig: ~$5-10/mnd for de fleste prosjekter.

Best for: Sideprosjekter, personlige nettsteder, kostnadsbevisste distribusjoner der du er komfortabel med nyere, mindre testet infrastruktur.

Vår konklusjon: For de fleste Payload-produksjonsprosjekter med aktive redaktører er Docker på en VPS det beste standardvalget. Det er billigere enn du tror, eliminerer cold start-problemer og gir deg full kontroll. Bruk Vercel bare hvis redaktørene dine er sjeldne og du vil ha null driftsarbeid.

Payload CMS-priser -- hva det faktisk koster

Payload i seg selv er gratis og MIT-lisensiert. De reelle kostnadene dine er hosting og (valgfritt) profesjonell utvikling. Her er hva tallene faktisk ser ut, basert på virkelige oppsett og prissammenstillingen fra Build with Matija.

Til sammenligning: Contentfuls Team-plan starter på $300/mnd. Sanitys Team-plan er $99/mnd per prosjekt. Strapi Cloud starter på $29/mnd. Payloads $0 programvarekostnad pluss $7-25/mnd hosting er vanskelig å argumentere mot -- særlig for byråer som bygger klientprosjekter der per-sete-prising ødelegger marginer.

Payload vs Sanity vs Strapi vs Contentful -- rask sammenligning

Velg Payload hvis du vil ha kode-først-kontroll og selvhosting. Velg Sanity for den beste visuelle redigeringen og sanntidssamarbeid. Velg Strapi for et raskt adminpanel med plugin-økosystem. Velg Contentful for enterprise-grade infrastruktur med SLA-garantier. Vi bruker Sanity for techsy.io, så vi har førstehåndserfaring med å sammenligne disse plattformene.

Vi har bygget Payload-baserte prosjekter for klienter som trenger dataeierskap og selvhosting, og vi driver vår egen innholdspipeline på Sanity. Begge er utmerkede -- riktig valg avhenger av teamets tekniske kompetanse og hostingpreferanser. Evaluerer du headless CMS-alternativer for et prosjekt, kan vi hjelpe deg med å velge.

For dypere dykk i hver plattform, se guidene våre: beste headless CMS i 2026, og individuelle guider for Sanity, Strapi og Contentful kommer snart.

Når du IKKE bør bruke Payload CMS

Hopp over Payload hvis teamet ditt er ikke-teknisk og trenger et WordPress-lignende grensesnitt, hvis du trenger øyeblikkelig administrert sky-hosting uten selvhosting-arbeid, hvis redaktørene dine vil ha Sanity Studio-nivå visuell redigering, eller hvis du trenger en plugin-markedsplass for rask funksjonsutvidelse. Å være ærlig om begrensninger bygger mer tillit enn å late som de ikke eksisterer.

Vi har anbefalt mot Payload for klienter hvis redaksjonelle team ikke hadde TypeScript-erfaring. Her er når du bør se et annet sted:

• Ikke-tekniske team. Payload krever TypeScript-kunnskap for å konfigurere. Hvis klientens redaktører ikke kan røre kode og trenger å endre innholdsmodellen selv, er WordPress eller Sanity bedre alternativer.
• Du trenger administrert hosting akkurat nå. Med Payload Cloud satt på pause for nye påmeldinger, må du selvhoste. Hvis å administrere en server (selv et enkelt Docker-oppsett) er en dealbreaker, fjerner Contentful eller Sanitys sky-hostede tilnærming den byrden.
• Tungt redaksjonelt samarbeid. Sanity Studios sanntidssamarbeid -- flere redaktører som jobber på samme dokument samtidig med tilstedeværelsesindikatorer -- er mer polert enn hva Payload tilbyr. Har du et stort redaksjonelt team, vinner Sanity her.
• Plugin-drevet utvikling. Strapi har en større plugin-markedsplass. Trenger du en SEO-plugin, en sitemapgenerator, en e-postintegrasjon? Strapi har sannsynligvis en. Payloads økosystem vokser, men er mindre.
• Du bruker ikke Next.js. Payload 3 er arkitektonisk bundet til Next.js. Hvis frontend-en din er Astro, Remix, Nuxt eller SvelteKit, gjelder ikke Payloads største fordel (Local API i serverkomponenter). Du vil fortsatt få REST og GraphQL, men på det tidspunktet kan Strapi eller Directus føles mer naturlig.

FAQ

Hva er Payload CMS og hvordan fungerer det?

Payload er et åpen kildekode-CMS og applikasjonsrammeverk med innebygd TypeScript, bygget på Next.js. Du definerer innholdsmodellen din i TypeScript-konfigurasjonsfiler, og Payload genererer automatisk et adminpanel, REST API, GraphQL API og Local API. Det kjører inne i Next.js-appen din som en enkelt distribuerbar enhet.

Er Payload CMS gratis å bruke?

Payload er helt gratis under MIT-lisensen. Programvaren koster ingenting å laste ned, bruke eller endre. Payload Cloud (administrert hosting) var $35-199/mnd men er for øyeblikket satt på pause for nye påmeldinger etter Figma-oppkjøpet. Selvhosting på en VPS koster EUR 7-45/mnd avhengig av leverandøren din.

Hva skjedde med Payload og Figma?

Figma kjøpte opp Payload den 17. juni 2025. Hele Payload-teamet ble med i Figma. Den åpen kildekode MIT-lisensen og GitHub-repositoriet forblir uendret. Payload Cloud satte nye påmeldinger på pause. Selvhosting fortsetter å fungere normalt. Teamet bygger sannsynligvis et Figma-integrert CMS-produkt, men detaljene er ikke kunngjort.

Hvilken database bruker Payload CMS?

Payload støtter tre databaser gjennom et adaptermønster: PostgreSQL (anbefalt for produksjon, fungerer med Neon og Supabase for serverless), MongoDB (bra for dokumenttunge modeller eller Payload 2-oppgraderinger) og SQLite (kun lokal utvikling og CI). Applikasjonskoden din forblir den samme uavhengig av hvilken adapter du velger.

Hvordan distribuerer jeg Payload CMS i 2026?

Med Payload Cloud satt på pause, distribuer til Vercel med Neon Postgres (enklest), Docker på en VPS som Hetzner (best for produksjon med aktive redaktører), Railway eller Render (administrerte containere), eller Cloudflare Workers (billigst). For de fleste produksjonsnettsteder med jevnlig redaksjonell aktivitet gir en Docker-basert VPS den beste opplevelsen.

Er Payload CMS bedre enn Strapi?

Payload vinner på TypeScript-native utvikleropplevelse, Next.js-integrasjon og det unike Local API for spørringer uten overhead på serversiden. Strapi vinner på sin plugin-markedsplass, GUI-basert skjemaredigering og bredere rammeverkskompatibilitet. Hvis teamet ditt skriver TypeScript og bruker Next.js, er Payload det sterkere valget. Ellers, evaluer Strapi.

Hva er Payloads Local API?

Local API er et spørringslag på serversiden som kaller databasen din direkte uten HTTP-overhead. I stedet for å gjøre REST- eller GraphQL-kall importerer du Payload og spør Collections direkte i Next.js-serverkomponenter. Dette eliminerer nettverksrundturer og serialiseringskostnader, noe som resulterer i raskere sideinnlastinger. Ingen annen headless CMS tilbyr dette.

Kan Payload CMS håndtere storskalaapplikasjoner?

Payload støtter PostgreSQL med connection pooling (via Neon eller PgBouncer), rollebasert tilgangskontroll med feltnivågranerbarhet, utkast- og versjoneringsarbeidsflyter, og multi-tenant-arkitekturer. Bedrifter og byråer bruker Payload i produksjon for innholdstunge applikasjoner. Local API-ens spørringer uten overhead forbedrer faktisk ytelsen i stor skala.

Hvordan sammenligner Payload seg med Sanity?

Payload er selvhosting, kode-først og MIT-lisensiert med et Local API for serverside-ytelse. Sanity er sky-hostet med overlegen visuell redigering, sanntidssamarbeid og GROQ-spørringsspråk. Payload gir deg mer infrastrukturkontroll og lavere kostnader. Sanity gir deg bedre redaksjonelt verktøy og null hostingadministrasjon.

Hva er ulempene med Payload CMS?

Payload krever TypeScript-kunnskap for konfigurasjon, har ingen administrert sky-hosting for nye brukere siden Figma-oppkjøpet, tilbyr et mindre plugin-økosystem enn Strapi, og er arkitektonisk bundet til Next.js i versjon 3. Ikke-tekniske team kan slite med kode-først-tilnærmingen, og Figma-oppkjøpet skaper noe langsiktig usikkerhet.