Payload CMS en 2026: qué es, Payload 4 y comparativa

En 2026, cuando alguien se plantea con qué construir su web y quiere algo más moderno que el gestor de siempre, uno de los nombres que aparece es Payload CMS. No es un plugin ni una plantilla: es una forma distinta de entender qué es un gestor de contenidos, pensada desde el primer día para quien construye webs y aplicaciones a medida. En Next.js vs WordPress explicamos cuándo conviene una web a medida; aquí respondemos a lo que viene después: qué es Payload, cómo funciona, qué versión conviene usar hoy y en qué se diferencia del resto de opciones, desde el clásico WordPress hasta otros CMS headless como Strapi o Sanity.

Qué es Payload CMS

Payload CMS es un gestor de contenidos de código abierto, escrito en TypeScript, que funciona como CMS headless y se instala dentro de una aplicación Next.js. Es un CMS, como lo es WordPress, pero pensado para desarrolladores, y su diferencia de fondo se resume en dos palabras: code-first, es decir, "primero el código". En la mayoría de gestores, para crear una sección nueva —por ejemplo, un catálogo de productos— vas pinchando opciones en un panel. En Payload, esa estructura se escribe directamente en el código del proyecto, y a partir de ahí el propio sistema construye solo todo lo demás.

¿Qué construye "solo"? Tres cosas:

1. El panel de administración, donde los editores escriben y suben contenido, con su aspecto visual ya montado.
2. El almacén donde se guardan los datos (la base de datos).
3. Las conexiones que permiten que tu web —o una app móvil, o cualquier otro sistema— pida ese contenido y lo muestre.

La palabra headless ("sin cabeza") describe justo eso: Payload se ocupa del contenido, pero no decide cómo se ve. El diseño de la web lo pones tú por separado, normalmente con Next.js —la tecnología con la que están hechas muchas webs modernas, incluida esta—. Es lo contrario del modelo clásico de WordPress, donde el mismo sistema guarda el contenido y dibuja la página.

La novedad que lo cambió todo llegó con Payload 3.0: fue el primer gestor que se instala dentro de la propia web Next.js, en lugar de funcionar como un programa aparte. En la práctica, el panel, el almacén de datos y la web pública viven en un único proyecto y se publican juntos. Hoy la rama estable sigue siendo la 3.x y la 4.0 se prueba en versiones canary; lo vemos en detalle más abajo.

Un apunte que da tranquilidad sobre su futuro: Payload es gratuito y de código abierto —cualquiera puede usarlo y modificarlo, bajo licencia MIT— y, desde junio de 2025, forma parte de Figma, la conocida herramienta de diseño. Sigue siendo gratis y puedes alojarlo donde quieras, pero ahora con una empresa grande detrás.

Cómo funciona por dentro

La mejor forma de entenderlo es ver lo corto que es crear una sección. Este trozo de código define un apartado de artículos de blog, con su título, su cuerpo, su autor y su fecha:

export const Posts = {
  slug: 'posts',
  fields: [
    { name: 'title', type: 'text', required: true },              // título
    { name: 'content', type: 'richText' },                        // cuerpo del artículo
    { name: 'author', type: 'relationship', relationTo: 'users' }, // autor
    { name: 'publishedAt', type: 'date' },                        // fecha
  ],
}

No hace falta entender cada línea; basta con quedarse con la idea: con unas pocas líneas, Payload ya sabe crear el formulario del panel, guardar los datos y ponerlos a disposición de la web. Esa definición es la "fuente de la verdad", y todo lo demás se genera a partir de ella. Si mañana añades un campo, el panel y el almacén se actualizan solos.

Las piezas que merece la pena conocer, en cristiano:

• La base de datos, a tu elección. Payload no te obliga a usar una tecnología concreta para guardar los datos: funciona con las más habituales (es database-agnostic: MongoDB, PostgreSQL o SQLite). Traducido: puedes usar la que ya tengas o la que mejor encaje, sin cambiar de gestor.
• Usuarios y permisos incluidos. Trae de serie el registro e inicio de sesión y un control muy fino de quién puede ver o editar cada cosa, hasta el nivel de un dato concreto dentro de una ficha.
• Gestión de imágenes y archivos. Sube imágenes, las recorta y redimensiona solo a los tamaños que definas y permite organizarlas en carpetas, sin necesidad de programas ni servicios extra.
• Tareas automáticas. Puede encargarse de trabajos que tardan o que se repiten —enviar correos, procesar cosas de madrugada— sin ralentizar la web, algo poco común en gestores de este tipo.
• Contenido listo para cualquier pantalla. Lo sirve por API REST y GraphQL para que lo consuma una web, una app móvil u otro sistema; y como vive dentro de Next.js, la web puede pedírselo directamente, sin pasar por la red, y cargar más rápido.

Versiones de Payload CMS: la 3.90 estable y la 4.0 en canary

A 9 de octubre de 2026, la última versión estable de Payload es la 3.90.2, publicada el 23 de septiembre de 2026, y es la que conviene usar en producción. Payload 4.0 ya existe, pero solo como versión canary: la última es la 4.0.0-canary.39, del 8 de octubre, y todavía no hay beta ni fecha para la estable. Las dos se publican en npm: la 3.x con la etiqueta latest, la que se instala por defecto, y la 4.0 con la etiqueta canary.

Novedades recientes de Payload 3.x

La rama 3.x sigue recibiendo versiones casi cada semana. Lo más relevante de 2026, según las notas de versión oficiales:

• Compatibilidad con Next.js 16 (3.73, enero).
• Plugin MCP estable (3.78, febrero). El plugin MCP sale de beta y permite que asistentes de IA compatibles, como Claude Code, consulten y editen el contenido del CMS mediante claves de API. Si MCP te suena a chino, lo explicamos en cómo conectar Claude Code con tus herramientas. En la misma versión, la papelera de documentos deja de ser beta.
• Proyectos preparados para agentes de IA (3.83, abril). El instalador create-payload-app acepta la opción --agent (Claude, Codex o Cursor) y deja instaladas las instrucciones de Payload para el asistente de código.
• Importación y exportación de contenido estable (3.85, mayo).
• Permisos más estrictos en las tareas automáticas (3.89, septiembre). Adelanta a la 3.x un cambio de la 4.0 que puede romper compatibilidad, así que conviene leer sus notas antes de actualizar.
• Parche de seguridad crítico (3.90.0, 18 de septiembre). Corrige una tanda de vulnerabilidades, varias de ellas críticas, y el equipo pidió actualizar cuanto antes. Tras instalarla hay que regenerar los tipos y, con bases de datos SQL, crear y ejecutar una migración.

Payload 4.0 en canary: qué es y qué cambia

Una versión canary es una compilación que se publica directamente desde la rama principal de desarrollo, con lo último que se ha integrado y sin las garantías de una versión estable. Las de Payload 4.0 llegan a npm desde junio de 2026, y la propia política de versiones del proyecto avisa: las canary y las beta no se comprometen a ser compatibles entre sí, y la guía de migración solo cubre el salto entre versiones estables.

Esto es lo que trae, según el avance oficial de junio y la guía de migración de la 3.0 a la 4.0:

• Panel de administración rediseñado. Se reconstruye sobre un sistema de diseño con tokens semánticos, sin Sass y con mejor compatibilidad con Tailwind, y llega con nueva navegación, un escritorio de inicio renovado y muchas mejoras de accesibilidad. El objetivo, en palabras del equipo, "no es cambiar cómo funciona Payload".
• Más allá de Next.js. El núcleo se separa del framework mediante adaptadores. Next.js sigue siendo el principal y TanStack Start es la primera alternativa, ya publicada en canary.
• Más seguro por defecto. La Local API —la que usas desde tu propio código de servidor— pasa a respetar el control de acceso salvo que indiques lo contrario (overrideAccess vale false por defecto), y las tareas en segundo plano también aplican permisos de serie.
• Nuevos valores por defecto. Las colecciones guardan historial de versiones y quién creó o modificó cada documento (createdBy y updatedBy) sin configurar nada, y las consultas cargan un solo nivel de relaciones en lugar de dos, lo que aligera las respuestas.
• Archivos y medios. El redimensionado de imágenes con Sharp sale del núcleo a un paquete propio, los tamaños de imagen pasan a llamarse variants, cada archivo conserva su original y su historial, y llega una base común para organizar el contenido en carpetas, etiquetas y taxonomías.
• IA integrada. El plugin MCP se rediseña para funcionar con la mínima configuración, las instrucciones para modelos de lenguaje se gestionan desde el panel y la herramienta de migración incluye un modo asistido por agentes de IA.
• Lo que se va. Desaparece el editor Slate (Lexical queda como único editor de texto enriquecido) junto con las APIs marcadas como obsoletas, y suben los requisitos mínimos: Node.js 24.15, Next.js 16.4 y TypeScript 6.0.3.

Para migrar, Payload ofrece un codemod, una herramienta que reescribe el código automáticamente (npx @payloadcms/codemod). Resuelve la mayoría de los cambios y se puede ejecutar varias veces sobre un proyecto a medio migrar sin riesgo.

¿Cuándo sale Payload 4 y conviene usarlo ya?

No hay fecha oficial para la versión estable. En junio de 2026 el equipo escribió que apuntaba a "una beta de la 4.0 dentro del próximo trimestre"; a 9 de octubre seguimos en canary y no se ha publicado ninguna beta. Nuestra recomendación:

• Webs en producción: quedarse en la 3.x y, como mínimo, en la 3.90.0 por los parches de seguridad. La rama sigue recibiendo correcciones: el aviso de seguridad de septiembre salió a la vez para la 3.90.0 y para la 4.0.0-canary.34.
• Proyectos que empiezan ahora: arrancar en la 3.x y escribir el código pensando ya en la 4.0 —por ejemplo, indicando de forma explícita overrideAccess y depth en las consultas—, para que la migración sea un trámite.
• Si todavía usas el editor Slate: migra antes a Lexical. La guía oficial pide no actualizar a la 4.0 hasta haberlo hecho.
• Para evaluar la 4.0: en una rama aparte o un entorno de pruebas, con todos los paquetes @payloadcms/* en la misma versión canary, y nunca en el servidor de producción.

Payload CMS vs WordPress: comparativa rápida

Si solo tienes un minuto, esta tabla resume las diferencias con el gestor más extendido. En negrita, la opción más fuerte en cada criterio:

El resto del artículo desgrana las filas que más pesan en una decisión real.

Dos filosofías opuestas

WordPress nació como un sistema para publicar sin saber programar, y ahí sigue estando su fuerza. Es un monolito: el mismo servidor PHP guarda el contenido en una base de datos MySQL y genera la página pública en cada visita, apoyándose en un tema y en los plugins que tengas instalados. Cualquiera puede escribir un artículo, subir una foto o cambiar un texto desde un panel visual sin tocar una línea de código.

Payload invierte el punto de partida. Asume que hay un desarrollador construyendo la web y le da superpoderes: define el modelo de contenido en código y obtiene a cambio un backend completo y un panel de administración sin escribirlos a mano. El contenido se separa de la presentación, y el frontend —normalmente Next.js— decide cómo y cuándo mostrarlo, con la opción de servirlo ya preparado desde un CDN.

La consecuencia es directa: WordPress optimiza la experiencia de quien edita contenido; Payload optimiza la de quien construye la web. Casi todas las demás diferencias se derivan de esa decisión de origen.

Edición de contenido

Aquí WordPress mantiene su ventaja histórica. Con la IA integrada en el núcleo desde la versión 7.0 y lo que suma la 7.1, publicada en agosto de 2026 —diseño adaptado a cada tamaño de pantalla sin escribir CSS, un editor de imágenes renovado y notas para comentar el contenido en equipo—, la experiencia editorial es cómoda desde el minuto uno y no requiere absolutamente nada técnico. Para un cliente que publica a diario y quiere autonomía total, es difícil de superar.

Payload no se queda lejos, pero con un matiz importante: su panel también es visual y agradable de usar, una vez que un desarrollador lo ha configurado. El editor de texto, los campos personalizados o los bloques de contenido reutilizables ofrecen una experiencia moderna y muy pulida. La diferencia no está en el día a día del editor, sino en el punto de partida: en WordPress instalas y ya editas; en Payload alguien prepara antes la estructura del contenido.

Dos piezas recientes acercan además esa experiencia a la de un CMS visual de primera línea. El editor de texto usa Lexical —la tecnología de edición de Meta—, que permite incrustar elementos interactivos dentro del propio texto. Y la previsualización en vivo (Live Preview) deja al editor ver el diseño final exacto mientras escribe, sin sorpresas entre lo que edita y lo que se publica.

La captura resume bien la diferencia: el editor no rellena campos a ciegas, sino que trabaja sobre la página final, moviendo y editando bloques directamente donde se van a ver.

Rendimiento y seguridad

En rendimiento, Payload parte con la ventaja de Next.js: puede preparar las páginas por adelantado y servirlas desde el CDN, sin ejecutar código ni consultar la base de datos en cada visita. Los Core Web Vitals excelentes salen casi de serie —lo desarrollamos en nuestra guía práctica de Core Web Vitals—. WordPress puede ser rápido, pero exige trabajo continuo: caché, optimización de imágenes, disciplina con los plugins y un buen hosting.

En seguridad ocurre lo mismo. Una web construida con Payload y Next.js puede publicar su parte pública como páginas ya preparadas, sin panel de acceso expuesto ni base de datos accesible desde fuera. WordPress, por ser el CMS más popular del mundo, concentra la mayoría de los ataques automatizados a gestores de contenido, y su punto débil suele ser el ecosistema de plugins de terceros. No es que WordPress sea inseguro, sino que exige una vigilancia recurrente que alguien tiene que hacer y presupuestar.

Conviene ser justo en los dos sentidos. A favor de Payload: trae de fábrica el control de acceso, las sesiones seguras y la limitación de intentos, sin plugins. En su contra: al ser code-first, eres tú quien define las reglas de quién puede ver qué, y si no las declaras puedes dejar un dato sensible al descubierto. Y no es infalible: a 9 de octubre de 2026, el proyecto ha publicado este año 49 avisos de seguridad, ocho de ellos críticos, la mayoría en septiembre y octubre, que afectaban tanto al núcleo como a plugins oficiales; todos están corregidos a partir de la versión 3.90.0. La ventaja frente al monolito no es la ausencia de fallos, sino una superficie de ataque menor y que los parches llegan del propio equipo, sin depender de terceros. Eso sí, alguien tiene que aplicarlos.

Ecosistema y madurez

Y aquí es donde WordPress golpea de vuelta. Dos décadas de historia se traducen en un ecosistema descomunal: decenas de miles de plugins y temas, una comunidad enorme, tutoriales para cualquier duda y profesionales en cada ciudad. Si necesitas una tienda, un sistema de reservas o un campus online, es casi seguro que existe un plugin que lo resuelve hoy.

Payload es joven en comparación, aunque crece deprisa: su repositorio en GitHub supera las 45.000 estrellas, en junio el equipo contaba que había pasado de unas 100.000 a más de 400.000 descargas semanales desde septiembre, y en la primera semana de octubre de 2026 npm registró 978.799 descargas. El respaldo de Figma le da estabilidad, pero no hay un "plugin para todo": lo que en WordPress es instalar y configurar, en Payload muchas veces es desarrollar. Para un equipo técnico eso es una ventaja (control total, sin sorpresas de terceros); para quien busca montar algo estándar sin desarrollo, es un coste.

Gobernanza y soberanía

Hay un factor que antes no aparecía en estas comparativas y ahora sí: quién controla la plataforma. La gobernanza de WordPress está muy centralizada en Automattic y su cofundador, y la crisis de 2024 con WP Engine —con bloqueos de acceso al repositorio oficial de plugins y actualizaciones— demostró que una disputa corporativa puede afectar a millones de webs. Con Payload, toda la configuración vive en tu propio proyecto bajo licencia MIT y no dependes de un repositorio central para funcionar ni para actualizar la seguridad: el control sobre tu web es total.

Payload frente a otros CMS headless

WordPress es solo una de las alternativas. Si ya tienes claro que quieres un CMS headless, la comparación relevante es con los otros pesos pesados del sector: Strapi, Sanity y Contentful. Cada uno resuelve el mismo problema de forma distinta.

• Strapi, hoy en su versión 5, es el rival de código abierto más directo, pero mantiene el modelo clásico de dos programas separados —el gestor por un lado y la web por otro—, con la lentitud añadida de que tengan que hablar entre ellos por la red. Payload se ahorra ese salto al vivir dentro de Next.js. Además, Strapi solo funciona con bases de datos SQL, mientras que Payload admite también MongoDB.
• Sanity es excelente para contenido muy estructurado y trabajo en equipo en tiempo real, y también define el contenido en código. La gran diferencia es el modelo: es un servicio en la nube, tus datos viven en sus servidores y la factura crece por usuario y por uso; tiene plan gratuito, pero el plan Growth cuesta 15 dólares por usuario al mes. Payload lo alojas tú, así que el control de los datos es tuyo —algo innegociable en sanidad, banca o administración pública—. Sanity, además, se consulta sobre todo con su propio lenguaje, GROQ; Payload usa los estándares del sector, REST y GraphQL.
• Contentful es la opción para grandes corporaciones: muy potente, pero con un precio y una complejidad que lo hacen desproporcionado para la mayoría de proyectos.
• Opciones más ligeras como Keystatic guardan el contenido como simples archivos de texto dentro del proyecto: perfectas para documentación o blogs sencillos, pero se quedan cortas en cuanto necesitas usuarios, permisos o muchos datos relacionados entre sí, terreno donde Payload juega en otra liga.

Resumido: frente a los servicios de pago (Sanity, Contentful), Payload gana en control y coste; frente a Strapi, en integración con Next.js; y frente a las opciones más simples, en potencia para aplicaciones de verdad.

Payload y Figma: qué ha cambiado desde la compra

El 17 de junio de 2025, su creador y CEO, James Mikrut, anunció que Payload se unía a Figma, con el mismo equipo al frente del proyecto. Para quien evalúa adoptarlo, importan dos cosas. La primera: el núcleo sigue siendo de código abierto bajo licencia MIT, y Figma se ha comprometido a mantenerlo e invertir en él. La segunda: el despliegue de proyectos nuevos en Payload Cloud está en pausa; los existentes siguen funcionando con normalidad y el equipo prepara un sustituto al que podrán migrar. En la práctica, Payload se despliega en cualquier sitio donde funcione una app Next.js, desde Vercel o Cloudflare hasta tu propio servidor; comparamos las opciones en dónde desplegar Next.js.

La lógica de la operación explica hacia dónde va el producto. Payload define el contenido en código, con una estructura que se parece mucho a un sistema de diseño, y Mikrut lo resumió así en el anuncio: "nos integraremos con los sistemas de diseño como ningún otro CMS puede". La apuesta es que los componentes y estilos creados en Figma se traduzcan en estructura de contenido en Payload, recortando el eterno "toma y daca" entre quien diseña y quien programa. De momento no hay una integración concreta publicada: en junio de 2026 el equipo hablaba de integraciones más profundas entre los dos productos y enmarcaba en ese acercamiento el rediseño del panel de la 4.0.

Cuándo elegir Payload

• Equipo técnico que quiere control total y TypeScript de punta a punta: Payload. El modelo de contenido en código es un placer para desarrollar y mantener.
• Cliente no técnico que publica a diario y quiere autonomía: WordPress. La edición sin desarrollo previo sigue siendo su gran baza.
• Web o aplicación a medida sobre Next.js que además necesita panel de contenido: Payload. Al vivir dentro del mismo proyecto, evita el pegamento entre gestor y web.
• Proyecto que se apoya en funcionalidad muy específica ya hecha (membresías, cursos, reservas complejas): WordPress, salvo que quieras desarrollar esos sistemas a medida.
• Producto digital, portal con roles y permisos finos, o base de una app: Payload. El control de acceso al detalle es de los mejores del mercado.
• Sectores con datos sensibles (salud, finanzas, administración): Payload, por poder eliminar el panel expuesto y la base de datos pública, y por mantener los datos en tu propio servidor.

¿Y la comparación con WordPress headless (usar WordPress solo como almacén de contenido y Next.js como web)? Es una alternativa legítima, pero ahí sigues arrastrando dos sistemas y dos despliegues; Payload unifica todo en un único proyecto sobre Next.js. Si ya vives en el ecosistema JavaScript, esa unificación es su mayor argumento.

Conclusión: ¿es Payload CMS para ti?

No hay tecnología ganadora universal, hay proyectos y perfiles. Payload CMS brilla cuando manda quien construye: control total, TypeScript de punta a punta, rendimiento y seguridad de serie, y un backend completo que vive dentro de tu propia app Next.js, con los datos siempre bajo tu control. Frente a WordPress gana cuando el equipo es técnico y el rendimiento importa; frente a los CMS de pago en la nube (Sanity, Contentful), en control y coste; frente a Strapi, en integración con Next.js. Y si te decides, hoy toca empezar sobre la 3.x estable y dejar la 4.0 para cuando salga de canary.

Nuestra forma de decidirlo es sencilla: miramos quién va a tener las manos en la web el día a día y cuánto pesa el contenido frente a la funcionalidad a medida. En nuestro servicio de desarrollo web partimos de esa pregunta antes de recomendar nada, y en nuestros proyectos puedes ver distintos enfoques funcionando en producción.