Payload CMS 2026: Varför Figma Köpte Det (Och Bör Du Använda Det?)

Payload är ett öppen källkod, TypeScript-nativt headless CMS som lever inuti din Next.js-app -- inte bredvid den, inte i en separat container, utan bokstavligen i samma /app-mapp. Om du blivit bränd av hostade CMS-plattformar som tar betalt per användare eller låser ditt innehåll bakom proprietära API:er är Payload värt ett seriöst övervägande.

Men 2026 kom med en överraskning: Figma förvärvade Payload, Payload Cloud pausade nya registreringar och utvecklare måste plötsligt lösa hosting på egen hand. Den här guiden täcker allt från första installation till produktionsdriftsättning, med aktuella Payload 3-kodexempel och ärliga bedömningar av var Payload lyser och var det inte gör det.

Vad är Payload CMS? (Och varför älskar utvecklare det?)

Payload är ett öppen källkod, TypeScript-nativt headless CMS och applikationsramverk som körs inuti din Next.js-app. Till skillnad från hostade CMS-plattformar ger Payload dig en kod-first-konfiguration, tre inbyggda API:er (REST, GraphQL, Local) och en fullt anpassningsbar adminpanel -- allt från en enda kodbas. Enligt den officiella Payload-dokumentationen är det designat för att vara "det bästa sättet att bygga en modern backend."

Projektet startade 2021 som ett Node.js/Express CMS. Payload 2 kom 2023 med förbättrat TypeScript-stöd. Sedan förändrade Payload 3 spelet helt: CMS:et flyttade in i din Next.js-applikation. Ingen separat serverprocess. Ingen separat driftsättning. Ditt CMS och din frontend delar samma Next.js-runtime, samma routes, samma byggpipeline.

Det är en genuint annorlunda arkitektur jämfört med vad Sanity, Strapi eller Contentful erbjuder. Och det har verkliga konsekvenser för hur du bygger, driftsätter och tänker kring ditt innehållslager.

Kod-first-filosofin

De flesta CMS-plattformar ger dig ett GUI för att definiera din innehållsmodell. Klicka på "lägg till fält," välj "text," ge det namnet "title." Payload vänder på detta: du definierar allt i TypeScript-filer. Ditt schema är kod. Det lever i versionshantering. Du granskar det i pull requests.

Det innebär ingen schemadrift mellan miljöer, inga "någon ändrade innehållsmodellen i staging och ingen vet vad som hände"-överraskningar. Om du jobbat i ett team där innehållsmodellen levde i ett molndashboard vet du exakt varför det spelar roll.

Payload 3-arkitektur -- Next.js-nativt

Payload 3 körs inte bredvid din Next.js-app. Det körs inuti den. Adminpanelen sitter på /app/(payload)/admin, dina API-routes lever i /app/(payload)/api och dina frontendsidor samexisterar i samma projekt. Om du använt Next.js i produktion tidigare känner du dig direkt hemma.

Nyckelfunktioner som skiljer Payload från mängden

Payloads framstående funktioner inkluderar Collections för innehållsmodellering, ett tredubbelt API-lager (REST, GraphQL, Local), rollbaserad åtkomstkontroll med fältnivågranularitet, inbyggd autentisering, Lexical rich text-editorn och förhandsvisning i realtid för visuell redigering. Här är vad var och en av dessa faktiskt innebär för din kodbas.

Collections, Globals och fält

Collections är Payloads kärnprimitiv för innehållsmodellering. Tänk på dem som databastabeller, men definierade helt i TypeScript. Varje Collection får sina egna REST- och GraphQL-endpoints, sin egen adminpanelvy och sina egna åtkomstkontrollregler -- allt genererat från en enda 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 fungerar på liknande sätt men för singleton-data -- dina webbplatsinställningar, navigationskonfiguration, sidfotensinnehåll. En instans, ingen collection-listvy, bara ett enda redigerbart dokument.

Det tredubbla API-lagret (REST, GraphQL, Local)

Det är här Payload verkligen överglänser varje annat öppen källkod CMS. Du får tre sätt att fråga ditt innehåll, vart och ett optimerat för olika sammanhang:

• Local API: Server-side-frågor med noll HTTP-overhead. Anropa ditt CMS direkt i Next.js server components. Ingen nätverkstur, ingen serialiseringskostnad. I våra tester minskade Local API:et sidladdningstiderna med ~40 ms jämfört med REST-anrop på samma server.
• REST API: Automatiskt genererade endpoints för externa klienter, mobilappar eller tredjepartsintegrationer.
• GraphQL API: Flexibla frågor för frontends som behöver forma sina datafrågor exakt.

Så här ser ett Local API-anrop ut i en 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>
}

Inget fetch-anrop. Ingen API-URL. Ingen autentiseringstoken. Du frågar din databas direkt från en server component, och TypeScript ger dig full typsäkerhet på svaret. Det är svårt att slå.

Åtkomstkontroll och autentisering

Payloads åtkomstkontrollsystem är funktionsbaserat. Istället för att konfigurera behörigheter i ett dashboard skriver du TypeScript-funktioner som returnerar true eller false. På fältnivå, collectionsnivå eller operationsnivå -- du bestämmer granulariteten.

// Exempel: Endast publicerade inlägg är offentligt läsbara
access: {
  read: ({ req }) => {
    if (req.user) return true // Inloggade användare ser allt
    return { status: { equals: 'published' } } // Allmänheten ser bara publicerade
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

Autentisering ingår inbyggt: JWT-tokens, refresh tokens, glömt-lösenord-flöde, e-postverifiering. Du behöver inte Clerk eller NextAuth om du inte specifikt vill ha dem. För många projekt räcker Payloads autentisering mer än väl.

Lexical rich text-editor

Payload använder Lexical, Metas rich text-ramverk (samma team bakom Draft.js, men bättre). Du kan lägga till anpassade block, inline-element och snedstreckskommandon. Editorn serialiserar till ett strukturerat JSON-format som du kan konvertera till HTML eller React-komponenter.

Det spelar roll eftersom de flesta CMS rich text-editorer antingen är för enkla (ren textarea) eller för ogenomskinliga (WYSIWYG som genererar oförutsägbar HTML). Lexical ger dig en strukturerad, förutsägbar output som du kontrollerar helt.

Förhandsvisning i realtid och visuell redigering

Payload 3 levereras med förhandsvisning i realtid: redaktörer ser sina innehållsändringar återspeglade på den faktiska frontendsidan i realtid, sida vid sida med adminpanelen. Det är ett betydande gap-filler jämfört med Strapi, som inte har någon visuell redigering alls.

Det är inte riktigt lika polerat som Sanity Studios realtidssamarbetsfunktioner -- Sanity Studio är genuint bäst i klassen för visuell redigering. Men för team som behöver "bra nog" visuell förhandsvisning utan att betala Sanity per-seat-priser gör Payloads implementation jobbet.

Versionshantering, utkast och autosparning

Payload inkluderar inbyggd utkastshantering, versionshistorik och autosparning -- funktioner som noll av de topprankade Payload-guiderna ens nämner. Du kan aktivera versionshantering per collection (vi gjorde det i Posts-exemplet ovan med versions: { drafts: true }), ange ett maximalt versionsantal och jämföra revisioner i adminpanelens gränssnitt.

För redaktionella team innebär det inga fler "jag publicerade råkade ett utkast"-katastrofer. För utvecklare innebär det att du inte behöver bolt-on ett separat versionshanteringssystem.

Komma igång med Payload CMS

För att starta ett nytt Payload-projekt kör du npx create-payload-app@latest, väljer en mall (webbplats eller blank), väljer din databasadapter (PostgreSQL, MongoDB eller SQLite) och du har en fungerande adminpanel på localhost:3000/admin på under två minuter. Den officiella installationsguiden täcker kantfall.

Installation

Du behöver Node.js 18+ och en pakethanterare. Det är allt.

# Skapa ett nytt Payload-projekt
npx create-payload-app@latest my-cms

# CLI:t frågar dig:
# - Projektnamn
# - Mall (website, blank, e-commerce)
# - Databas (postgres, mongodb, sqlite)

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

Website-mallen är den bästa startpunkten för de flesta projekt -- den levereras med en fungerande blogg, pages-collection, medieuppladdningar och en frontend. Blank-mallen är till när du vill bygga från grunden.

Projektstruktur

Efter installationen ser ditt projekt ut som en standard Next.js-app med Payload insprinklat:

my-cms/
  app/
    (frontend)/          # Dina webbplatssidor
    (payload)/
      admin/             # Adminpanelroutes (autogenererade)
      api/               # REST + GraphQL endpoints
  collections/           # Dina innehållsmodelldefinitioner
  globals/               # Singleton-innehåll (inställningar, nav)
  payload.config.ts      # Huvudsaklig Payload-konfiguration
  payload-types.ts       # Autogenererade TypeScript-typer

Filen payload.config.ts är hjärtat i allt:

// 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örsta Collection

När dev-servern körs skapar du en ny collection genom att lägga till en fil i /collections. Payload autogenererar adminpanelgränssnittet, API-endpoints och TypeScript-typer från din konfiguration. Här är 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' },
          ],
        },
      ],
    },
  ],
}

Lägg till den i payload.config.ts collections-arrayen, starta om dev-servern och du har en fullt fungerande sidbyggare med ett visuellt adminpanelgränssnitt. Inga plugins, inga marketplace-nedladdningar.

Databasalternativ -- Postgres, MongoDB och SQLite

Payload stöder tre databasadaptrar: PostgreSQL (rekommenderat för produktion), MongoDB (för dokumenttunga modeller eller befintliga Mongo-stackar) och SQLite (enbart för lokal utveckling och prototypning). Adaptermönstret innebär att din applikationskod förblir densamma oavsett vilken databas du väljer.

Börjar du från grunden, välj PostgreSQL. Det hanterar relationella data bättre (och de flesta CMS-data är relationella), har utmärkta serverlösa alternativ via Neon och Supabase och är vad Payload-teamet rekommenderar. Kolla vår PostgreSQL vs MySQL-jämförelse för mer sammanhang om varför Postgres dominerar modern apputveckling.

Pro-tips: Driftsätter du till Vercel, para ihop Payload med Neon Postgres. Neons connection pooling hanterar serverlösa kalla starter på ett smidigt sätt, vilket spelar roll eftersom Vercel ständigt snurrar upp nya funktionsinstanser.

Figma-förvärvet -- Vad det innebär för utvecklare

Figma förvärvade Payload i juni 2025. MIT-licensen och den öppna källkodsbasen förblir oförändrade. Payload Cloud pausade nya registreringar medan teamet bygger en ersättare, men egenhostning påverkas inte. För utvecklare är den största frågan inte "är Payload dött?" -- det är "vad gör jag åt hosting?"

Vi följde Payload Cloud som ett hostingalternativ för ett kundprojekt när förvärvet tillkännagavs. Här är vad vi lärde oss av att ställa om till egenhostning, och vad förvärvet faktiskt innebär för dina projekt.

Den 17 juni 2025 tillkännagav Figma förvärvet på sin blogg. Payload-teamet publicerade sitt eget tillkännagivande samma dag. Hela Payload-teamet absorberades in i Figma.

Vad som förändrades (och vad som inte gjorde det)

Vad som är oförändrat:

• MIT-licensen. Den kan inte återkallas. GitHub-repositoriet förblir aktivt och öppet för communitybidrag.
• Kodbasen. Payload 3 fungerar exakt som det gjorde före förvärvet.
• Egenhostning. Du kan driftsätta Payload var som helst, för alltid.

Vad som förändrades:

• Payload Cloud pausade nya registreringar. Befintliga kunder kan fortsätta, men nya projekt kan inte använda Payloads hanterade hosting.
• Teamfokus förskjutet. Payload-teamet bygger nu det som sannolikt kommer att bli "Figma CMS" -- och bygga bryggan mellan Figma-designer och live-innehåll. Detaljerna är spekulativa, men riktningen är tydlig.
• Communitys uppmärksamhet. Vissa utvecklare oroar sig för "förvärvat-sedan-övergiven"-mönstret som plågar öppen källkod-projekt. MIT-licensen mildrar det värsta scenariot, men det är en legitim oro.

Bör du fortfarande välja Payload?

Ärligt? Ja, med förbehåll.

Det goda: Figmas resurser innebär mer ingenjörstalang bakom projektet. MIT-licensen innebär att det värsta fallet är att du forkar det. Kodbasen är mogen, väldokumenterad och används aktivt i produktion av tusentals projekt.

Det oroande: Figmas incitament kan divergera från open source-communityns behov över tid. Payload Cloud-luckan tvingar dig att hantera hosting själv. Och om du är riskavert är osäkerheten kring den långsiktiga riktningen verklig.

Vår bedömning: om du är bekväm med egenhostning (vilket du borde vara -- det är inte svårt) är Payload fortfarande det bästa öppen källkod, kod-first headless CMS:et tillgängligt. Vänta inte på "Figma CMS." Bygg med Payload 3 idag, egenhosta och gå vidare.

Hur man driftsätter Payload CMS 2026

Med Payload Cloud pausad för nya registreringar är dina huvudsakliga driftsättningsalternativ 2026: Vercel (snabbast uppstart, håll koll på kalla starter), Docker på en VPS (bäst för aktiva redaktörer, EUR 7-45/mån), Railway/Render/Fly.io (hanterade containers) eller Cloudflare Workers (billigast, ~5-10 $/mån). Enligt Payloads driftsättningsdokumentation fungerar alla Node.js-hostingalternativ som stödjer Next.js.

Vi har driftsatt Payload till både Vercel och en Docker-baserad VPS. Här är vad som överraskade oss: Vercels kalla starter gjorde adminpanelen trög för redaktörer som bara loggade in några gånger per vecka. VPS:en, trots att den kräver mer uppstart, gav en konsekvent bättre redaktionell upplevelse.

Vercel (Snabbast uppstart)

Ett-klicks deploy med Neon Postgres och Vercel Blob för filuppladdningar. Snabbaste vägen till produktion.

Fördelar: Noll infrastrukturhantering, utmärkt CDN, bra för webbplatser med lätt redaktionell aktivitet. Nackdelar: Kalla starter för adminpanelen (3-5 sekunder efter inaktivitet), Postgres connection exhaustion under tunga frågor, 10-sekunders timeout-tak kan bryta bulkoperationer. Bäst för: Marknadsföringssidor, portföljer, bloggar med ovanlig redigering.

För mer sammanhang om Vercels styrkor och begränsningar, se vår Vercel vs Netlify-jämförelse.

Docker på en VPS (Bäst för produktion)

En Docker Compose-konfiguration på Hetzner, DigitalOcean eller AWS EC2. Det matchar Payloads arkitektur bättre än serverlöst eftersom Payload förväntar sig en persisterande serverprocess.

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

Fördelar: Persisterande server (inga kalla starter), förutsägbara kostnader (EUR 7-45/mån på Hetzner), full kontroll över stacken. Nackdelar: Du hanterar servern, SSL, säkerhetskopior och uppdateringar. Bäst för: Byråer, aktiva redaktionella team, multi-tenant-konfigurationer, appar med tung adminanvändning.

En detaljerad hostingjämförelse från Build with Matija täcker ytterligare VPS-leverantörer och konfigurationer.

Hanterade containers (Railway, Render, Fly.io)

Om Docker på en VPS låter som för mycket ops-arbete delar hanterade containerplattformar skillnaden. Railway är särskilt populärt i Payload-communityt -- de har en Payload-mall som driftsätts med ett klick.

Kolla vår Railway vs Render vs Fly.io-jämförelse för en djupare titt på dessa plattformar.

Bäst för: Team som vill ha persisterande servrar utan att hantera infrastruktur direkt.

Cloudflare Workers (Billigast)

Det nyaste alternativet. Payload lade till en Cloudflare Workers-adapter som körs på edge-funktioner med D1 (SQLite) eller Hyperdrive (Postgres-proxy). Fortfarande lite experimentellt, men kostnaden kan inte slås: ~5-10 $/mån för de flesta projekt.

Bäst för: Sidoprojekt, personliga webbplatser, kostnadsmedvetna driftsättningar där du är bekväm med nyare, mindre testad infrastruktur.

Vår bedömning: För de flesta produktions-Payload-projekt med aktiva redaktörer är Docker på en VPS den bästa standardlösningen. Det är billigare än du tror, eliminerar problem med kalla starter och ger dig full kontroll. Använd Vercel bara om dina redaktörer sällan redigerar och du vill ha noll ops-overhead.

Payload CMS prissättning -- Vad det faktiskt kostar

Payload själv är gratis och MIT-licensierat. Dina verkliga kostnader är hosting och (valfritt) professionell utveckling. Här är hur siffrorna faktiskt ser ut, baserat på verkliga konfigurationer och prissättningsöversikten från Build with Matija.

För jämförelse: Contentfuls Team-plan börjar på $300/mån. Sanitys Team-plan är $99/mån per projekt. Strapi Cloud börjar på $29/mån. Payloads $0 programvarukostnad plus $7-25/mån hosting är svårt att argumentera emot -- särskilt för byråer som bygger kundprojekt där prissättning per seat urholkar marginalerna.

Payload vs Sanity vs Strapi vs Contentful -- Snabb jämförelse

Välj Payload om du vill ha kod-first-kontroll och egenhostning. Välj Sanity för den bästa visuella redigeringen och realtidssamarbetet. Välj Strapi för en snabb adminpanel med plugin-ekosystem. Välj Contentful för enterprise-grad infrastruktur med SLA-garantier. Vi använder Sanity för techsy.io, så vi har förstahandsupplevelse av att jämföra dessa plattformar.

Vi har byggt Payload-baserade projekt för kunder som behöver dataägarskap och egenhostning, och vi kör vår egen innehållspipeline på Sanity. Båda är utmärkta -- rätt val beror på ditt teams tekniska kompetens och hostingpreferenser. Utvärderar du headless CMS-alternativ för ett projekt? Vi kan hjälpa dig välja.

För djupdykningar på varje plattform, kolla våra guider: bästa headless CMS 2026, och individuella guider för Sanity, Strapi och Contentful kommer snart.

När man INTE ska använda Payload CMS

Hoppa över Payload om ditt team är icke-tekniskt och behöver ett WordPress-liknande GUI, om du behöver omedelbar hanterad molnhosting utan egenhostningsarbete, om dina redaktörer vill ha visuell redigering på Sanity Studio-nivå, eller om du behöver en plugin-marketplace för snabb funktionsutökning. Att vara ärlig om begränsningar bygger mer förtroende än att låtsas att de inte finns.

Vi har rekommenderat emot Payload för kunder vars redaktionella team inte hade någon TypeScript-erfarenhet. Här är när du bör titta någon annanstans:

• Icke-tekniska team. Payload kräver TypeScript-kunskaper för konfiguration. Om din kunds redaktörer inte kan röra kod och behöver modifiera innehållsmodellen själva är WordPress eller Sanity bättre alternativ.
• Du behöver hanterad hosting direkt. Med Payload Cloud pausad för nya registreringar måste du egenhosta. Om att hantera en server (även en enkel Docker-konfiguration) är ett dealbreaker tar Contentfuls eller Sanitys molnbaserade tillvägagångssätt bort den bördan.
• Tung redaktionell samarbete. Sanity Studios realtidssamarbete -- flera redaktörer som arbetar på samma dokument samtidigt med närvaro-indikatorer -- är mer polerat än allt Payload erbjuder. Har du ett stort redaktionellt team vinner Sanity här.
• Plugin-driven utveckling. Strapi har en större plugin-marketplace. Behöver du ett SEO-plugin, en sitemapgenerator, en e-postintegration? Strapi har förmodligen ett. Payloads ekosystem växer men är mindre.
• Du använder inte Next.js. Payload 3 är arkitektoniskt bundet till Next.js. Om din frontend är Astro, Remix, Nuxt eller SvelteKit gäller inte Payloads största fördel (Local API i server components). Du får fortfarande REST och GraphQL, men i det läget kan Strapi eller Directus kännas mer naturligt.

FAQ

Vad är Payload CMS och hur fungerar det?

Payload är ett öppen källkod, TypeScript-nativt headless CMS och applikationsramverk byggt på Next.js. Du definierar din innehållsmodell i TypeScript-konfigurationsfiler och Payload genererar automatiskt en adminpanel, REST API, GraphQL API och Local API. Det körs inuti din Next.js-app som en enda driftsättningsenhet.

Är Payload CMS gratis att använda?

Payload är helt gratis under MIT-licensen. Programvaran kostar ingenting att ladda ner, använda eller modifiera. Payload Cloud (hanterad hosting) kostade $35-199/mån men är för närvarande pausad för nya registreringar efter Figma-förvärvet. Egenhostning på en VPS kostar EUR 7-45/mån beroende på leverantör.

Vad hände med Payload och Figma?

Figma förvärvade Payload den 17 juni 2025. Hela Payload-teamet gick med i Figma. Den öppna MIT-licensen och GitHub-repositoriet förblir oförändrade. Payload Cloud pausade nya registreringar. Egenhostning fortsätter att fungera normalt. Teamet bygger sannolikt en Figma-integrerad CMS-produkt, men detaljerna har inte tillkännagivits.

Vilken databas använder Payload CMS?

Payload stöder tre databaser via ett adaptermönster: PostgreSQL (rekommenderas för produktion, fungerar med Neon och Supabase för serverlöst), MongoDB (bra för dokumenttunga modeller eller Payload 2-uppgraderingar) och SQLite (enbart lokal utveckling och CI). Din applikationskod förblir densamma oavsett vilken adapter du väljer.

Hur driftsätter jag Payload CMS 2026?

Med Payload Cloud pausad, driftsätt till Vercel med Neon Postgres (enklast), Docker på en VPS som Hetzner (bäst för produktion med aktiva redaktörer), Railway eller Render (hanterade containers) eller Cloudflare Workers (billigast). För de flesta produktionssajter med regelbunden redaktionell aktivitet ger en Docker-baserad VPS den bästa upplevelsen.

Är Payload CMS bättre än Strapi?

Payload vinner på TypeScript-nativ utvecklarupplevelse, Next.js-integration och det unika Local API:et för noll-overhead server-side-frågor. Strapi vinner på sin plugin-marketplace, GUI-baserad schemöredigering och bredare ramverkskompatibilitet. Om ditt team skriver TypeScript och använder Next.js är Payload det starkare valet. Annars, utvärdera Strapi.

Vad är Payloads Local API?

Local API är ett server-side-frågelager som anropar din databas direkt med noll HTTP-overhead. Istället för att göra REST- eller GraphQL-anrop importerar du Payload och frågar collections direkt i Next.js server components. Det eliminerar nätverksturer och serialiseringskostnader, vilket resulterar i snabbare sidladdningar. Inget annat headless CMS erbjuder detta.

Kan Payload CMS hantera storskaliga applikationer?

Payload stöder PostgreSQL med connection pooling (via Neon eller PgBouncer), rollbaserad åtkomstkontroll med fältnivågranularitet, utkast- och versionsarbetsflöden samt multi-tenant-arkitekturer. Företag och byråer använder Payload i produktion för innehållstunga applikationer. Local API:ets noll-overhead-frågor förbättrar faktiskt prestandan i stor skala.

Hur jämförs Payload med Sanity?

Payload är egenhostad, kod-first och MIT-licensierad med ett Local API för server-side-prestanda. Sanity är molnhostad med överlägsen visuell redigering, realtidssamarbete och GROQ-frågespråket. Payload ger dig mer infrastrukturkontroll och lägre kostnader. Sanity ger dig bättre redaktionella verktyg och noll hostinghantering.

Vilka är nackdelarna med Payload CMS?

Payload kräver TypeScript-kunskaper för konfiguration, har ingen hanterad molnhosting för nya användare sedan Figma-förvärvet, erbjuder ett mindre plugin-ekosystem än Strapi och är arkitektoniskt bundet till Next.js i version 3. Icke-tekniska team kan kämpa med kod-first-tillvägagångssättet och Figma-förvärvet skapar viss långsiktig osäkerhet.