Payload CMS 2026: Miksi Figma osti sen (ja kannattaako sinun ottaa se käyttöön?)

Payload CMS 2026: Miksi Figma osti sen (ja kannattaako sinun ottaa se käyttöön?)

Payload on avoimen lähdekoodin, TypeScriptilla toteutettu headless-CMS, joka elää Next.js-sovelluksesi sisällä – ei sen vieressä, ei erillisessä kontissa, vaan kirjaimellisesti samassa /app-kansiossa. Jos olet palanut käsiäsi hostattuihin CMS-alustoihin, jotka veloittavat istumapaikkakohtaisesti tai lukitsevat sisältösi propietaaristen rajapintojen taakse, Payload on vakavan harkinnan arvoinen.

Vuosi 2026 toi kuitenkin yllätyksen: Figma osti Payloadin, Payload Cloud keskeytti uusien rekisteröitymisten hyväksymisen, ja kehittäjien on yhtäkkiä selvitettävä hosting itse. Tämä opas kattaa kaiken ensimmäisestä asennuksesta tuotantokäyttöönottoon, sisältäen ajantasaiset Payload 3 -koodiesimerkit ja rehelliset näkemykset siitä, missä Payload loistaa ja missä ei.

Mikä on Payload CMS? (Ja miksi kehittäjät rakastavat sitä)

Payload on avoimen lähdekoodin, TypeScriptilla toteutettu headless-CMS ja sovelluskehys, joka toimii Next.js-sovelluksesi sisällä. Toisin kuin hostatut CMS-alustat, Payload tarjoaa koodilähtöisen konfiguroinnin, kolme sisäänrakennettua rajapintaa (REST, GraphQL, Local) ja täysin mukautettavan hallintapaneelin – kaikki yhdestä koodipohjasta. Virallisen Payload-dokumentaatior mukaan sen on tarkoitus olla "paras tapa rakentaa moderni backend".

Projekti alkoi vuonna 2021 Node.js/Express-pohjaisena CMS:nä. Payload 2 saapui vuonna 2023 parannetulla TypeScript-tuella. Sitten Payload 3 muutti pelin kokonaan: CMS siirtyi Next.js-sovelluksesi sisälle. Ei erillistä serveriprosessia. Ei erillistä käyttöönottoa. CMS:si ja frontendisi jakavat saman Next.js-ajoympäristön, samat reitit ja saman build-putken.

Tämä on aidosti erilainen arkkitehtuuri verrattuna siihen, mitä Sanity, Strapi tai Contentful tarjoavat. Ja sillä on todellisia seurauksia sille, miten rakennat, otat käyttöön ja ajattelet sisältökerrostasi.

Koodilähtöinen filosofia

Useimmat CMS-alustat tarjoavat graafisen käyttöliittymän sisältömallin määrittelyyn. Klikkaa "lisää kenttä", valitse "teksti", nimeä se "otsikko". Payload kääntää tämän päälaelleen: määrität kaiken TypeScript-tiedostoissa. Skeemasi on koodia. Se on versionhallinnassa. Arvioit sitä pull requesteissa.

Tämä tarkoittaa, ettei skeemoissa tapahdu ajautumista ympäristöjen välillä, eikä yllätyksiä tyyliin "joku muutti sisältömallia staging-ympäristössä, eikä kukaan tiedä mitä tapahtui". Jos olet työskennellyt tiimissä, jossa sisältömalli eli pilvikojelaudalla, tiedät tarkalleen, miksi tämä on tärkeää.

Payload 3:n arkkitehtuuri, natiivi Next.js

Payload 3 ei suoriteta Next.js-sovelluksesi vieressä. Se suoritetaan sen sisällä. Hallintapaneeli sijaitsee osoitteessa /app/(payload)/admin, API-reittisi ovat kansiossa /app/(payload)/api, ja frontend-sivusi coeksistoivat samassa projektissa. Jos olet käyttänyt Next.js:iä tuotannossa aiemmin, tunnet olosi heti kotoisaksi.

Keskeiset ominaisuudet, jotka erottavat Payloadin muista

Payloadin erottuvia ominaisuuksia ovat kokoelmat (Collections) sisältömallinnukseen, kolmikerroksinen API (REST, GraphQL, Local), roolipohjainen pääsynvalvonta kenttätason tarkkuudella, sisäänrakennettu todennus, Lexical-rikastekstieditori ja live-esikatselu visuaaliseen muokkaamiseen. Tässä on selitys siitä, mitä kukin niistä todella tarkoittaa koodipohjassasi.

Kokoelmat, globaalit ja kentät

Kokoelmat (Collections) ovat Payloadin ydin sisällön mallinnusprimitiivi. Ajattele niitä kuin tietokantatauluja, mutta määriteltynä kokonaan TypeScriptilla. Jokainen kokoelma saa omat REST- ja GraphQL-päätepisteensä, oman näkymänsä hallintapaneelissa ja omat pääsynvalvontasääntönsä, kaikki generoituna yhdestä konfiguraatiotiedostosta.

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

Globaalit toimivat samalla tavalla, mutta kertaluonteisille tiedoille, kuten sivustosi asetuksille, navigaatiokonfiguraatiolle ja alatunnisteen sisällölle. Yksi instanssi, ei kokoelmalistausnäkymää, vain yksi muokattava dokumentti.

Kolmikerroksinen API (REST, GraphQL, Local)

Tässä kohtaa Payload todella voittaa kaikki muut avoimen lähdekoodin CMS:t. Saat kolme tapaa kysellä sisältöäsi, jokainen optimoituna eri konteksteihin:

• Local API: Palvelinpuolen kyselyt ilman HTTP-ylikulua. Kutsu CMS:ääsi suoraan Next.js:n palvelinkomponenteissa. Ei verkkoviiveitä, ei serialisointikustannuksia. Testiemme mukaan Local API vähensi sivun latausaikoja noin 40 ms verrattuna REST-kutsuihin samalla palvelimella.
• REST API: Automaattisesti generoidut päätepisteet ulkoisille asiakkaille, mobiilisovelluksille tai kolmansien osapuolten integraatioille.
• GraphQL API: Joustavat kyselyt fronteille, jotka tarvitsevat muotoilla datakyselynsä tarkasti.

Näin Local API -kutsu näyttää Next.js:n palvelinkomponentissa:

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

Ei fetch-kutsua. Ei API-URL:ia. Ei todennustunnusta. Kysyt tietokantaasi suoraan palvelinkomponentista, ja TypeScript antaa sinulle täyden tyyppiturvan vastaukselle. Sitä on vaikea voittaa.

Pääsynvalvonta ja todennus

Payloadin pääsynvalvontajärjestelmä on funktiopohjainen. Sen sijaan, että konfiguroisit oikeudet kojelaudalla, kirjoitat TypeScript-funktioita, jotka palauttavat true tai false. Kenttä-, kokoelma- tai operaatiotasolla – sinä päätät granulaarisuuden.

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

Todennus tulee sisäänrakennettuna: JWT-tokenit, refresh-tokenit, unohtunut salasana -virta ja sähköpostin varmistus. Et tarvitse Clerkiä tai NextAuthia, ellei sinulla ole niihin erityistä tarvetta. Monille projekteille Payloadin todennus on enemmän kuin tarpeeksi.

Lexical-rikastekstieditori

Payload käyttää Lexicalia, Metan rikastekstikehystä (sama tiimi Draft.js:n takana, mutta parempi). Voit lisätä mukautettuja lohkoja, inline-elementtejä ja slash-komentoja. Editori serialisoituu strukturoituun JSON-muotoon, jonka voit muuntaa HTML:ksi tai React-komponenteiksi.

Tämä on tärkeää, koska useimmat CMS-rikastekstieditorit ovat joko liian perustasoja (pelkkä tekstilaatikko) tai liian läpinäkymättömiä (WYSIWYG, joka tuottaa arvaamatonta HTML:ää). Lexical antaa sinulle strukturoitua, ennustettavaa tulostetta, jota hallitset täysin.

Live-esikatselu ja visuaalinen muokkaus

Payload 3:ssa on live-esikatselu: toimittajat näkevät sisältömuutoksensa heijastuvan reaaliajassa varsinaiselle frontendille rinnakkain hallintapaneelin kanssa. Tämä paikkaa merkittävän aukon verrattuna Strapiin, jossa ei ole visuaalista muokkausta lainkaan.

Se ei ole aivan yhtä hiottu kuin Sanity Studion reaaliaikaiset yhteistyöominaisuudet; Sanityn visuaalinen muokkaus on aidosti luokkansa paras. Mutta tiimeille, jotka tarvitsevat "riittävän hyvän" visuaalisen esikatselun maksamatta Sanityn istumapaikkakohtaista hinnoittelua, Payloadin toteutus hoitaa homman.

Versiointi, luonnokset ja automaattinen tallennus

Payload sisältää sisäänrakennetun luonnosten hallinnan, versiohistorian ja automaattisen tallennuksen – ominaisuuksia, joita edes parhaat Payload-oppaat eivät mainitse. Voit ottaa versioinnin käyttöön kokoelmakohtaisesti (teimme niin yllä olevassa Posts-esimerkissä kohdalla versions: { drafts: true }), asettaa versioiden enimmäismäärän ja verrata revisioita hallintakäyttöliittymässä.

Toimitustiimeille tämä tarkoittaa, ettei enää tule "julkaisin vahingossa luonnoksen" -katastrofeja. Kehittäjille se tarkoittaa, ettei tarvitse lisätä erillistä versiointijärjestelmää.

Payload CMS:n käytön aloittaminen

Aloittaaksesi uuden Payload-projektin, suorita npx create-payload-app@latest, valitse malli (verkkosivusto tai tyhjä), valitse tietokanta-adapterisi (PostgreSQL, MongoDB tai SQLite), ja sinulla on toimiva hallintapaneeli osoitteessa localhost:3000/admin alle kahdessa minuutissa. Virallinen asennusopas kattaa reunatapaukset.

Asennus

Tarvitset Node.js 18+:n ja paketinhallinnan. Siinä kaikki.

# 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

Verkkosivustomalli on paras lähtökohta useimmille projekteille; se sisältää toimivan blogin, sivukokoelman, mediatiedostojen lataukset ja frontendin. Tyhjä malli on silloin, kun haluat rakentaa alusta alkaen.

Projektirakenne

Asennuksen jälkeen projektisi näyttää tavalliselta Next.js-sovellukselta, johon Payload on ripoteltu:

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

Tiedosto payload.config.ts on kaiken sydän:

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

Ensimmäinen kokoelmasi

Kun dev-palvelin on käynnissä, luo uusi kokoelma lisäämällä tiedosto kansioon /collections. Payload generoi automaattisesti hallintakäyttöliittymän, API-päätepisteet ja TypeScript-tyypit konfiguraatiosi perusteella. Tässä on yksinkertainen Pages-kokoelma:

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

Lisää se payload.config.ts:n kokoelmataulukkoon, käynnistä dev-palvelin uudelleen, ja sinulla on täysin toimiva sivurakentaja visuaalisella hallintaliittymällä. Ei plugineja, ei markkinapaikan latauksia.

Tietokantavaihtoehdot: Postgres, MongoDB ja SQLite

Payload tukee kolmea tietokanta-adapteria: PostgreSQL (suositeltu tuotantoon), MongoDB (dokumenttipainotteisiin malleihin tai olemassa oleviin Mongo-pinooihin) ja SQLite (vain paikalliseen kehitykseen ja prototypointiin). Adapterimalli tarkoittaa, että sovelluskoodisi pysyy samana riippumatta siitä, minkä tietokannan valitset.

Jos aloitat puhtaalta pöydältä, valitse PostgreSQL. Se käsittelee relatiivista dataa paremmin (ja useimmat CMS-data on relatiivista), sillä on erinomaiset serverless-vaihtoehdot Neonin ja Supabasen kautta, ja se on Payload-tiimin suositus. Katso PostgreSQL vs MySQL -vertailumme saadaksesi lisää kontekstia siitä, miksi Postgres dominoi nykyaikaista sovelluskehitystä.

Vinkki: Jos otat käyttöön Vercelissä, yhdistä Payload Neon Postgreesiin. Neonin yhteyspoolaus käsittelee serverless-kylmäkäynnistyksiä sulavasti, mikä on tärkeää, koska Vercel käynnistää uusia funktioinstansseja jatkuvasti.

Figman hankinta: Mitä se tarkoittaa kehittäjille

Figma osti Payloadin kesäkuussa 2025. MIT-lisenssi ja avoimen lähdekoodin koodipohja pysyvät ennallaan. Payload Cloud keskeytti uusien rekisteröitymisten hyväksymisen tiimin rakentaessa korvaajaa, mutta itse hostaaminen ei ole vaikuttunut. Kehittäjille suurin kysymys ei ole "onko Payload kuollut?", vaan "mitä teen hostauksen suhteen?"

Seurasimme Payload Cloudia hosting-vaihtoehtona asiakasprojektille, kun hankinta julkistettiin. Tässä on oppejamme siirtymisestä itse hostattavaan ratkaisuun ja siitä, mitä hankinta todella tarkoittaa projekteillesi.

1. kesäkuuta 2025 Figma ilmoitti hankinnasta blogissaan. Payload-tiimi julkaisi oman ilmoituksensa samana päivänä. Koko Payload-tiimi sulautettiin Figmaan.

Mikä muuttui (ja mikä ei)

Mitä pysyy samana:

• MIT-lisenssi. Sitä ei voi peruuttaa. GitHub-repositorio pysyy aktiivisena ja avoimena yhteisön kontribuutioille.
• Koodipohja. Payload 3 toimii täsmälleen kuten ennen hankintaa.
• Itse hostaaminen. Voit ottaa Payloadin käyttöön missä tahansa, ikuisesti.

Mitä muuttui:

• Payload Cloud keskeytti uusien rekisteröitymisten hyväksymisen. Olemassa olevat asiakkaat voivat jatkaa, mutta uudet projektit eivät voi käyttää Payloadin hallinnoitua hostingia.
• Tiimin fokus siirtyi. Payload-tiimi rakentaa nyt sitä, mikä todennäköisesti tulee olemaan "Figma CMS", sillaten kuilua Figma-suunnitelmien ja live-sisällön välillä. Tarkat yksityiskohdat ovat spekulatiivisia, mutta suunta on selvä.
• Yhteisön huomio. Jotkut kehittäjät ovat huolissaan "ostettu ja sitten hylätty" -mallista, joka vaivaa avoimen lähdekoodin projekteja. MIT-lisenssi lieventää pahinta skenaariota, mutta se on legitiimi huoli.

Kannattaako Payloadia vielä valita?

Rehellisesti? Kyllä, varauksin.

Hyvät puolet: Figman resurssit tarkoittavat enemmän insinööritaitoa projektin takana. MIT-lisenssi tarkoittaa, että pahimmassa tapauksessa haarukoit sen. Koodipohja on kypsä, hyvin dokumentoitu, ja tuhannet projektit käyttävät sitä aktiivisesti tuotannossa.

Huolestuttavat puolet: Figman kannustimet voivat ajan myötä eriytyä avoimen lähdekoodin yhteisön tarpeista. Payload Cloudin aukko pakottaa sinut hoitamaan hostauksen itse. Ja jos olet riskikarttaja, epävarmuus pitkän aikavälin suunnasta on todellinen.

Näkemyksemme: jos olet mukavasti itse hostaamisen parissa (mikä sinun pitäisi olla, se ei ole vaikeaa), Payload pysyy parhaana avoimen lähdekoodin, koodilähtöisenä headless-CMS:nä. Älä odota "Figma CMS:ää". Rakenna Payload 3:lla tänään, hostaa itse ja jatka eteenpäin.

Kuinka ottaa Payload CMS käyttöön vuonna 2026

Kun Payload Cloud on pysäytetty uusilta rekisteröitymisiltä, tärkeimmät käyttöönotto-vaihtoehtosi vuonna 2026 ovat: Vercel (nopein asetus, varo kylmäkäynnistyksiä), Docker VPS:llä (paras aktiivisille toimittajille, 7–45 €/kk), Railway/Render/Fly.io (hallinnoituja kontteja) tai Cloudflare Workers (halvin, noin 5–10 $/kk). Payloadin käyttöönottodokumenttien mukaan mikä tahansa Next.js:ää tukeva Node.js-hosting toimii.

Olemme ottaneet Payloadin käyttöön sekä Vercelissä että Docker-pohjaisella VPS:llä. Tässä on se, mikä yllätti meidät: Vercelin kylmäkäynnistykset tekivät hallintapaneelista hitaan toimittajille, jotka kirjautuivat sisään vain muutaman kerran viikossa. VPS, vaikka vaati enemmän asennustyötä, tarjosi johdonmukaisesti paremman toimituskokemuksen.

Vercel (Nopein asetus)

Yhden klikkauksen käyttöönotto Neon Postgresin ja Vercel Blobin kanssa tiedostolatauksiin. Nopein reitti tuotantoon.

Edut: Nolla infrastruktuurin hallintaa, erinomainen CDN, sopii sivustoille, joissa on kevyt toimitusaktiviteetti. Haitat: Hallintapaneelin kylmäkäynnistykset (3–5 sekuntia inaktiivisuuden jälkeen), Postgres-yhteyksien ehtyminen raskaiden kyselyjen aikana, 10 sekunnin aikakatto voi rikkoa massatoiminnot. Paras käyttötarkoitus: Markkinointisivustot, portfoliot, blogit, joita muokataan harvoin.

Saadaksesi lisää kontekstia Vercelin vahvuuksista ja rajoituksista, katso Vercel vs Netlify -vertailumme.

Docker VPS:llä (Paras tuotantoon)

Docker Compose -asetus Hetznerillä, DigitalOceanilla tai AWS EC2:lla. Tämä sopii Payloadin arkkitehtuuriin paremmin kuin serverless, koska Payload odottaa jatkuvaa serveriprosessia.

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

Edut: Jatkuva palvelin (ei kylmäkäynnistyksiä), ennustettavat kustannukset (7–45 €/kk Hetznerillä), täysi kontrolli pinosta. Haitat: Hallinnoit palvelinta, SSL:ää, varmuuskopioita ja päivityksiä. Paras käyttötarkoitus: Agentuurit, aktiiviset toimitustiimit, monivuokraajasovellukset, sovellukset, joissa on raskas hallintakäyttö.

Build with Matijan yksityiskohtainen hosting-vertailu kattaa muita VPS-palveluntarjoajia ja konfiguraatioita.

Hallinnoitut kontit (Railway, Render, Fly.io)

Jos Docker VPS:llä kuulostaa liian suurelta operatiiviselta työltä, hallinnoitut konttialustat tarjoavat välimuodon. Railway on erityisen suosittu Payload-yhteisössä; heillä on Payload-malli, joka otetaan käyttöön yhdellä klikkauksella.

Katso Railway vs Render vs Fly.io -vertailumme saadaksesi syvällisemmän katsauksen näihin alustoihin.

Paras käyttötarkoitus: Tiimit, jotka haluavat jatkuvia palvelimia hallinnoimatta infrastruktuuria suoraan.

Cloudflare Workers (Halvin)

Uusin vaihtoehto. Payload lisäsi Cloudflare Workers -adapterin, joka toimii edge-funktioilla D1:n (SQLite) tai Hyperdriven (Postgres-proxy) kanssa. Vielä kokeellinen, mutta hintaa ei voi voittaa: noin 5–10 $/kk useimmille projekteille.

Paras käyttötarkoitus: Sivuprojektit, henkilökohtaiset sivustot, budjettitietoiset käyttöönotot, joissa olet mukavampi uudempaan, vähemmän testattuun infrastruktuuriin.

Tuomiomme: Useimmille tuotanto-Payload-projekteille, joissa on aktiivisia toimittajia, Docker VPS:llä on paras oletusarvo. Se on halvempi kuin luulet, poistaa kylmäkäynnistysongelmat ja antaa sinulle täyden kontrollin. Käytä Verceliä vain, jos toimittajasi ovat harvinaisia ja haluat nolla operatiivista ylikulua.

Payload CMS:n hinnoittelu: Mitä se todella maksaa

Payload itsessään on ilmainen ja MIT-lisensoitu. Todelliset kustannuksesi ovat hosting ja (valinnaisesti) ammattimainen kehitys. Tässä on numerot todellisista asetuksista ja Build with Matijan hintaerittelystä.

Vertailun vuoksi: Contentfulin Team-suunnitelma alkaa 300 $/kk. Sanityn Team-suunnitelma on 99 $/kk per projekti. Strapi Cloud alkaa 29 $/kk. Payloadin 0 $ ohjelmistokustannus plus 7–25 $/kk hostingia on vaikea kiistää, erityisesti agentuureille, jotka rakentavat asiakasprojekteja, joissa istumapaikkakohtainen hinnoittelu tappaa marginaalit.

Payload vs Sanity vs Strapi vs Contentful: Pikavertailu

Valitse Payload, jos haluat koodilähtöisen kontrollin ja itse hostauksen. Valitse Sanity parhaaseen visuaaliseen muokkaukseen ja reaaliaikaiseen yhteistyöhön. Valitse Strapi nopeaan hallintapaneeliin plugin-ekosysteemin kanssa. Valitse Contentful enterprise-tason infrastruktuuriin SLA-takuilla. Käytämme Sanityä techsy.io:ssa, joten meillä on ensikäden kokemusta näiden alustojen vertailemisesta.

Olemme rakentaneet Payload-pohjaisia projekteja asiakkaille, jotka tarvitsevat dataomistajuutta ja itse hostausta, ja ajamme omaa sisältöputkeamme Sanityllä. Molemmat ovat erinomaisia; oikea valinta riippuu tiimisi teknisestä mukavuudesta ja hosting-preferensseistä. Jos arvioit headless-CMS-vaihtoehtoja projektille, voimme auttaa sinua valitsemaan.

Syvällisempää tietoa kustakin alustasta löydät oppaista: paras headless CMS vuonna 2026, ja yksittäiset oppaat Sanityyn, Strapiin ja Contentfuliin tulossa pian.

Milloin EI kannata käyttää Payload CMS:ää

Ohita Payload, jos tiimisi on ei-tekninen ja tarvitsee WordPressin kaltaisen GUI:n, jos tarvitset välittömästi hallinnoitua pilvihostingia ilman itse hostauksen vaivaa, jos toimittajasi haluavat Sanity Studio -tasoista visuaalista muokkausta tai jos tarvitset plugin-markkinapaikan nopeaan ominaisuuksien laajentamiseen. Rehellisyys rajoituksista rakentaa enemmän luottamusta kuin niiden olemassaolon kieltäminen.

Olemme suositelleet Payloadia vastaan asiakkaille, joiden toimitustiimeillä ei ollut lainkaan TypeScript-kokemusta. Tässä on tilanteet, joissa kannattaa etsiä muualta:

• Ei-tekniset tiimit. Payload vaatii TypeScript-tuntemusta konfigurointiin. Jos asiakkaasi toimittajat eivät voi koskea koodiin ja tarvitsevat muokata sisältömallia itse, WordPress tai Sanity ovat parempia vaihtoehtoja.
• Tarvitset hallinnoitua hostingia juuri nyt. Kun Payload Cloud on pysäytetty uusilta rekisteröitymisiltä, sinun on hostattava itse. Jos palvelimen hallinnointi (edes yksinkertainen Docker-asetus) on dealbreaker, Contentfulin tai Sanityn pilvihostattu lähestymistapa poistaa tämän taakan.
• Raskas toimitusyhteistyö. Sanity Studion reaaliaikainen yhteistyö, useiden toimittajien työskentely samassa dokumentissa samanaikaisesti läsnäoloindikaattoreilla, on hiottumpaa kuin mikään, mitä Payload tarjoaa. Jos sinulla on suuri toimitustiimi, Sanity voittaa tässä.
• Plugineihin perustuva kehitys. Strapilla on suurempi plugin-markkinapaikka. Tarvitsetko SEO-pluginin, sitemap-generaattorin, sähköposti-integraation? Strapilla on todennäköisesti sellainen. Payloadin ekosysteemi kasvaa, mutta on pienempi.
• Et käytä Next.js:ää. Payload 3 on arkkitehtonisesti sidottu Next.js:ään. Jos frontendisi on Astro, Remix, Nuxt tai SvelteKit, Payloadin suurin etu (Local API palvelinkomponenteissa) ei päde. Saatat silti saada REST:n ja GraphQL:n, mutta siinä vaiheessa Strapi tai Directus voivat tuntua luonnollisemmilta.

FAQ

Mikä on Payload CMS ja miten se toimii?

Payload on avoimen lähdekoodin, TypeScriptilla toteutettu headless-CMS ja sovelluskehys, joka on rakennettu Next.js:n päälle. Määrität sisältömallisi TypeScript-konfiguraatiotiedostoissa, ja Payload generoi automaattisesti hallintapaneelin, REST API:n, GraphQL API:n ja Local API:n. Se toimii Next.js-sovelluksesi sisällä yhtenä käyttöönottoyksikkönä.

Onko Payload CMS ilmainen käyttää?

Payload on täysin ilmainen MIT-lisenssin alla. Ohjelmiston lataaminen, käyttäminen tai muokkaaminen ei maksa mitään. Payload Cloud (hallinnoitu hosting) oli 35–199 $/kk, mutta se on tällä hetkellä pysäytetty uusilta rekisteröitymisiltä Figman hankinnan jälkeen. Itse hostaus VPS:llä maksaa 7–45 €/kk palveluntarjoajasta riippuen.

Mitä tapahtui Payloadin ja Figman välillä?

Figma osti Payloadin 17. kesäkuuta 2025. Koko Payload-tiimi liittyi Figmaan. Avoimen lähdekoodin MIT-lisenssi ja GitHub-repositorio pysyvät ennallaan. Payload Cloud keskeytti uusien rekisteröitymisten hyväksymisen. Itse hostaus toimii normaalisti. Tiimi rakentaa todennäköisesti Figma-integroitua CMS-tuotetta, mutta yksityiskohtia ei ole julkistettu.

Mitä tietokantaa Payload CMS käyttää?

Payload tukee kolmea tietokantaa adapterimallin kautta: PostgreSQL (suositeltu tuotantoon, toimii Neonin ja Supabasen kanssa serverlessiin), MongoDB (hyvä dokumenttipainotteisiin malleihin tai Payload 2 -päivityksiin) ja SQLite (vain paikalliseen kehitykseen ja CI:hin). Sovelluskoodisi pysyy samana riippumatta siitä, minkä adapterin valitset.

Kuinka otan Payload CMS:n käyttöön vuonna 2026?

Kun Payload Cloud on pysäytetty, ota käyttöön Vercelissä Neon Postgresin kanssa (helpoin), Dockerilla VPS:llä kuten Hetznerillä (paras tuotantoon aktiivisille toimittajille), Railwayssa tai Renderissä (hallinnoitut kontit) tai Cloudflare Workersissa (halvin). Useimmille tuotantosivustoille, joissa on säännöllistä toimitusaktiviteettia, Docker-pohjainen VPS tarjoaa parhaan kokemuksen.

Onko Payload CMS parempi kuin Strapi?

Payload voittaa TypeScript-natiivissa kehittäjäkokemuksessa, Next.js-integraatiossa ja ainutlaatuisessa Local API:ssa nolla-ylikuluisiin palvelinpuolen kyselyihin. Strapi voittaa plugin-markkinapaikallaan, GUI-pohjaisella skeeman muokkauksella ja laajemmalla kehysyhteensopivuudella. Jos tiimisi kirjoittaa TypeScriptiä ja käyttää Next.js:ää, Payload on vahvempi valinta. Muuten, arvioi Strapi.

Mikä on Payloadin Local API?

Local API on palvelinpuolen kyselykerros, joka kutsuu tietokantaasi suoraan ilman HTTP-ylikulua. REST- tai GraphQL-kutsujen sijaan tuot Payloadin ja kysyt kokoelmia suoraan Next.js:n palvelinkomponenteissa. Tämä poistaa verkkoviiveet ja serialisointikustannukset, mikä johtaa nopeampaan sivun latautumiseen. Mikään muu headless-CMS ei tarjoa tätä.

Pystyykö Payload CMS käsittelemään suurten mittakaavan sovelluksia?

Payload tukee PostgreSQL:ää yhteyspoolauksella (Neonin tai PgBouncerin kautta), roolipohjaista pääsynvalvontaa kenttätason granulaarisuudella, luonnos- ja versiointityövirkauksia ja monivuokraaja-arkkitehtuureja. Enterprise-yritykset ja agentuurit käyttävät Payloadia tuotannossa sisältöpainotteisissa sovelluksissa. Local API:n nolla-ylikuluiset kyselyt itse asiassa parantavat suorituskykyä skaalautuessa.

Miten Payload vertautuu Sanityyn?

Payload on itse hostattu, koodilähtöinen ja MIT-lisensoitu Local API:lla palvelinpuolen suorituskykyä varten. Sanity on pilvihostattu, ja sillä on ylivoimainen visuaalinen muokkaus, reaaliaikainen yhteistyö ja GROQ-kyselykieli. Payload antaa sinulle enemmän infrastruktuurikontrollia ja alhaisemmat kustannukset. Sanity antaa sinulle paremmat toimitustyökalut ja nolla hosting-hallintaa.

Mitkä ovat Payload CMS:n haitat?

Payload vaatii TypeScript-tuntemusta konfigurointiin, sillä ei ole hallinnoitua pilvihostingia uusille käyttäjille Figman hankinnan jälkeen, sen plugin-ekosysteemi on pienempi kuin Strapilla, ja se on arkkitehtonisesti sidottu Next.js:ään versiossa 3. Ei-tekniset tiimit saattavat kamppailla koodilähtöisen lähestymistavan kanssa, ja Figman hankinta luo jonkin verran pitkän aikavälin epävarmuutta.