Un cliente me llamó en octubre pasado en un ligero pánico. Habían construido toda su plataforma de marketing en un CMS hospedado y el proveedor acababa de anunciar una reestructuración de precios. De la noche a la mañana, su factura pasó de £180/mes a algo más de £900. El contenido no era complejo. Un blog, un catálogo de productos, tal vez cuarenta campos personalizados en tres colecciones. Nada que justificara esa cifra. Esa llamada es la razón por la que pasé los siguientes tres meses migrando dos proyectos de Seahawk a Payload CMS y construyendo un modelo de costos adecuado alrededor de él.
Así que déjame contarte lo que realmente encontré.
Qué es Payload CMS realmente (y qué no es)
Payload es un CMS headless impulsado por código y orientado a TypeScript primero. Defines tus colecciones, globales y campos completamente en archivos de configuración. No hay GUI para hacer clic para diseño de esquemas. El panel de administración se genera a partir de tu código, no al revés. Esa inversión es el punto completo, y también es lo que te tropezará si vienes de WordPress o Contentful.
No es SaaS. No hay un nivel hospedado por Payload que pagues mensualmente. Eres dueño del despliegue completamente. Eso es una característica y una restricción dependiendo de tu situación.
Payload 2.0 se lanzó con soporte completo para PostgreSQL junto a MongoDB, que fue lo que desbloqueó que fuera genuinamente viable para clientes que quieren datos relacionales sin las acrobacias de NoSQL. Para principios de 2026, el ecosistema alrededor de él ha madurado lo suficiente como para que me sienta cómodo recomendándolo para producción sin los cuidados que solía adjuntar.
En qué está realmente construido
Bajo el capó: Next.js 15 para la UI de administración, TypeScript en todas partes, y tu elección de Drizzle ORM (para Postgres) o Mongoose (para MongoDB). Las APIs REST y GraphQL se generan automáticamente a partir de tu esquema. También obtienes una API local para consultas del lado del servidor que es rápida de una manera que aún me sorprende cada vez.
Dónde encaja en 2026
Honestamente, Payload se sienta en un punto dulce específico. No todos los proyectos pertenecen allí. Después de ejecutarlo en una docena de construcciones en Seahawk, aquí está el patrón que he notado.
Es un ajuste fuerte cuando:
- El proyecto es liderado por desarrolladores desde el principio. Significando que un ingeniero real lo está configurando, no un cliente al que le han dicho que pueden "manejar todo ellos mismos".
- Necesitas lógica de campos personalizada, campos condicionales, o cadenas de relaciones complejas que te costarían caro en cargos por características en algo como Contentful.
- El cliente es sensible al costo en un horizonte de 2-3 años. Las matemáticas casi siempre se inclinan a favor de Payload después del mes 14.
- Ya estás ejecutando una aplicación Next.js o Node y quieres el CMS coubicado o al menos compartiendo infraestructura.
Es un ajuste malo cuando:
- El cliente necesita que una persona no técnica configure nuevos tipos de contenido sin apoyo de ingeniería.
- Estás construyendo algo que necesita ser entregado completamente y el destinatario no tiene un desarrollador en el personal.
- Tienes menos de dos semanas para lanzar y no tienes un proyecto Payload listo para clonar.
Aprendí ese segundo punto a la mala. Allá por 2022 definí el alcance de un sitio pequeño para una organización sin fines de lucro con Payload (v1 en ese momento). El plan era pasarlo a su coordinador de voluntarios interno para que lo manejara. Tres meses después seguía recibiendo mensajes de WhatsApp preguntando por qué el campo no aparecía. El CMS no estaba mal para el proyecto técnicamente. Estaba mal para el modelo de entrega.
El Costo Real de Ejecutar Payload en 2026
Esta es la sección que la mayoría de los posts de blog se saltan o disfrazan con rangos vagos. Te doy números reales de lo que he ejecutado.
Infraestructura
Necesitas un lugar para alojar el servidor Node y un lugar para guardar tu base de datos. Esos son tus dos costos fijos.
Opción A: Railway Uso Railway para la mayoría de proyectos Payload con tráfico medio. Una app típica de Payload (servicio Node + instancia Postgres) corre entre $12 y $35/mes dependiendo del uso. Para un sitio de marketing con contenido editorial, casi seguro estás en la banda de $15-20. Los despliegues son directos desde un repo de GitHub, y los backups de Postgres son automáticos.
Opción B: Render Precio similar a Railway. Existe capa gratuita pero no la uses en producción (los cold starts te avergonzarán frente a clientes). Los planes pagados comienzan en $7/mes para el servicio web más $7/mes para Postgres administrado. Así que ~$14/mes mínimo, escalando con CPU y memoria conforme crece el tráfico.
Opción C: VPS Auto-administrado Si ejecutas múltiples proyectos Payload, un VPS de DigitalOcean o Hetzner empieza a verse atractivo. Un Hetzner CX32 (4 vCPU, 8GB RAM) cuesta €8.29/mes y puede ejecutar sin problemas tres o cuatro instancias Payload detrás de un proxy Nginx. Ejecuto una instancia compartida de Postgres en la misma máquina para clientes más pequeños. No es para los de corazón débil, pero perfectamente estable.
Almacenamiento de Media
Payload no maneja tus imágenes a menos que configures un adaptador de almacenamiento. Los dos que he usado en producción:
- AWS S3 + CloudFront para cualquier cosa a escala. Presupuesta aproximadamente $5-15/mes para un sitio de marketing típico.
- Cloudflare R2 como almacenamiento compatible con S3 sin costos de egreso. Este es mi estándar ahora. Para un sitio con ~50GB de activos de media, estoy pagando esencialmente nada en egreso y aproximadamente $1.50/mes en almacenamiento. Usa el plugin payload-cloud-storage y apúntalo a R2.
Tiempo de Desarrollador (el costo que la gente olvida)
Configuración inicial de un proyecto Payload, correctamente estructurado con autenticación, media, las colecciones que tu cliente necesita, y un modelo de control de acceso sensato: presupuesta 12-20 horas para un desarrollador experimentado. Eso no es complejidad opcional, esa es simplemente la naturaleza de un CMS basado en código. Con una tarifa diaria de £400-600 (freelance de mercado medio en Londres), eso es £4,800-12,000 de entrada antes de que escribas una línea de código frontend.
Compara eso con lanzar un espacio de Contentful y configurar tipos de contenido vía su interfaz en 3 horas. El costo de entrada es real. El costo continuo es donde Payload gana.
Costo Total de Propiedad, Año 1 vs Año 3
Aquí hay un modelo aproximado para un sitio de marketing de tamaño medio, comparando Payload en Railway vs el plan Growth de Contentful:
- Payload en Railway, Año 1: £18/mes infra + ~£5,000 tiempo de configuración = ~£5,216 total
- Payload en Railway, Año 3: £18/mes infra + mantenimiento mínimo = ~£648 infra durante el año 3
- Plan Growth de Contentful, Año 1: £320/mes = £3,840, sin costo de configuración personalizada
- Plan Growth de Contentful, Año 3: £320/mes = £3,840 de nuevo
El punto de equilibrio ocurre alrededor del mes 20-22 dependiendo de tu tarifa diaria. Después de eso, Payload es sustancialmente más barato. Para un cliente que va a ejecutar el mismo sitio en 2028, esto importa.
La Experiencia del Desarrollador en Términos Honestos
Genuinamente disfruto trabajar con Payload. El enfoque config-as-code significa que tu schema está versionado, es revisable en pull requests, y desplegable como cualquier otro cambio de código. Eso solo ya lo pone por delante de herramientas CMS donde un content modeller ha estado haciendo clic en una GUI y nadie sabe realmente qué cambió o cuándo.
La inferencia de TypeScript es excelente. Los tipos de tus colecciones fluyen hacia tus consultas locales de API sin ningún paso manual de generación de tipos. Seahawk tuvo un proyecto de contenido fintech el año pasado donde consultábamos datos de relaciones profundamente anidadas, y la seguridad de tipos atrapó dos bugs de forma de datos antes de que llegaran a staging. Eso no es poco.
La UI admin es limpia y rápida. No es llamativa, solo funcional. Los editores no técnicos generalmente se sienten cómodos con ella dentro de una o dos sesiones una vez que los campos están bien etiquetados. Los hooks son la otra cosa que quiero señalar: before-change, after-read, y hooks de ciclo de vida similares te permiten hacer cosas en la capa de datos que de otro modo tendrías que construir como middleware API personalizado.
Los Aspectos Problemáticos
Migraciones. Si estás en Postgres y cambias tu schema, necesitas ejecutar migraciones de Drizzle. Esto está bien si sabes lo que haces y es ligeramente aterrador si no. He visto a un dev junior en un subcontrato de Seahawk eliminar una columna por no leer cuidadosamente el diff de migración. Siempre revisa, siempre haz backup primero.
El ecosistema de plugins es más pequeño que WordPress, obviamente. Pero el directorio de plugins de Payload ha crecido significativamente. Form builder, nested docs, campos SEO, redirects. Las bases importantes están cubiertas. Aún escribirás más código personalizado que en una plataforma más establecida.
Cómo Se Compara con Otras Opciones Headless
Déjame ser directo sobre dónde elegiría algo distinto.
Sanity.io si tu equipo de contenido es grande y editores no técnicos están creando sus propias estructuras de contenido. Studio de Sanity es más amigable para esa audiencia, el backend alojado es confiable, y el lenguaje de consulta GROQ es genuinamente agradable de escribir. Pagarás $99+/mes en un plan real, pero para algunos clientes vale la pena.
Strapi fue la alternativa a Payload durante años. Sigue siendo viable y el modelo self-hosted es similar, pero encuentro la experiencia de TypeScript más torpe y la ruta de actualización entre versiones mayores ha sido históricamente dolorosa. El código de Payload me parece más intencional.
WordPress con ACF o una configuración basada en bloques para cualquier cosa que deba entregarse a un mantenedor no técnico que ya está cómodo con WordPress. Sigue siendo la respuesta correcta para grandes porciones de lo que construyen las agencias. Que nadie te diga lo contrario.
Directus como un outsider que vale la pena ver, especialmente si trabajas con un schema de base de datos existente que necesitas envolver con un CMS. Filosofía diferente a Payload pero genuinamente bueno en ese trabajo específico.
FAQ
¿Es Payload CMS gratuito?
Sí. Payload es open-source bajo la licencia MIT. No hay cuota de licencia. Pagas por tu propia infraestructura de hosting, que es el tradeoff versus un CMS SaaS alojado.
¿Pueden los clientes no técnicos usar el panel admin de Payload?
Con campos bien etiquetados, valores por defecto sensatos, y algo de capacitación básica, sí. La UI admin es lo suficientemente limpia que los editores la aprenden razonablemente rápido. Lo que no pueden hacer es crear nuevas colecciones o cambiar el schema sin un developer. Esa es una restricción dura por diseño.
¿Funciona Payload con Next.js?
Sí, y particularmente bien. Payload 2.x fue reconstruido en Next.js, así que puedes ejecutar el CMS y tu frontend desde la misma app Next.js. Esta configuración "monorepo en un solo repo" funciona bien para proyectos pequeños a medianos y reduce tu overhead de infraestructura.
¿Qué base de datos debo usar con Payload?
Para nuevos proyectos en 2026 por defecto uso PostgreSQL vía Drizzle ORM. Está bien probado, obtienes restricciones relacionales apropiadas, y las herramientas de migración son sólidas cuando se usan con cuidado. MongoDB sigue siendo una opción y es un buen ajuste si tus datos tienen forma de documento por naturaleza, pero Postgres es mi primera recomendación.
¿Cómo maneja Payload las cargas de medios?
Por defecto, Payload almacena cargas localmente en el filesystem del servidor, lo que está bien para desarrollo pero no para producción. Para producción querrás configurar un adaptador de almacenamiento que apunte a S3, Cloudflare R2, o similar. El paquete oficial @payloadcms/plugin-cloud-storage maneja esto y toma aproximadamente una hora configurarlo correctamente la primera vez.
¿Está Payload listo para sitios de producción a gran escala?
Está manejando tráfico de producción serio en varias empresas. Dicho esto, no es el CMS que elegiría para un sitio con 10 millones de visitantes mensuales y un equipo editorial de 20 personas. A esa escala, estarías buscando opciones de nivel empresarial con contratos de soporte dedicado. Para los proyectos de mid-market construidos por agencias que representan la mayor parte de nuestro trabajo en Seahawk, Payload es estable y capaz.
La Verdad Honesta
Payload CMS en 2026 es una herramienta madura y bien construida para proyectos liderados por desarrolladores donde el costo a largo plazo importa y tienes la capacidad de ingeniería para ser dueño del stack. La inversión inicial en tiempo de configuración es real. El costo de infraestructura continuo es bajo. La experiencia del desarrollador es buena.
No es un reemplazo de WordPress. No está intentando serlo. Pero para el proyecto correcto, con el equipo correcto, es la opción de headless CMS más rentable que he trabajado en más de 12,000+ builds. La pregunta no es si es bueno. Es si es bueno para tu situación.