Payload CMS 2026: Perché Figma l'Ha Acquisita (E Dovresti Adottarla?)

Guida a Payload CMS: Setup, API e Deployment nel 2026

Payload è un CMS headless open-source, nativo TypeScript, che vive dentro la tua app Next.js -- non accanto a essa, non in un container separato, ma letteralmente nella stessa cartella /app. Se sei mai stato penalizzato da piattaforme CMS hosted che fanno pagare per ogni utente o bloccano i contenuti dietro API proprietarie, Payload merita uno sguardo serio.

Il 2026 ha però portato una sorpresa: Figma ha acquisito Payload, Payload Cloud ha sospeso le nuove iscrizioni e gli sviluppatori si trovano improvvisamente a dover gestire l'hosting da soli. Questa guida copre tutto, dalla prima installazione al deployment in produzione, con esempi di codice aggiornati a Payload 3 e valutazioni oneste su dove Payload eccelle e dove no.

Cos'è Payload CMS? (E perché gli sviluppatori lo adorano)

Payload è un CMS headless open-source e un framework applicativo, nativo TypeScript, che gira dentro la tua app Next.js. A differenza delle piattaforme CMS hosted, Payload ti dà una configurazione code-first, tre API integrate (REST, GraphQL, Local) e un pannello admin completamente personalizzabile -- il tutto da un'unica codebase. Secondo la documentazione ufficiale di Payload, è progettato per essere "il modo migliore per costruire un backend moderno."

Il progetto è nato nel 2021 come CMS su Node.js/Express. Payload 2 è arrivato nel 2023 con un supporto TypeScript migliorato. Poi Payload 3 ha cambiato tutto: il CMS si è spostato dentro l'applicazione Next.js. Nessun processo server separato. Nessun deployment separato. Il tuo CMS e il tuo frontend condividono lo stesso runtime Next.js, le stesse route, la stessa pipeline di build.

È un'architettura genuinamente diversa da quella di Sanity, Strapi o Contentful. E ha conseguenze reali su come costruisci, fai il deploy e pensi al tuo content layer.

La filosofia code-first

La maggior parte delle piattaforme CMS ti dà una GUI per definire il tuo modello di contenuti. Clicchi "aggiungi campo", scegli "testo", lo chiami "titolo." Payload capovolge questo approccio: definisci tutto in file TypeScript. Il tuo schema è codice. Vive nel version control. Lo rivedi nelle pull request.

Questo significa niente schema drift tra ambienti, niente sorprese del tipo "qualcuno ha cambiato il modello di contenuti in staging e nessuno sa cosa è successo." Se hai lavorato in un team dove il modello di contenuti viveva in un dashboard cloud, sai esattamente perché questo è importante.

Architettura di Payload 3 -- nativo Next.js

Payload 3 non gira accanto alla tua app Next.js. Gira dentro di essa. Il pannello admin si trova in /app/(payload)/admin, le route API in /app/(payload)/api, e le tue pagine frontend coesistono nello stesso progetto. Se hai già usato Next.js in produzione, ti sentirai subito a casa.

Funzionalità chiave che distinguono Payload

Le funzionalità di punta di Payload includono le Collections per la modellazione dei contenuti, un triplo livello API (REST, GraphQL, Local), controllo degli accessi basato sui ruoli con granularità a livello di campo, autenticazione integrata, l'editor rich text Lexical e la live preview per il visual editing. Ecco cosa significa concretamente ognuna di queste per la tua codebase.

Collections, Globals e Fields

Le Collections sono la primitiva fondamentale di Payload per la modellazione dei contenuti. Pensale come tabelle di database, ma definite interamente in TypeScript. Ogni Collection ottiene i propri endpoint REST e GraphQL, la propria vista nel pannello admin e le proprie regole di controllo accessi -- tutto generato da un singolo file di configurazione.

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

I Globals funzionano in modo simile ma per dati singleton -- le impostazioni del sito, la configurazione della navigazione, il contenuto del footer. Un'unica istanza, nessuna vista a lista, solo un singolo documento modificabile.

Il triplo livello API (REST, GraphQL, Local)

Qui Payload supera davvero ogni altro CMS open-source. Hai tre modi per interrogare i tuoi contenuti, ognuno ottimizzato per contesti diversi:

• Local API: query lato server con zero overhead HTTP. Chiama il tuo CMS direttamente nei server component di Next.js. Nessun round-trip di rete, nessun costo di serializzazione. Nei nostri test, la Local API ha ridotto i tempi di caricamento delle pagine di circa 40ms rispetto alle chiamate REST sullo stesso server.
• REST API: endpoint generati automaticamente per client esterni, app mobile o integrazioni di terze parti.
• GraphQL API: query flessibili per frontend che devono modellare con precisione le richieste di dati.

Ecco come appare una chiamata alla Local API in un server component di 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>
}

Nessuna chiamata fetch. Nessun URL API. Nessun token di autenticazione. Stai interrogando il tuo database direttamente da un server component, e TypeScript ti garantisce la type safety completa sulla risposta. Difficile fare di meglio.

Controllo degli accessi e autenticazione

Il sistema di controllo degli accessi di Payload è basato su funzioni. Invece di configurare i permessi in un dashboard, scrivi funzioni TypeScript che restituiscono true o false. A livello di campo, di collection o di operazione -- tu decidi la granularità.

// Esempio: solo i post pubblicati sono leggibili pubblicamente
access: {
  read: ({ req }) => {
    if (req.user) return true // Gli utenti loggati vedono tutto
    return { status: { equals: 'published' } } // Il pubblico vede solo i pubblicati
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

L'autenticazione è integrata: JWT token, refresh token, flusso "password dimenticata," verifica email. Non hai bisogno di Clerk o NextAuth, a meno che non li voglia specificamente. Per molti progetti, il sistema auth di Payload è più che sufficiente.

Editor rich text Lexical

Payload usa Lexical, il framework rich text di Meta (lo stesso team dietro Draft.js, ma migliore). Puoi aggiungere blocchi personalizzati, elementi inline e slash command. L'editor serializza in un formato JSON strutturato che puoi convertire in HTML o componenti React.

Questo è importante perché la maggior parte degli editor rich text dei CMS è o troppo basilare (semplice textarea) o troppo opaca (WYSIWYG che genera HTML imprevedibile). Lexical ti dà un output strutturato e prevedibile che controlli completamente.

Live Preview e visual editing

Payload 3 include la live preview: gli editor vedono le modifiche ai contenuti riflesse sul frontend reale in tempo reale, fianco a fianco con il pannello admin. Colma una lacuna significativa rispetto a Strapi, che non ha alcun visual editing.

Non è raffinata quanto le funzionalità di collaborazione in tempo reale di Sanity Studio -- il visual editing di Sanity è genuinamente il migliore della categoria. Ma per i team che hanno bisogno di una preview visiva "sufficientemente buona" senza pagare i prezzi per seat di Sanity, l'implementazione di Payload funziona.

Versioni, bozze e salvataggio automatico

Payload include gestione integrata delle bozze, cronologia delle versioni e salvataggio automatico -- funzionalità che nessuna delle guide Payload più visibili menziona nemmeno. Puoi abilitare il versioning per collection (l'abbiamo fatto nell'esempio Posts sopra con versions: { drafts: true }), impostare un numero massimo di versioni e confrontare le revisioni nell'interfaccia admin.

Per i team editoriali, questo significa niente più disastri del tipo "ho pubblicato accidentalmente una bozza." Per gli sviluppatori, significa che non devi aggiungere un sistema di versioning separato.

Iniziare con Payload CMS

Per avviare un nuovo progetto Payload, esegui npx create-payload-app@latest, seleziona un template (website o blank), scegli il tuo database adapter (PostgreSQL, MongoDB o SQLite), e avrai un pannello admin funzionante su localhost:3000/admin in meno di due minuti. La guida ufficiale all'installazione copre i casi limite.

Installazione

Hai bisogno di Node.js 18+ e un package manager. Nient'altro.

# Crea un nuovo progetto Payload
npx create-payload-app@latest my-cms

# La CLI ti chiede:
# - Nome del progetto
# - Template (website, blank, e-commerce)
# - Database (postgres, mongodb, sqlite)

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

Il template website è il punto di partenza migliore per la maggior parte dei progetti -- include un blog funzionante, una collection di pagine, upload di media e un frontend. Il template blank è per quando vuoi costruire da zero.

Struttura del progetto

Dopo l'installazione, il tuo progetto appare come una normale app Next.js con Payload integrato:

my-cms/
  app/
    (frontend)/          # Le pagine del tuo sito
    (payload)/
      admin/             # Route del pannello admin (auto-generate)
      api/               # Endpoint REST + GraphQL
  collections/           # Le definizioni del tuo modello di contenuti
  globals/               # Contenuti singleton (impostazioni, nav)
  payload.config.ts      # Configurazione principale di Payload
  payload-types.ts       # Tipi TypeScript auto-generati

Il file payload.config.ts è il cuore di tutto:

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

La tua prima Collection

Una volta avviato il server di sviluppo, crea una nuova collection aggiungendo un file in /collections. Payload genera automaticamente l'interfaccia admin, gli endpoint API e i tipi TypeScript dalla tua configurazione. Ecco una semplice collection di Pagine:

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

Aggiungila all'array collections del tuo payload.config.ts, riavvia il server di sviluppo, e hai un page builder completamente funzionale con un'interfaccia admin visiva. Nessun plugin, nessun download dal marketplace.

Opzioni di database -- Postgres, MongoDB e SQLite

Payload supporta tre database adapter: PostgreSQL (consigliato per la produzione), MongoDB (per modelli document-heavy o stack Mongo esistenti) e SQLite (solo per sviluppo locale e prototipazione). Il pattern adapter significa che il codice della tua applicazione rimane invariato indipendentemente dal database che scegli.

Se stai partendo da zero, scegli PostgreSQL. Gestisce meglio i dati relazionali (e la maggior parte dei dati CMS è relazionale), ha ottime opzioni serverless tramite Neon e Supabase, ed è quello che il team di Payload raccomanda. Dai un'occhiata al nostro confronto PostgreSQL vs MySQL per capire meglio perché Postgres domina lo sviluppo moderno.

Consiglio pro: Se fai il deploy su Vercel, abbina Payload a Neon Postgres. Il connection pooling di Neon gestisce i cold start serverless in modo elegante -- e questo conta, perché Vercel crea continuamente nuove istanze di function.

L'acquisizione da parte di Figma -- cosa significa per gli sviluppatori

Figma ha acquisito Payload nel giugno 2025. La licenza MIT e la codebase open-source rimangono invariate. Payload Cloud ha sospeso le nuove iscrizioni mentre il team costruisce un sostituto, ma il self-hosting non è interessato. Per gli sviluppatori, la domanda più importante non è "Payload è morto?" -- è "cosa faccio per l'hosting?"

Stavamo valutando Payload Cloud come opzione di hosting per un progetto cliente quando è stata annunciata l'acquisizione. Ecco cosa abbiamo imparato dal passaggio al self-hosting, e cosa significa davvero l'acquisizione per i tuoi progetti.

Il 17 giugno 2025, Figma ha annunciato l'acquisizione sul proprio blog. Il team di Payload ha pubblicato il proprio annuncio lo stesso giorno. L'intero team di Payload è stato assorbito in Figma.

Cosa è cambiato (e cosa no)

Cosa rimane invariato:

• Licenza MIT. Non può essere revocata. Il repository GitHub rimane attivo e aperto ai contributi della community.
• La codebase. Payload 3 funziona esattamente come prima dell'acquisizione.
• Il self-hosting. Puoi fare il deploy di Payload ovunque, per sempre.

Cosa è cambiato:

• Payload Cloud ha sospeso le nuove iscrizioni. I clienti esistenti possono continuare, ma i nuovi progetti non possono usare l'hosting gestito di Payload.
• Il focus del team si è spostato. Il team di Payload sta ora costruendo quello che diventerà probabilmente "Figma CMS" -- colmando il divario tra i design di Figma e i contenuti live. I dettagli sono speculativi, ma la direzione è chiara.
• L'attenzione della community. Alcuni sviluppatori temono il pattern "acquisito e poi abbandonato" che affligge i progetti open-source. La licenza MIT mitiga lo scenario peggiore, ma è una preoccupazione legittima.

Dovresti ancora scegliere Payload?

Onestamente? Sì, con qualche riserva.

Il lato positivo: le risorse di Figma significano più talenti ingegneristici dietro il progetto. La licenza MIT significa che nel peggiore dei casi puoi farne un fork. La codebase è matura, ben documentata e usata attivamente in produzione da migliaia di progetti.

Il lato preoccupante: gli incentivi di Figma potrebbero divergere dai bisogni della community open-source nel tempo. Il vuoto di Payload Cloud ti obbliga a gestire l'hosting da solo. E se sei avverso al rischio, l'incertezza sulla direzione a lungo termine è reale.

La nostra posizione: se sei a tuo agio con il self-hosting (e dovresti esserlo -- non è difficile), Payload rimane il miglior CMS headless open-source e code-first disponibile. Non aspettare "Figma CMS." Costruisci con Payload 3 oggi, fai il self-hosting e vai avanti.

Come fare il deploy di Payload CMS nel 2026

Con Payload Cloud in pausa per le nuove iscrizioni, le principali opzioni di deployment nel 2026 sono: Vercel (setup più rapido, attenzione ai cold start), Docker su un VPS (migliore per gli editor attivi, EUR 7-45/mese), Railway/Render/Fly.io (container gestiti), o Cloudflare Workers (il più economico, ~$5-10/mese). Secondo la documentazione di deployment di Payload, qualsiasi hosting Node.js che supporta Next.js funzionerà.

Abbiamo fatto il deploy di Payload sia su Vercel che su un VPS Docker. Ecco cosa ci ha sorpreso: i cold start di Vercel rendevano il pannello admin lento per gli editor che si collegavano solo poche volte a settimana. Il VPS, nonostante richiedesse più configurazione, offriva un'esperienza editoriale costantemente migliore.

Vercel (setup più rapido)

Deploy con un click con Neon Postgres e Vercel Blob per gli upload di file. Il percorso più rapido verso la produzione.

Pro: Nessuna gestione dell'infrastruttura, CDN eccellente, ottimo per siti con attività editoriale leggera. Contro: Cold start del pannello admin (3-5 secondi dopo inattività), esaurimento delle connessioni Postgres sotto query intensive, un limite di timeout di 10 secondi può bloccare le operazioni batch. Ideale per: Siti marketing, portfolio, blog con editing poco frequente.

Per più contesto sui punti di forza e sui limiti di Vercel, guarda il nostro confronto Vercel vs Netlify.

Docker su un VPS (migliore per la produzione)

Un setup Docker Compose su Hetzner, DigitalOcean o AWS EC2. Si adatta meglio all'architettura di Payload rispetto al serverless, perché Payload si aspetta un processo server persistente.

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

Pro: Server persistente (nessun cold start), costi prevedibili (EUR 7-45/mese su Hetzner), controllo completo sullo stack. Contro: Gestisci tu server, SSL, backup e aggiornamenti. Ideale per: Agenzie, team editoriali attivi, setup multi-tenant, app con uso intensivo dell'admin.

Un confronto dettagliato sull'hosting di Build with Matija copre ulteriori provider VPS e configurazioni.

Container gestiti (Railway, Render, Fly.io)

Se Docker su un VPS sembra troppo lavoro ops, le piattaforme container gestite sono una via di mezzo. Railway è particolarmente popolare nella community Payload -- hanno un template Payload che fa il deploy con un click.

Guarda il nostro confronto Railway vs Render vs Fly.io per un'analisi più approfondita di queste piattaforme.

Ideale per: Team che vogliono server persistenti senza gestire l'infrastruttura direttamente.

Cloudflare Workers (il più economico)

L'opzione più recente. Payload ha aggiunto un adapter per Cloudflare Workers che gira su edge function con D1 (SQLite) o Hyperdrive (proxy Postgres). Ancora un po' sperimentale, ma il costo è imbattibile: ~$5-10/mese per la maggior parte dei progetti.

Ideale per: Progetti personali, siti personali, deploy a basso budget dove sei a tuo agio con un'infrastruttura più recente e meno testata.

Il nostro verdetto: Per la maggior parte dei progetti Payload in produzione con editor attivi, Docker su un VPS è il default migliore. È più economico di quanto pensi, elimina i problemi di cold start e ti dà il controllo completo. Usa Vercel solo se i tuoi editor sono poco frequenti e vuoi zero overhead operativo.

Prezzi di Payload CMS -- quanto costa davvero

Payload in sé è gratuito e con licenza MIT. I costi reali sono l'hosting e (facoltativamente) lo sviluppo professionale. Ecco come stanno i numeri, basandosi su setup reali e sul breakdown dei prezzi di Build with Matija.

Per confronto: il piano Team di Contentful parte da $300/mese. Il piano Team di Sanity è $99/mese per progetto. Strapi Cloud parte da $29/mese. Il software a $0 di Payload più $7-25/mese di hosting è difficile da battere -- specialmente per le agenzie che costruiscono progetti per clienti dove i prezzi per seat erodono i margini.

Payload vs Sanity vs Strapi vs Contentful -- confronto rapido

Scegli Payload se vuoi controllo code-first e self-hosting. Scegli Sanity per il miglior visual editing e la collaborazione in tempo reale. Scegli Strapi per un pannello admin rapido con ecosistema di plugin. Scegli Contentful per un'infrastruttura enterprise-grade con garanzie SLA. Usiamo Sanity per techsy.io, quindi abbiamo un'esperienza diretta nel confrontare queste piattaforme.

Abbiamo costruito progetti basati su Payload per clienti che hanno bisogno di data ownership e self-hosting, e gestiamo la nostra pipeline di contenuti su Sanity. Entrambi sono eccellenti -- la scelta giusta dipende dalla competenza tecnica del tuo team e dalle preferenze di hosting. Se stai valutando opzioni di CMS headless per un progetto, possiamo aiutarti a scegliere.

Per analisi più approfondite su ogni piattaforma, guarda le nostre guide: i migliori CMS headless nel 2026, e guide individuali per Sanity, Strapi e Contentful in arrivo.

Quando NON usare Payload CMS

Evita Payload se il tuo team è non tecnico e ha bisogno di una GUI simile a WordPress, se hai bisogno di hosting cloud gestito senza lavoro di self-hosting, se i tuoi editor vogliono un visual editing al livello di Sanity Studio, o se hai bisogno di un marketplace di plugin per espandere rapidamente le funzionalità. Essere onesti sui limiti crea più fiducia che far finta che non esistano.

Abbiamo sconsigliato Payload per clienti i cui team editoriali non avevano esperienza TypeScript. Ecco quando dovresti cercare altro:

• Team non tecnici. Payload richiede conoscenza di TypeScript per la configurazione. Se i tuoi editor non possono toccare il codice e hanno bisogno di modificare il modello di contenuti da soli, WordPress o Sanity sono più adatti.
• Hai bisogno di hosting gestito adesso. Con Payload Cloud in pausa per le nuove iscrizioni, devi fare il self-hosting. Se gestire un server (anche un semplice setup Docker) è un ostacolo insormontabile, l'approccio cloud-hosted di Contentful o Sanity elimina quel peso.
• Collaborazione editoriale intensa. La collaborazione in tempo reale di Sanity Studio -- più editor che lavorano sullo stesso documento simultaneamente con indicatori di presenza -- è più rifinita di quanto Payload offra. Se hai un grande team editoriale, Sanity vince qui.
• Sviluppo guidato dai plugin. Strapi ha un marketplace di plugin più ampio. Hai bisogno di un plugin SEO, un generatore di sitemap, un'integrazione email? Strapi probabilmente ce l'ha. L'ecosistema di Payload sta crescendo, ma è più piccolo.
• Non stai usando Next.js. Payload 3 è architetturalmente legato a Next.js. Se il tuo frontend è Astro, Remix, Nuxt o SvelteKit, il principale vantaggio di Payload (la Local API nei server component) non si applica. Avresti comunque REST e GraphQL, ma a quel punto Strapi o Directus potrebbero sembrare più naturali.

FAQ

Cos'è Payload CMS e come funziona?

Payload è un CMS headless open-source e framework applicativo nativo TypeScript, costruito su Next.js. Definisci il tuo modello di contenuti in file di configurazione TypeScript, e Payload genera automaticamente un pannello admin, REST API, GraphQL API e Local API. Gira dentro la tua app Next.js come un'unica unità deployabile.

Payload CMS è gratuito?

Payload è completamente gratuito con licenza MIT. Il software non costa nulla da scaricare, usare o modificare. Payload Cloud (hosting gestito) era $35-199/mese ma è attualmente in pausa per le nuove iscrizioni dopo l'acquisizione da parte di Figma. Il self-hosting su un VPS costa EUR 7-45/mese a seconda del provider.

Cosa è successo tra Payload e Figma?

Figma ha acquisito Payload il 17 giugno 2025. L'intero team di Payload è entrato in Figma. La licenza MIT open-source e il repository GitHub rimangono invariati. Payload Cloud ha sospeso le nuove iscrizioni. Il self-hosting continua a funzionare normalmente. Il team sta probabilmente costruendo un prodotto CMS integrato con Figma, ma i dettagli non sono ancora stati annunciati.

Quale database usa Payload CMS?

Payload supporta tre database tramite un pattern adapter: PostgreSQL (consigliato per la produzione, funziona con Neon e Supabase per il serverless), MongoDB (ottimo per modelli document-heavy o upgrade da Payload 2) e SQLite (solo per sviluppo locale e CI). Il codice dell'applicazione rimane lo stesso indipendentemente dall'adapter scelto.

Come faccio il deploy di Payload CMS nel 2026?

Con Payload Cloud in pausa, fai il deploy su Vercel con Neon Postgres (il più semplice), Docker su un VPS come Hetzner (il migliore per la produzione con editor attivi), Railway o Render (container gestiti), oppure Cloudflare Workers (il più economico). Per la maggior parte dei siti in produzione con attività editoriale regolare, un VPS Docker offre l'esperienza migliore.

Payload CMS è meglio di Strapi?

Payload vince sull'esperienza developer nativa TypeScript, l'integrazione con Next.js e la Local API unica per query lato server senza overhead. Strapi vince sul marketplace di plugin, l'editing dello schema tramite GUI e la compatibilità con un maggior numero di framework. Se il tuo team scrive TypeScript e usa Next.js, Payload è la scelta più forte. Altrimenti, valuta Strapi.

Cos'è la Local API di Payload?

La Local API è un livello di query lato server che interroga il database direttamente con zero overhead HTTP. Invece di fare chiamate REST o GraphQL, importi Payload e interroghi le collection direttamente nei server component di Next.js. Questo elimina i round-trip di rete e i costi di serializzazione, risultando in pagine più veloci. Nessun altro CMS headless offre questo.

Payload CMS può gestire applicazioni su larga scala?

Payload supporta PostgreSQL con connection pooling (via Neon o PgBouncer), controllo degli accessi basato sui ruoli con granularità a livello di campo, workflow di bozze e versioning, e architetture multi-tenant. Agenzie e grandi aziende usano Payload in produzione per applicazioni content-heavy. Le query a zero overhead della Local API migliorano effettivamente le prestazioni su larga scala.

Come si confronta Payload con Sanity?

Payload è self-hosted, code-first e con licenza MIT, con una Local API per le prestazioni lato server. Sanity è cloud-hosted con visual editing superiore, collaborazione in tempo reale e il linguaggio di query GROQ. Payload ti dà più controllo sull'infrastruttura e costi inferiori. Sanity ti dà strumenti editoriali migliori e nessuna gestione dell'hosting.

Quali sono gli svantaggi di Payload CMS?

Payload richiede conoscenza di TypeScript per la configurazione, non ha hosting cloud gestito per i nuovi utenti dopo l'acquisizione di Figma, offre un ecosistema di plugin più piccolo rispetto a Strapi ed è architetturalmente legato a Next.js nella versione 3. I team non tecnici possono avere difficoltà con l'approccio code-first, e l'acquisizione da parte di Figma crea qualche incertezza a lungo termine.