Payload CMS 2026: De ce a cumpărat Figma și ar trebui să-l adopți?

Payload CMS 2026: De ce a cumpărat Figma și ar trebui să-l adopți?

Payload este un headless CMS open-source, nativ TypeScript, care trăiește în interiorul aplicației tale Next.js, nu alături de ea, nu într-un container separat, ci literalmente în același folder /app. Dacă ai fost dezamăgit de platformele CMS găzduite care taxează per utilizator sau îți blochează conținutul în spatele unor API-uri proprietare, Payload merită o privire atentă.

Dar anul 2026 a adus o surpriză: Figma a achiziționat Payload, Payload Cloud a suspendat înscrierile noi, iar dezvoltatorii trebuie brusc să își gestioneze singuri hosting-ul. Acest ghid acoperă totul, de la prima instalare până la implementarea în producție, cu exemple de cod actuale pentru Payload 3 și opinii oneste despre punctele forte și slabe ale Payload.

Ce este Payload CMS? (Și de ce îl adoră dezvoltatorii)

Payload este un framework de aplicații și un headless CMS open-source, nativ TypeScript, care rulează în interiorul aplicației tale Next.js. Spre deosebire de platformele CMS găzduite, Payload îți oferă o configurare „code-first”, trei API-uri integrate (REST, GraphQL, Local) și un panou de administrare complet personalizabil, toate dintr-o singură bază de cod. Conform documentației oficiale Payload, este conceput pentru a fi „cea mai bună modalitate de a construi un backend modern”.

Proiectul a început în 2021 ca un CMS Node.js/Express. Payload 2 a sosit în 2023 cu suport îmbunătățit pentru TypeScript. Apoi, Payload 3 a schimbat complet regulile jocului: CMS-ul s-a mutat în interiorul aplicației tale Next.js. Niciun proces de server separat. Nicio implementare separată. CMS-ul tău și frontend-ul tău partajează același runtime Next.js, aceleași rute, aceeași pipeline de build.

Aceasta este o arhitectură genuin diferită față de ceea ce oferă Sanity, Strapi sau Contentful. Și are consecințe reale asupra modului în care construiești, implementezi și te gândești la stratul tău de conținut.

Filosofia Code-First

Majoritatea platformelor CMS îți oferă o interfață grafică (GUI) pentru a defini modelul de conținut. Dai click pe „adaugă câmp”, alegi „text”, îl numești „titlu”. Payload inversează această abordare: definești totul în fișiere TypeScript. Schema ta este cod. Aceasta trăiește în controlul versiunilor. O revizuiești în pull request-uri.

Asta înseamnă fără divergențe de schemă între medii, fără surprize de genul „cineva a modificat modelul de conținut în staging și nimeni nu știe ce s-a întâmplat”. Dacă ai lucrat într-o echipă unde modelul de conținut trăia într-un dashboard cloud, știi exact de ce contează acest aspect.

Arhitectura Payload 3, Nativa Next.js

Payload 3 nu rulează lângă aplicația ta Next.js. Rulează în interiorul ei. Panoul de administrare se află la /app/(payload)/admin, rutele tale API trăiesc în /app/(payload)/api, iar paginile frontend coexistă în același proiect. Dacă ai folosit Next.js în producție anterior, te vei simți ca acasă.

Caracteristici cheie care diferențiază Payload

Caracteristicile remarcabile ale Payload includ Colecții pentru modelarea conținutului, un strat triplu de API (REST, GraphQL, Local), controlul accesului bazat pe roluri cu granularitate la nivel de câmp, autentificare integrată, editorul de text rich Lexical și previzualizarea live pentru editarea vizuală. Iată ce înseamnă fiecare dintre acestea pentru baza ta de cod.

Colecții, Globale și Câmpuri

Colecțiile sunt primitiva de bază pentru modelarea conținutului în Payload. Gândește-te la ele ca la tabele de bază de date, dar definite integral în TypeScript. Fiecare Colecție primește propriile endpoint-uri REST și GraphQL, propria vizualizare în panoul de administrare și propriile reguli de control al accesului, toate generate dintr-un singur fișier de configurare.

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

Globalele funcționează similar, dar pentru date singleton, cum ar fi setările site-ului, configurația de navigare, conținutul footer-ului. O singură instanță, fără vizualizare listă de colecție, doar un singur document editabil.

Stratul Triplu de API (REST, GraphQL, Local)

Aici Payload întrece cu adevărat orice alt CMS open-source. Primești trei modalități de a interoga conținutul, fiecare optimizată pentru contexte diferite:

• Local API: Interogări server-side fără overhead HTTP. Sună direct la CMS-ul tău în componentele server Next.js. Fără dus-întors pe rețea, fără cost de serializare. În testele noastre, Local API a redus timpii de încărcare a paginii cu ~40ms comparativ cu apelurile REST pe același server.
• REST API: Endpoint-uri generate automat pentru clienți externi, aplicații mobile sau integrări terțe.
• GraphQL API: Interogări flexibile pentru frontend-uri care trebuie să modeleze precis cererile lor de date.

Iată cum arată un apel Local API într-o componentă server Next.js:

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

Niciun apel fetch. Niciun URL API. Niciun token de autentificare. Interoghezi direct baza de date dintr-o componentă server, iar TypeScript îți oferă siguranță deplină a tipurilor pentru răspuns. Este greu de bătut.

Controlul Accesului și Autentificarea

Sistemul de control al accesului din Payload se bazează pe funcții. În loc să configurezi permisiuni într-un dashboard, scrii funcții TypeScript care returnează true sau false. La nivel de câmp, colecție sau operațiune, tu decizi granularitatea.

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

Autentificarea vine integrată: token-uri JWT, token-uri de reîmprospătare, flux de recuperare parolă, verificare email. Nu ai nevoie de Clerk sau NextAuth decât dacă le dorești specific. Pentru multe proiecte, autentificarea Payload este mai mult decât suficientă.

Editorul de Text Rich Lexical

Payload folosește Lexical, framework-ul de text rich al Meta (aceeași echipă din spatele Draft.js, dar mai bun). Poți adăuga blocuri personalizate, elemente inline și comenzi slash. Editorul serializează într-un format JSON structurat pe care îl poți converti în HTML sau componente React.

Acest lucru contează deoarece majoritatea editorilor de text rich din CMS sunt fie prea simpli (textarea simplu), fie prea opaci (WYSIWYG care generează HTML imprevizibil). Lexical îți oferă un output structurat, predictibil, pe care îl controlezi integral.

Previzualizare Live și Editare Vizuală

Payload 3 vine cu previzualizare live: editorii văd modificările de conținut reflectate pe frontend-ul real în timp real, alături de panoul de administrare. Aceasta este o completare semnificativă față de Strapi, care nu are deloc editare vizuală.

Nu este chiar atât de rafinat precum funcțiile de colaborare în timp real din Sanity Studio; editarea vizuală a Sanity este cu adevărat cea mai bună din clasă. Dar pentru echipele care au nevoie de o previzualizare vizuală „suficient de bună” fără a plăti prețul per utilizator al Sanity, implementarea Payload își face treaba.

Versionare, Draft-uri și Salvare Automată

Payload include gestionarea draft-urilor, istoricul versiunilor și salvarea automată, funcții pe care zero dintre ghidurile Payload de top nici măcar nu le menționează. Poți activa versionarea per colecție (am făcut-o în exemplul Posts de mai sus cu versions: { drafts: true }), poți seta un număr maxim de versiuni și poți compara reviziile în UI-ul de administrare.

Pentru echipele editoriale, asta înseamnă sfârșitul dezastrelor de tip „am publicat accidental un draft”. Pentru dezvoltatori, înseamnă că nu trebuie să adaugi un sistem de versionare separat.

Începerea cu Payload CMS

Pentru a începe un nou proiect Payload, rulează npx create-payload-app@latest, selectează un șablon (website sau blank), alege adaptorul de bază de date (PostgreSQL, MongoDB sau SQLite) și vei avea un panou de administrare funcțional la localhost:3000/admin în mai puțin de două minute. Ghidul oficial de instalare acoperă cazurile limită.

Instalare

Ai nevoie de Node.js 18+ și un manager de pachete. Asta e tot.

# 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

Șablonul website este cel mai bun punct de plecare pentru majoritatea proiectelor; vine cu un blog funcțional, o colecție de pagini, încărcări media și un frontend. Șablonul blank este pentru când vrei să construiești de la zero.

Structura Proiectului

După instalare, proiectul tău arată ca o aplicație Next.js standard cu Payload integrat:

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

Fișierul payload.config.ts este inima tuturor:

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

Prima ta Colecție

Odată ce serverul de dezvoltare rulează, creează o nouă colecție adăugând un fișier în /collections. Payload generează automat UI-ul de administrare, endpoint-urile API și tipurile TypeScript din configurația ta. Iată o colecție simplă Pages:

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

Adaug-o în array-ul de colecții din payload.config.ts, repornește serverul de dezvoltare și ai un constructor de pagini complet funcțional cu o interfață vizuală de administrare. Fără plugin-uri, fără descărcări din marketplace.

Opțiuni de Bază de Date: Postgres, MongoDB și SQLite

Payload suportă trei adaptoare de bază de date: PostgreSQL (recomandat pentru producție), MongoDB (pentru modele heavy pe documente sau stack-uri Mongo existente) și SQLite (doar pentru dezvoltare locală și prototipare). Modelul de adaptor înseamnă că codul aplicației tale rămâne același indiferent de baza de date aleasă.

Dacă începi de la zero, mergi pe PostgreSQL. Gestionează mai bine datele relaționale (și majoritatea datelor CMS sunt relaționale), are opțiuni serverless excelente prin Neon și Supabase și este ceea ce recomandă echipa Payload. Verifică compararea noastră PostgreSQL vs MySQL pentru mai mult context despre why Postgres domină dezvoltarea modernă de aplicații.

Sfat pro: Dacă implementezi pe Vercel, asociază Payload cu Neon Postgres. Pooling-ul de conexiuni al Neon gestionează elegant pornirile la rece (cold starts) serverless, ceea contează deoarece Vercel lansează constant noi instanțe de funcții.

Achiziția Figma: Ce înseamnă pentru dezvoltatori

Figma a achiziționat Payload în iunie 2025. Licența MIT și baza de cod open-source rămân neschimbate. Payload Cloud a suspendat înscrierile noi în timp ce echipa construiește un înlocuitor, dar self-hosting-ul nu este afectat. Pentru dezvoltatori, cea mai mare întrebare nu este „este Payload mort?”, ci „ce fac cu hosting-ul?”.

Urmăream Payload Cloud ca opțiune de hosting pentru un proiect client când a fost anunțată achiziția. Iată ce am învățat din pivotarea către self-hosting și ce înseamnă cu adevărat achiziția pentru proiectele tale.

Pe 17 iunie 2025, Figma a anunțat achiziția pe blogul lor. Echipa Payload și-a publicat propria anunț în aceeași zi. Întreaga echipă Payload a fost absorbită în Figma.

Ce s-a schimbat (și ce nu)

Ce rămâne la fel:

• Licența MIT. Aceasta nu poate fi revocată. Repository-ul GitHub rămâne activ și deschis contribuțiilor comunității.
• Baza de cod. Payload 3 funcționează exact cum o făcea înainte de achiziție.
• Self-hosting. Poți implementa Payload oriunde, pentru totdeauna.

Ce s-a schimbat:

• Payload Cloud a suspendat înscrierile noi. Clienții existenți pot continua, dar noile proiecte nu pot folosi hosting-ul gestionat al Payload.
• Focusul echipei s-a schimbat. Echipa Payload construiește acum ceea ce va deveni probabil „Figma CMS”, făcând legătura între design-urile Figma și conținutul live. Specificațiile sunt speculative, dar direcția este clară.
• Atenția comunității. Unii dezvoltatori sunt îngrijorați de modelul „achiziționat-apoi-abandonat” care bântuie proiectele open-source. Licența MIT atenuează cel mai rău scenariu, dar este o preocupare legitimă.

Ar trebui să alegi totuși Payload?

Onest? Da, cu rezerve.

Partea bună: Resursele Figma înseamnă mai mult talent ingineresc în spatele proiectului. Licența MIT înseamnă că cel mai rău caz este să faci un fork. Baza de cod este matură, bine documentată și utilizată activ în producție de mii de proiecte.

Partea îngrijorătoare: Incentivele Figma se pot diverge de nevoile comunității open-source în timp. Lipsa Payload Cloud te obligă să gestionezi singur hosting-ul. Și dacă ești avers la risc, incertitudinea privind direcția pe termen lung este reală.

Opinia noastră: dacă te simți confortabil cu self-hosting (ceea ar trebui, nu e greu), Payload rămâne cel mai bun headless CMS open-source, code-first, disponibil. Nu aștepta „Figma CMS”. Construiește cu Payload 3 astăzi, găzduiește-l singur și mergi mai departe.

Cum să implementezi Payload CMS în 2026

Cu Payload Cloud suspendat pentru înscrieri noi, principalele tale opțiuni de implementare în 2026 sunt: Vercel (configurare cea mai rapidă, atenție la cold starts), Docker pe un VPS (cel mai bun pentru editori activi, 7-45 EUR/lună), Railway/Render/Fly.io (containere gestionate) sau Cloudflare Workers (cel mai ieftin, ~5-10 USD/lună). Conform documentației de implementare Payload, orice hosting Node.js care suportă Next.js va funcționa.

Am implementat Payload atât pe Vercel, cât și pe un VPS bazat pe Docker. Iată ce ne-a surprins: cold starts-urile Vercel au făcut panoul de administrare lent pentru editorii care se logau doar de câteva ori pe săptămână. VPS-ul, deși necesita mai multă configurare, a oferit o experiență editorială constant mai bună.

Vercel (Configurare cea mai rapidă)

Implementare one-click cu Neon Postgres și Vercel Blob pentru încărcarea fișierelor. Calea cea mai rapidă spre producție.

Pros: Zero management infrastructură, CDN excelent, grozav pentru site-uri cu activitate editorială ușoară. Cons: Cold starts panou admin (3-5 secunde după inactivitate), epuizarea conexiunilor Postgres sub interogări intense, plafonul de timeout de 10 secunde poate strica operațiunile bulk. Cel mai bun pentru: Site-uri de marketing, portofolii, bloguri cu editare rară.

Pentru mai mult context despre punctele forte și limitările Vercel, vezi compararea noastră Vercel vs Netlify.

Docker pe un VPS (Cel mai bun pentru Producție)

O configurare Docker Compose pe Hetzner, DigitalOcean sau AWS EC2. Aceasta se potrivește mai bine arhitecturii Payload decât serverless, deoarece Payload se așteaptă la un proces de server persistent.

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

Pros: Server persistent (fără cold starts), costuri predictibile (7-45 EUR/lună pe Hetzner), control total asupra stack-ului. Cons: Gestionezi serverul, SSL, backup-urile și actualizările. Cel mai bun pentru: Agenții, echipe editoriale active, setup-uri multi-tenant, aplicații cu utilizare intensă a adminului.

O comparare detaliată de hosting de la Build with Matija acoperă provideri VPS suplimentari și configurații.

Containere Gestionate (Railway, Render, Fly.io)

Dacă Docker pe un VPS sună a prea multă muncă de ops, platformele de containere gestionate reprezintă un compromis. Railway este deosebit de popular în comunitatea Payload; au un șablon Payload care se implementează printr-un singur click.

Verifică compararea noastră Railway vs Render vs Fly.io pentru o privire mai profundă asupra acestor platforme.

Cel mai bun pentru: Echipe care doresc servere persistente fără a gestiona direct infrastructura.

Cloudflare Workers (Cel mai ieftin)

Cea mai nouă opțiune. Payload a adăugat un adaptor Cloudflare Workers care rulează pe funcții edge cu D1 (SQLite) sau Hyperdrive (proxy Postgres). Încă experimental-ish, dar costul nu poate fi bătut: ~5-10 USD/lună pentru majoritatea proiectelor.

Cel mai bun pentru: Proiecte secundare, site-uri personale, implementări cu buget limitat unde ești confortabil cu infrastructuri mai noi, mai puțin testate.

Verdictul nostru: Pentru majoritatea proiectelor Payload de producție cu editori activi, Docker pe un VPS este implicitul cel mai bun. Este mai ieftin decât ai crede, elimină problemele de cold start și îți oferă control total. Folosește Vercel doar dacă editorii tăi sunt rari și vrei zero overhead de ops.

Prețuri Payload CMS: Cât costă de fapt

Payload în sine este gratuit și licențiat MIT. Costurile tale reale sunt hosting-ul și (opțional) dezvoltarea profesională. Iată cum arată cifrele în realitate, bazate pe setup-uri din lumea reală și defalcarea prețurilor de la Build with Matija.

Pentru comparație: Planul Team al Contentful începe de la 300 USD/lună. Planul Team al Sanity este 99 USD/lună per proiect. Strapi Cloud începe de la 29 USD/lună. Costul software-ului de 0 USD al Payload plus hosting-ul de 7-25 USD/lună este greu de contestat, mai ales pentru agențiile care construiesc proiecte pentru clienți unde prețurile per utilizator distrug marjele.

Payload vs Sanity vs Strapi vs Contentful: Comparatie Rapidă

Alege Payload dacă vrei control code-first și self-hosting. Alege Sanity pentru cea mai bună editare vizuală și colaborare în timp real. Alege Strapi pentru un panou admin rapid cu ecosistem de plugin-uri. Alege Contentful pentru infrastructură de nivel enterprise cu garanții SLA. Noi folosim Sanity pentru techsy.io, deci avem experiență directă în compararea acestor platforme.

Am construit proiecte bazate pe Payload pentru clienți care au nevoie de ownership-ul datelor și self-hosting, și rulăm propria noastră pipeline de conținut pe Sanity. Ambele sunt excelente; alegerea corectă depinde de confortul tehnic al echipei tale și preferințele de hosting. Dacă evaluezi opțiuni headless CMS pentru un proiect, te putem ajuta să alegi.

Pentru analize mai profunde ale fiecărei platforme, verifică ghidurile noastre: cel mai bun headless CMS în 2026 și ghiduri individuale pentru Sanity, Strapi și Contentful care vor veni în curând.

Când să NU folosești Payload CMS

Ocolește Payload dacă echipa ta este non-tehnică și are nevoie de o interfață GUI similară WordPress, dacă ai nevoie de hosting cloud gestionat instantaneu fără munca de self-hosting, dacă editorii tăi vor editare vizuală la nivelul Sanity Studio sau dacă ai nevoie de un marketplace de plugin-uri pentru expansiunea rapidă a funcționalităților. A fi onest despre limitări construiește mai multă încredere decât a pretinde că nu există.

Am recomandat împotriva Payload pentru clienții ale căror echipe editoriale aveau zero experiență TypeScript. Iată când ar trebui să cauți altundeva:

• Echipe non-tehnice. Payload necesită cunoștințe TypeScript pentru configurare. Dacă editorii clientului tău nu pot atinge codul și trebuie să modifice ei înșiși modelul de conținut, WordPress sau Sanity sunt potriviri mai bune.
• Ai nevoie de hosting gestionat chiar acum. Cu Payload Cloud suspendat pentru înscrieri noi, trebuie să faci self-host. Dacă gestionarea unui server (chiar și un setup Docker simplu) este un impediment, abordarea cloud-hosted a Contentful sau Sanity elimină acea povară.
• Colaborare editorială intensă. Colaborarea în timp real a Sanity Studio, mai mulți editori lucrând simultan pe același document cu indicatori de prezență, este mai rafinată decât orice oferă Payload. Dacă ai o echipă editorială mare, Sanity câștigă aici.
• Dezvoltare driven de plugin-uri. Strapi are un marketplace de plugin-uri mai mare. Ai nevoie de un plugin SEO, un generator sitemap, o integrare email? Probabil Strapi are unul. Ecosistemul Payload crește, dar este mai mic.
• Nu folosești Next.js. Payload 3 este legat arhitectural de Next.js. Dacă frontend-ul tău este Astro, Remix, Nuxt sau SvelteKit, cel mai mare avantaj al Payload (Local API în componentele server) nu se aplică. Ai primi totuși REST și GraphQL, dar în acel punct, Strapi sau Directus s-ar putea simți mai naturale.

Întrebări Frecvente (FAQ)

Ce este Payload CMS și cum funcționează?

Payload este un headless CMS open-source, nativ TypeScript și un framework de aplicații construit pe Next.js. Îți definești modelul de conținut în fișiere de configurare TypeScript, iar Payload generează automat un panou de administrare, API REST, API GraphQL și API Local. Rulează în interiorul aplicației tale Next.js ca o singură unitate implementabilă.

Este Payload CMS gratuit de utilizat?

Payload este complet gratuit sub licența MIT. Software-ul nu costă nimic pentru descărcare, utilizare sau modificare. Payload Cloud (hosting gestionat) costa 35-199 USD/lună, dar este momentan suspendat pentru înscrieri noi în urma achiziției de către Figma. Self-hosting-ul pe un VPS costă 7-45 EUR/lună în funcție de provider.

Ce s-a întâmplat cu Payload și Figma?

Figma a achiziționat Payload pe 17 iunie 2025. Întreaga echipă Payload s-a alăturat Figma. Licența open-source MIT și repository-ul GitHub rămân neschimbate. Payload Cloud a suspendat înscrierile noi. Self-hosting-ul continuă să funcționeze normal. Echipa construiește probabil un produs CMS integrat Figma, dar specificațiile nu au fost anunțate.

Ce bază de date folosește Payload CMS?

Payload suportă trei baze de date printr-un model de adaptor: PostgreSQL (recomandat pentru producție, funcționează cu Neon și Supabase pentru serverless), MongoDB (bun pentru modele heavy pe documente sau upgrade-uri Payload 2) și SQLite (doar dezvoltare locală și CI). Codul aplicației tale rămâne același indiferent de adaptorul ales.

Cum implementez Payload CMS în 2026?

Cu Payload Cloud suspendat, implementează pe Vercel cu Neon Postgres (cel mai ușor), Docker pe un V