CMS para Symfony: cómo elegir y comparativa de las mejores opciones

Symfony es un framework, no un CMS. Cuando un proyecto Symfony necesita gestionar contenido, el abanico de opciones es distinto al del mundo WordPress: no consiste en instalar "el CMS de turno". Primero hay que decidir qué papel juega el contenido en tu arquitectura, y elegir en consecuencia.

La decisión depende sobre todo de una cosa: dónde está el centro de gravedad de tu proyecto. Si el protagonista es tu aplicación a medida y el contenido es un complemento, te conviene una herramienta. Si el contenido es el producto, otra. Y si solo necesitas un sitio sencillo y rápido, probablemente ninguna de las dos.

Aquí comparamos las cinco opciones que más aparecen en proyectos Symfony (Armonic, Sulu, Ibexa, Drupal y Grav) por arquitectura, experiencia de edición, capacidades headless y casos de uso. Ninguna gana en todos los escenarios: cuál te conviene depende de qué vayas a construir.

No todas estas opciones se relacionan con Symfony de la misma forma, y entender el matiz evita malentendidos:

• Bundles nativos de Symfony. Se instalan con Composer dentro de tu aplicación Symfony y comparten su runtime, su base de código y su backend. Es el caso de Armonic y Sulu.
• Plataformas construidas sobre Symfony. Son aplicaciones completas y autónomas que utilizan componentes de Symfony por debajo, pero que tú instalas como base del proyecto. Es el caso de Ibexa y, en buena medida, Drupal (Drupal moderno usa muchos componentes de Symfony, pero es su propia plataforma, no un bundle).
• Aplicaciones independientes que aprovechan componentes de Symfony. Es el caso de Grav: no es una aplicación Symfony, pero reutiliza librerías de Symfony para tareas concretas.

Esta distinción —bundle dentro de tu app vs. plataforma sobre la que construyes— es la que más condiciona el resto de la decisión.

A continuación, cada opción en detalle.

Armonic es un bundle CMS construido para y sobre Symfony. Se instala con composer require dentro de una aplicación Symfony nueva o existente y comparte con ella código, runtime e interfaz de administración. Su filosofía es la integración profunda: el CMS y la aplicación son una sola cosa.

Dónde destaca:

• Integración real y admin unificado. Las secciones del CMS (contenido, bloques, media) conviven en el mismo backend que la gestión de usuarios, productos o pedidos de tu aplicación. Un solo despliegue, una sola base de código.
• Edición inline moderna. Un constructor de páginas basado en módulos con edición directa sobre la página y vista previa en tiempo real, pensado para que marketing y contenido trabajen con autonomía y menos dependencia de desarrollo.
• Configuración como código. Los tipos de contenido se definen en archivos YAML versionables, lo que encaja con flujos Git y CI/CD y garantiza consistencia entre entornos.
• Versionado granular. Guarda una versión en cada cambio, no solo al publicar, lo que da un historial completo y auditable (útil para compliance y trazabilidad).

Sus límites:

• No es headless de serie: es un CMS acoplado, así que para servir contenido a frontends desacoplados habría que construirlo a medida.
• No incluye buscador de frontend por defecto.
• Los workflows son básicos (versionado y publicar/despublicar), sin motor de aprobación multi-paso.

Ideal para: equipos que ya construyen con Symfony y necesitan un CMS integrado, con admin único y una experiencia editorial visual, sin montar una plataforma separada.

Sulu es un CMS open source también construido como bundle de Symfony. Lo que lo distingue es el contenido estructurado y una API REST headless lista desde el inicio.

Dónde destaca:

• Headless de serie. Incluye una API REST de contenido, lo que lo hace adecuado desde el primer día para arquitecturas desacopladas (una SPA en React, una app móvil, etc.).
• Contenido estructurado y consistente. El equipo de desarrollo define la estructura de página en plantillas XML y el equipo editorial rellena formularios. Menos flexibilidad de maquetación, pero mayor integridad del dato.
• Búsqueda integrada. Trae solución de búsqueda (Lucene/Elasticsearch) válida para backend y web pública.
• Gestión de medios avanzada. Permisos granulares e integración con Flysystem (S3 y similares). Licencia MIT.

Sus límites: la edición es por formularios, no visual/inline, así que el equipo de contenido no puede cambiar la maquetación sin intervención técnica. El versionado se crea al publicar (modelo draft/live), sin historial detallado del borrador.

Ideal para: proyectos con necesidades headless inmediatas, equipos que prefieren estructuras de contenido rígidas y casos donde la búsqueda es crítica desde el día uno.

Ibexa es una plataforma de experiencia digital (DXP) y framework de gestión de contenidos construido sobre Symfony. Es una aplicación autocontenida, orientada a entornos enterprise.

Dónde destaca:

• Headless y API-first. REST y GraphQL de serie, ideal para estrategias omnicanal (web, móvil, otros servicios) desde un único repositorio de contenido.
• Workflows de nivel enterprise. Motor de aprobación multi-paso, transiciones por roles y estados de contenido (borrador, en revisión, publicado), pensado para equipos editoriales grandes.
• Búsqueda avanzada. Search API agnóstica que integra Elasticsearch o Solr para búsquedas rápidas y facetadas.
• Plataforma completa. Versionado con comparación (diff), constructor visual drag-and-drop, y opciones de PIM, commerce y hosting PaaS (Ibexa Cloud).

Sus límites: es una plataforma completa que instalas como base del proyecto, con la curva y el peso que eso implica; suele ser sobredimensionada si tu proyecto es una app a medida con algo de contenido.

Ideal para: organizaciones que construyen una plataforma digital de gran escala donde el contenido es el producto central y se distribuye en múltiples canales, con procesos editoriales complejos.

Drupal es un CMS de propósito general, open source y muy maduro. Aunque las versiones modernas usan muchos componentes de Symfony, es una aplicación completa y autónoma, no un bundle.

Dónde destaca:

• Ecosistema enorme de módulos. Decenas de miles de módulos contribuidos cubren casi cualquier funcionalidad imaginable, reduciendo el código a medida necesario.
• Workflows editoriales avanzados. Los módulos Workflows y Content Moderation están en el core: estados como borrador, en revisión y aprobado vienen de serie.
• Headless maduro. JSON:API y REST en el core para entrega de contenido a frontends desacoplados o apps.
• Construcción desde la interfaz. Perfiles no técnicos pueden definir tipos de contenido, campos y relaciones sin escribir código. Soporte sólido multisitio y multidioma.

Sus límites: es una plataforma sobre la que construyes (tu lógica vive dentro de su estructura de módulos y temas), no un componente que añades a tu app. Para un equipo cuyo centro es una aplicación Symfony propia, puede sentirse como adoptar un segundo sistema.

Ideal para: sitios centrados en contenido a gran escala, con flujos editoriales complejos y necesidad de aprovechar un ecosistema masivo de módulos preexistentes.

Grav es un CMS flat-file: no usa base de datos y guarda contenido y configuración en archivos Markdown y YAML. No es una aplicación Symfony, pero aprovecha varios de sus componentes.

Dónde destaca:

• Simplicidad y portabilidad. Sin base de datos, el despliegue es casi trivial (copiar archivos a un servidor) y las copias de seguridad, un zip.
• Ecosistema público de plugins. Más de 300 plugins gratuitos de la comunidad para búsqueda, formularios, SEO, etc. Licencia MIT.
• Accesible. Cualquier desarrollador PHP puede adoptarlo sin ser experto en Symfony.

Sus límites: no tiene constructor visual de páginas (edición basada en archivos y plantillas), carece de versionado nativo (depende de Git) y su soporte multisitio está etiquetado como "preliminar".

Ideal para: sitios sencillos e independientes (blogs, documentación, portfolios, webs de pequeña empresa) donde mandan la simplicidad operativa y la velocidad.

La tabla ayuda, pero la decisión se aclara antes respondiendo a unas pocas preguntas:

¿Partes de una aplicación Symfony existente o de cero? Si ya tienes una app a medida y quieres añadirle gestión de contenido sin replataformar, un bundle (Armonic, Sulu) encaja de forma natural. Si arrancas de cero un proyecto centrado en contenido, una plataforma (Drupal, Ibexa) puede darte más de serie.

¿El contenido es el producto o un complemento de tu aplicación? Si tu aplicación es la protagonista y el contenido la acompaña, Armonic. Si el contenido es el activo central que distribuyes, Drupal o Ibexa.

¿Necesitas headless o multicanal desde el principio? Si vas a servir contenido a varios frontends desde el día uno, mira Sulu o Ibexa. Si tu web y tu app son lo mismo, no pagues la complejidad del headless.

¿Quién gestiona el contenido? Si es un equipo de marketing que necesita autonomía visual, la edición inline de Armonic se nota mucho en el día a día. Si son perfiles técnicos o priorizas la rigidez estructural, Sulu o Drupal.

¿Tienes procesos de aprobación complejos? Si necesitas flujos editoriales multi-paso, Drupal e Ibexa lo traen de serie; Armonic y Sulu, no.

¿Qué peso tiene la búsqueda integrada? Crítica desde el inicio → Sulu o Ibexa. Asumible a medida → Armonic.

Licencia y hosting. Si necesitas MIT y despliegue ultraligero, Grav. Si quieres opción PaaS gestionada, Ibexa. El resto son self-hosted con licencias a revisar según tu caso.

¿Symfony tiene un CMS propio? No. Symfony es un framework; el contenido se gestiona con CMS construidos sobre él (como Armonic o Sulu) o con plataformas que usan sus componentes (como Drupal o Ibexa).

¿Drupal está basado en Symfony? Drupal moderno utiliza muchos componentes de Symfony, pero es una plataforma completa y autónoma, no un bundle que se integre dentro de tu aplicación Symfony.

¿Cuál es el mejor CMS headless para Symfony? Si necesitas API desde el día uno, Sulu (REST) e Ibexa (REST + GraphQL) son las opciones más directas. Drupal también ofrece headless maduro vía JSON:API.

¿Puedo añadir un CMS a una aplicación Symfony que ya existe? Sí. Un bundle como Armonic está pensado precisamente para eso: se instala con Composer dentro de la app existente sin replataformar.

¿Qué CMS Symfony elegir para multisitio y multidioma? Armonic, Sulu, Ibexa y Drupal tienen soporte sólido. En Grav, el multisitio es todavía preliminar.

La elección de un CMS para Symfony es, sobre todo, una decisión de arquitectura: depende de dónde esté el centro de gravedad de tu proyecto. Si es tu aplicación Symfony a medida, un bundle integrado como Armonic ofrece el mayor nivel de cohesión y una experiencia editorial moderna. Si es el contenido, plataformas como Drupal o Ibexa están más preparadas. Y si solo necesitas un sitio sencillo, Grav gana en simplicidad operativa.

En proyectos donde la lógica de negocio es avanzada o los procesos son complejos, contar con una empresa especializada en desarrollo Symfony puede ahorrarte errores caros en la arquitectura y el mantenimiento a largo plazo. Si quieres comentar tu caso, hablemos.