Payload CMS 2026: por qué Figma lo compró — ¿y debería adoptarlo tu equipo?

Payload es un CMS headless de código abierto, nativo en TypeScript, que vive dentro de tu aplicación Next.js — no al lado, no en un contenedor separado, sino literalmente en la misma carpeta /app. Si te han quemado plataformas CMS alojadas que cobran por usuario o encierran tu contenido detrás de APIs propietarias, Payload merece una mirada seria.

Pero 2026 trajo una sorpresa: Figma adquirió Payload, Payload Cloud pausó nuevos registros, y los desarrolladores de repente tienen que resolver el alojamiento por su cuenta. Esta guía cubre todo, desde la primera instalación hasta el despliegue en producción, con ejemplos de código actuales de Payload 3 y una valoración honesta de dónde brilla Payload y dónde no.

¿Qué Es Payload CMS? (Y Por Qué Los Desarrolladores Lo Aman)

Payload es un CMS headless y framework de aplicaciones de código abierto, nativo en TypeScript, que se ejecuta dentro de tu app de Next.js. A diferencia de las plataformas CMS alojadas, Payload te da una configuración code-first, tres APIs integradas (REST, GraphQL, Local) y un panel de administración completamente personalizable — todo desde una única base de código. Según la documentación oficial de Payload, está diseñado para ser "la mejor forma de construir un backend moderno".

El proyecto comenzó en 2021 como un CMS de Node.js/Express. Payload 2 llegó en 2023 con mejor soporte para TypeScript. Luego Payload 3 cambió las reglas del juego: el CMS se trasladó al interior de tu aplicación Next.js. Sin proceso de servidor separado. Sin despliegue independiente. Tu CMS y tu frontend comparten el mismo runtime de Next.js, las mismas rutas, el mismo pipeline de build.

Es una arquitectura genuinamente diferente a lo que ofrecen Sanity, Strapi o Contentful. Y tiene consecuencias reales en cómo construyes, despliegas y piensas en tu capa de contenido.

La Filosofía Code-First

La mayoría de las plataformas CMS te dan una interfaz gráfica para definir tu modelo de contenido. Haces clic en "añadir campo", eliges "texto", lo llamas "título". Payload invierte esto: defines todo en archivos TypeScript. Tu esquema es código. Vive en control de versiones. Lo revisas en pull requests.

Esto significa que no hay divergencia de esquemas entre entornos, ni sorpresas del tipo "alguien cambió el modelo de contenido en staging y nadie sabe qué pasó". Si has trabajado en un equipo donde el modelo de contenido vivía en un panel en la nube, sabes exactamente por qué esto importa.

Arquitectura de Payload 3 — Nativo en Next.js

Payload 3 no corre junto a tu app de Next.js. Corre dentro de ella. El panel de administración está en /app/(payload)/admin, tus rutas de API viven en /app/(payload)/api, y tus páginas frontend coexisten en el mismo proyecto. Si ya usaste Next.js en producción, te sentirás como en casa.

Características Clave Que Distinguen a Payload

Las características destacadas de Payload incluyen Collections para modelado de contenido, una triple capa de API (REST, GraphQL, Local), control de acceso basado en roles con granularidad a nivel de campo, autenticación integrada, el editor de texto enriquecido Lexical y vista previa en vivo para edición visual. Aquí lo que cada una significa en la práctica para tu base de código.

Collections, Globals y Campos

Las Collections son el primitivo central de modelado de contenido en Payload. Piénsalas como tablas de base de datos, pero definidas completamente en TypeScript. Cada Collection obtiene sus propios endpoints REST y GraphQL, su propia vista en el panel de administración y sus propias reglas de control de acceso — todo generado desde un único archivo de configuración.

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

Los Globals funcionan de forma similar, pero para datos singleton — la configuración de tu sitio, la navegación, el contenido del pie de página. Una sola instancia, sin vista de lista, solo un documento editable.

La Triple Capa de API (REST, GraphQL, Local)

Aquí es donde Payload supera genuinamente a cualquier otro CMS de código abierto. Tienes tres formas de consultar tu contenido, cada una optimizada para contextos distintos:

• Local API: Consultas en el lado servidor con cero overhead HTTP. Llama a tu CMS directamente en los componentes de servidor de Next.js. Sin viaje de red, sin coste de serialización. En nuestras pruebas, la Local API redujo los tiempos de carga de página en ~40ms respecto a las llamadas REST en el mismo servidor.
• REST API: Endpoints generados automáticamente para clientes externos, aplicaciones móviles o integraciones de terceros.
• GraphQL API: Consultas flexibles para frontends que necesitan moldear sus peticiones de datos con precisión.

Así es como se ve una llamada a la Local API en un componente de servidor de 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>
}

Sin llamada fetch. Sin URL de API. Sin token de autenticación. Consultas directas a tu base de datos desde un componente de servidor, y TypeScript te da seguridad de tipos completa en la respuesta. Es difícil superarlo.

Control de Acceso y Autenticación

El sistema de control de acceso de Payload está basado en funciones. En lugar de configurar permisos en un panel, escribes funciones TypeScript que devuelven true o false. A nivel de campo, de collection o de operación — tú decides la granularidad.

// Ejemplo: Solo los posts publicados son legibles públicamente
access: {
  read: ({ req }) => {
    if (req.user) return true // Los usuarios conectados ven todo
    return { status: { equals: 'published' } } // El público solo ve publicados
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

La autenticación viene integrada: tokens JWT, refresh tokens, flujo de recuperación de contraseña, verificación de email. No necesitas Clerk ni NextAuth a menos que los quieras específicamente. Para muchos proyectos, la auth de Payload es más que suficiente.

Editor de Texto Enriquecido Lexical

Payload usa Lexical, el framework de texto enriquecido de Meta (el mismo equipo detrás de Draft.js, pero mejor). Puedes añadir bloques personalizados, elementos en línea y comandos slash. El editor serializa a un formato JSON estructurado que puedes convertir a HTML o componentes React.

Esto importa porque la mayoría de los editores de texto enriquecido de CMS son o demasiado básicos (textarea simple) o demasiado opacos (WYSIWYG que genera HTML impredecible). Lexical te da una salida estructurada y predecible que controlas completamente.

Vista Previa en Vivo y Edición Visual

Payload 3 incluye vista previa en vivo: los editores ven sus cambios de contenido reflejados en el frontend real en tiempo real, junto al panel de administración. Es un relleno de brecha significativo respecto a Strapi, que no tiene edición visual en absoluto.

No está tan pulido como las funciones de colaboración en tiempo real de Sanity Studio — la edición visual de Sanity es genuinamente la mejor en su clase. Pero para equipos que necesitan una vista previa visual "suficientemente buena" sin pagar los precios por usuario de Sanity, la implementación de Payload hace el trabajo.

Versionado, Borradores y Autoguardado

Payload incluye gestión integrada de borradores, historial de versiones y autoguardado — características que ninguna de las principales guías sobre Payload siquiera menciona. Puedes habilitar el versionado por collection (lo hicimos en el ejemplo de Posts con versions: { drafts: true }), establecer un conteo máximo de versiones y comparar revisiones en la interfaz de administración.

Para equipos editoriales, esto significa que se acabaron los desastres de "publiqué un borrador por accidente". Para los desarrolladores, significa que no necesitas agregar un sistema de versionado separado.

Primeros Pasos con Payload CMS

Para comenzar un nuevo proyecto Payload, ejecuta npx create-payload-app@latest, selecciona una plantilla (website o en blanco), elige tu adaptador de base de datos (PostgreSQL, MongoDB o SQLite), y tendrás un panel de administración funcional en localhost:3000/admin en menos de dos minutos. La guía oficial de instalación cubre los casos especiales.

Instalación

Necesitas Node.js 18+ y un gestor de paquetes. Eso es todo.

# Crear un nuevo proyecto Payload
npx create-payload-app@latest my-cms

# El CLI te pregunta:
# - Nombre del proyecto
# - Plantilla (website, blank, e-commerce)
# - Base de datos (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Panel de administración: http://localhost:3000/admin

La plantilla website es el mejor punto de partida para la mayoría de proyectos — incluye un blog funcional, una collection de páginas, subida de archivos multimedia y un frontend. La plantilla en blanco es para cuando quieres construir desde cero.

Estructura del Proyecto

Después de la instalación, tu proyecto parece una app Next.js estándar con Payload integrado:

my-cms/
  app/
    (frontend)/          # Las páginas de tu sitio web
    (payload)/
      admin/             # Rutas del panel de administración (auto-generadas)
      api/               # Endpoints REST + GraphQL
  collections/           # Tus definiciones de modelo de contenido
  globals/               # Contenido singleton (configuración, nav)
  payload.config.ts      # Configuración principal de Payload
  payload-types.ts       # Tipos TypeScript generados automáticamente

El archivo payload.config.ts es el corazón de todo:

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

Tu Primera Collection

Una vez que el servidor de desarrollo está en marcha, crea una nueva collection añadiendo un archivo a /collections. Payload genera automáticamente la interfaz de administración, los endpoints de API y los tipos TypeScript a partir de tu configuración. Aquí una collection de Pages sencilla:

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

Agrégala al array de collections en payload.config.ts, reinicia el servidor de desarrollo y tendrás un constructor de páginas completamente funcional con una interfaz de administración visual. Sin plugins, sin descargas del marketplace.

Opciones de Base de Datos — Postgres, MongoDB y SQLite

Payload soporta tres adaptadores de base de datos: PostgreSQL (recomendado para producción), MongoDB (para modelos orientados a documentos o stacks Mongo existentes) y SQLite (solo para desarrollo local y prototipos). El patrón de adaptadores significa que el código de tu aplicación permanece igual independientemente de la base de datos que elijas.

Si empiezas de cero, ve con PostgreSQL. Maneja mejor los datos relacionales (y la mayoría de datos de CMS son relacionales), tiene excelentes opciones serverless a través de Neon y Supabase, y es lo que recomienda el equipo de Payload. Consulta nuestra comparación de PostgreSQL vs MySQL para más contexto sobre por qué Postgres domina el desarrollo de aplicaciones modernas.

Consejo pro: Si despliegas en Vercel, combina Payload con Neon Postgres. El connection pooling de Neon maneja los cold starts serverless con elegancia, lo que importa porque Vercel levanta nuevas instancias de función constantemente.

La Adquisición por Figma — Qué Significa para los Desarrolladores

Figma adquirió Payload en junio de 2025. La licencia MIT y la base de código open-source permanecen sin cambios. Payload Cloud pausó nuevos registros mientras el equipo construye un reemplazo, pero el auto-alojamiento no está afectado. Para los desarrolladores, la pregunta más importante no es "¿está muerto Payload?" — sino "¿qué hago con el alojamiento?"

Estábamos rastreando Payload Cloud como opción de alojamiento para un proyecto de cliente cuando se anunció la adquisición. Aquí lo que aprendimos al pivotar al auto-alojamiento, y lo que la adquisición significa realmente para tus proyectos.

El 17 de junio de 2025, Figma anunció la adquisición en su blog. El equipo de Payload publicó su propio anuncio el mismo día. Todo el equipo de Payload fue absorbido por Figma.

Qué Cambió (Y Qué No)

Lo que sigue igual:

• Licencia MIT. Esto no se puede revocar. El repositorio de GitHub sigue activo y abierto a contribuciones de la comunidad.
• La base de código. Payload 3 funciona exactamente igual que antes de la adquisición.
• El auto-alojamiento. Puedes desplegar Payload en cualquier lugar, para siempre.

Lo que cambió:

• Payload Cloud pausó nuevos registros. Los clientes existentes pueden continuar, pero los proyectos nuevos no pueden usar el alojamiento gestionado de Payload.
• El foco del equipo cambió. El equipo de Payload ahora está construyendo lo que probablemente se convierta en "Figma CMS" — cerrando la brecha entre los diseños de Figma y el contenido en vivo. Los detalles son especulativos, pero la dirección es clara.
• La atención de la comunidad. Algunos desarrolladores se preocupan por el patrón de "adquirido y luego abandonado" que afecta a los proyectos open-source. La licencia MIT mitiga el peor escenario posible, pero es una preocupación legítima.

¿Deberías Seguir Eligiendo Payload?

Honestamente, sí, con matices.

Lo positivo: los recursos de Figma significan más talento de ingeniería detrás del proyecto. La licencia MIT significa que en el peor caso puedes hacer un fork. La base de código es madura, bien documentada y usada activamente en producción por miles de proyectos.

Lo preocupante: los incentivos de Figma pueden divergir de las necesidades de la comunidad open-source con el tiempo. La brecha de Payload Cloud te obliga a gestionar el alojamiento tú mismo. Y si eres averso al riesgo, la incertidumbre sobre la dirección a largo plazo es real.

Nuestra valoración: si estás cómodo con el auto-alojamiento (que deberías estarlo — no es difícil), Payload sigue siendo el mejor CMS headless code-first de código abierto disponible. No esperes a "Figma CMS". Construye con Payload 3 hoy, auto-alójalo y sigue adelante.

Cómo Desplegar Payload CMS en 2026

Con Payload Cloud pausado para nuevos registros, tus principales opciones de despliegue en 2026 son: Vercel (configuración más rápida, ojo con los cold starts), Docker en un VPS (mejor para editores activos, EUR 7-45/mes), Railway/Render/Fly.io (contenedores gestionados) o Cloudflare Workers (lo más económico, ~$5-10/mes). Según la documentación de despliegue de Payload, cualquier alojamiento Node.js que soporte Next.js funcionará.

Hemos desplegado Payload tanto en Vercel como en un VPS basado en Docker. Aquí lo que nos sorprendió: los cold starts de Vercel hacían que el panel de administración fuera lento para editores que solo iniciaban sesión unas pocas veces por semana. El VPS, a pesar de requerir más configuración, proporcionó una experiencia editorial consistentemente mejor.

Vercel (Configuración Más Rápida)

Despliegue con un clic con Neon Postgres y Vercel Blob para la subida de archivos. El camino más rápido a producción.

Ventajas: Cero gestión de infraestructura, excelente CDN, ideal para sitios con actividad editorial ligera. Desventajas: Cold starts del panel de administración (3-5 segundos tras inactividad), agotamiento de conexiones de Postgres bajo consultas pesadas, límite de tiempo de 10 segundos que puede romper operaciones masivas. Mejor para: Sitios de marketing, portfolios, blogs con edición poco frecuente.

Para más contexto sobre las fortalezas y limitaciones de Vercel, consulta nuestra comparación de Vercel vs Netlify.

Docker en un VPS (Mejor para Producción)

Una configuración Docker Compose en Hetzner, DigitalOcean o AWS EC2. Esto encaja mejor con la arquitectura de Payload que serverless, porque Payload espera un proceso de servidor 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:

Ventajas: Servidor persistente (sin cold starts), costes predecibles (EUR 7-45/mes en Hetzner), control total sobre el stack. Desventajas: Gestionas el servidor, SSL, copias de seguridad y actualizaciones. Mejor para: Agencias, equipos editoriales activos, configuraciones multi-tenant, apps con uso intensivo del panel de administración.

Una comparación de alojamiento detallada de Build with Matija cubre proveedores VPS adicionales y configuraciones.

Contenedores Gestionados (Railway, Render, Fly.io)

Si Docker en un VPS te parece demasiado trabajo de operaciones, las plataformas de contenedores gestionados ofrecen un término medio. Railway es especialmente popular en la comunidad de Payload — tienen una plantilla para Payload que despliega con un clic.

Consulta nuestra comparación de Railway vs Render vs Fly.io para un análisis más profundo de estas plataformas.

Mejor para: Equipos que quieren servidores persistentes sin gestionar infraestructura directamente.

Cloudflare Workers (Lo Más Económico)

La opción más reciente. Payload añadió un adaptador para Cloudflare Workers que se ejecuta en funciones edge con D1 (SQLite) o Hyperdrive (proxy de Postgres). Todavía algo experimental, pero el coste es imbatible: ~$5-10/mes para la mayoría de proyectos.

Mejor para: Proyectos personales, sitios personales, despliegues con presupuesto ajustado donde estás cómodo con infraestructura más nueva y menos probada.

Nuestro veredicto: Para la mayoría de proyectos Payload en producción con editores activos, Docker en un VPS es el mejor punto de partida. Es más barato de lo que piensas, elimina los problemas de cold start y te da control total. Usa Vercel solo si tus editores son poco frecuentes y quieres cero trabajo de operaciones.

Precios de Payload CMS — Lo Que Cuesta Realmente

El propio Payload es gratuito y tiene licencia MIT. Tus costes reales son el alojamiento y (opcionalmente) el desarrollo profesional. Aquí cómo quedan los números en la práctica, basados en configuraciones reales y el desglose de precios de Build with Matija.

Para comparar: el plan Team de Contentful empieza en $300/mes. El plan Team de Sanity es $99/mes por proyecto. Strapi Cloud empieza en $29/mes. El coste de $0 en software de Payload más $7-25/mes en alojamiento es difícil de rebatir — especialmente para agencias que construyen proyectos para clientes donde los precios por usuario destruyen los márgenes.

Payload vs Sanity vs Strapi vs Contentful — Comparación Rápida

Elige Payload si quieres control code-first y auto-alojamiento. Elige Sanity para la mejor edición visual y colaboración en tiempo real. Elige Strapi para un panel de administración rápido con ecosistema de plugins. Elige Contentful para infraestructura de nivel empresarial con garantías de SLA. Usamos Sanity para techsy.io, así que tenemos experiencia de primera mano comparando estas plataformas.

Hemos construido proyectos basados en Payload para clientes que necesitan propiedad de datos y auto-alojamiento, y gestionamos nuestro propio pipeline de contenido en Sanity. Ambos son excelentes — la elección correcta depende de la comodidad técnica de tu equipo y las preferencias de alojamiento. Si estás evaluando opciones de CMS headless para un proyecto, podemos ayudarte a elegir.

Para análisis más profundos de cada plataforma, consulta nuestras guías: mejores CMS headless en 2026, y guías individuales para Sanity, Strapi y Contentful.

Cuándo NO Usar Payload CMS

Descarta Payload si tu equipo no es técnico y necesita una interfaz similar a WordPress, si necesitas alojamiento cloud gestionado inmediato sin trabajo de auto-alojamiento, si tus editores quieren una edición visual al nivel de Sanity Studio, o si necesitas un marketplace de plugins para expansión rápida de funcionalidades. Ser honesto sobre las limitaciones genera más confianza que fingir que no existen.

Hemos recomendado en contra de Payload para clientes cuyos equipos editoriales no tenían experiencia con TypeScript. Aquí cuándo deberías buscar en otro lugar:

• Equipos no técnicos. Payload requiere conocimientos de TypeScript para la configuración. Si los editores de tu cliente no pueden tocar el código y necesitan modificar el modelo de contenido por su cuenta, WordPress o Sanity son mejor opción.
• Necesitas alojamiento gestionado ahora mismo. Con Payload Cloud pausado para nuevos registros, debes auto-alojarte. Si gestionar un servidor (incluso una configuración Docker sencilla) es un problema irresolvible, el enfoque cloud de Contentful o Sanity elimina esa carga.
• Colaboración editorial intensa. La colaboración en tiempo real de Sanity Studio — varios editores trabajando en el mismo documento simultáneamente con indicadores de presencia — está más pulida que cualquier cosa que ofrezca Payload. Si tienes un equipo editorial grande, Sanity gana aquí.
• Desarrollo orientado a plugins. Strapi tiene un marketplace de plugins más grande. ¿Necesitas un plugin SEO, un generador de sitemap, una integración de email? Strapi probablemente lo tiene. El ecosistema de Payload está creciendo, pero es más pequeño.
• No usas Next.js. Payload 3 está arquitectónicamente ligado a Next.js. Si tu frontend es Astro, Remix, Nuxt o SvelteKit, la mayor ventaja de Payload (la Local API en los componentes de servidor) no aplica. Aún tendrías REST y GraphQL, pero en ese caso Strapi o Directus pueden sentirse más naturales.

FAQ

¿Qué es Payload CMS y cómo funciona?

Payload es un CMS headless y framework de aplicaciones de código abierto, nativo en TypeScript, construido sobre Next.js. Defines tu modelo de contenido en archivos de configuración TypeScript, y Payload genera automáticamente un panel de administración, una API REST, una API GraphQL y una Local API. Se ejecuta dentro de tu app Next.js como una única unidad desplegable.

¿Es Payload CMS gratuito?

Payload es completamente gratuito bajo la licencia MIT. El software no cuesta nada descargarlo, usarlo o modificarlo. Payload Cloud (alojamiento gestionado) era de $35-199/mes, pero actualmente está pausado para nuevos registros tras la adquisición por Figma. El auto-alojamiento en un VPS cuesta EUR 7-45/mes según tu proveedor.

¿Qué pasó entre Payload y Figma?

Figma adquirió Payload el 17 de junio de 2025. Todo el equipo de Payload se unió a Figma. La licencia MIT de código abierto y el repositorio de GitHub permanecen sin cambios. Payload Cloud pausó nuevos registros. El auto-alojamiento sigue funcionando con normalidad. Es probable que el equipo esté construyendo un producto CMS integrado con Figma, pero no se han anunciado detalles.

¿Qué base de datos usa Payload CMS?

Payload soporta tres bases de datos mediante un patrón de adaptadores: PostgreSQL (recomendado para producción, funciona con Neon y Supabase para serverless), MongoDB (bueno para modelos orientados a documentos o actualizaciones desde Payload 2) y SQLite (solo para desarrollo local y CI). El código de tu aplicación permanece igual independientemente del adaptador que elijas.

¿Cómo despliego Payload CMS en 2026?

Con Payload Cloud pausado, despliega en Vercel con Neon Postgres (la opción más fácil), Docker en un VPS como Hetzner (mejor para producción con editores activos), Railway o Render (contenedores gestionados), o Cloudflare Workers (la más económica). Para la mayoría de sitios en producción con actividad editorial regular, un VPS basado en Docker proporciona la mejor experiencia.

¿Es Payload CMS mejor que Strapi?

Payload gana en experiencia de desarrollo nativa en TypeScript, integración con Next.js y la única Local API para consultas en el lado servidor con cero overhead. Strapi gana en su marketplace de plugins, edición de esquemas mediante interfaz gráfica y compatibilidad con más frameworks. Si tu equipo escribe TypeScript y usa Next.js, Payload es la opción más sólida. En caso contrario, evalúa Strapi.

¿Qué es la Local API de Payload?

La Local API es una capa de consulta en el lado servidor que llama a tu base de datos directamente con cero overhead HTTP. En lugar de hacer llamadas REST o GraphQL, importas Payload y consultas las collections directamente en los componentes de servidor de Next.js. Esto elimina los viajes de red y los costes de serialización, resultando en páginas más rápidas. Ningún otro CMS headless ofrece esto.

¿Puede Payload CMS manejar aplicaciones a gran escala?

Payload soporta PostgreSQL con connection pooling (via Neon o PgBouncer), control de acceso basado en roles con granularidad a nivel de campo, flujos de trabajo de borradores y versionado, y arquitecturas multi-tenant. Empresas y agencias usan Payload en producción para aplicaciones con mucho contenido. Las consultas de cero overhead de la Local API mejoran el rendimiento a escala.

¿Cómo se compara Payload con Sanity?

Payload es auto-alojado, code-first y con licencia MIT, con una Local API para rendimiento en el lado servidor. Sanity está alojado en la nube con edición visual superior, colaboración en tiempo real y el lenguaje de consulta GROQ. Payload te da más control sobre la infraestructura y menores costes. Sanity te da mejores herramientas editoriales y cero gestión de alojamiento.

¿Cuáles son las desventajas de Payload CMS?

Payload requiere conocimientos de TypeScript para la configuración, no tiene alojamiento cloud gestionado para nuevos usuarios desde la adquisición por Figma, ofrece un ecosistema de plugins más pequeño que Strapi, y está arquitectónicamente ligado a Next.js en la versión 3. Los equipos no técnicos pueden tener dificultades con el enfoque code-first, y la adquisición por Figma genera cierta incertidumbre a largo plazo.