¿Es EmDash CMS de Cloudflare el fin de WordPress?

Cloudflare acaba de lanzar su propio CMS. Se llama EmDash, lo presentan como «el sucesor espiritual de WordPress» y ha caído como una bomba en la comunidad. Si quieres saber en qué consiste, si de verdad es una alternativa a WordPress y qué implicaciones tiene para todo el ecosistema montado alrededor de WordPress estás en el lugar indicado.

Lo anunciaron el 1 de abril, que es el día de los inocentes en medio mundo, así que la primera reacción de mucha gente fue pensar que era broma, pero no lo es. El repositorio en GitHub es real, el código funciona y en las primeras ocho horas acumuló más de 1.300 estrellas y llegó al número 1 en Hacker News.

Pero que sea real no significa que sea lo que Cloudflare dice que es. Vamos a ver qué tiene en las tripas, qué promete, qué cumple y qué le falta.

Qué es EmDash y de dónde sale

EmDash es un CMS de código abierto escrito en TypeScript, construido sobre el framework Astro y pensado para funcionar sobre la infraestructura de Cloudflare (Workers, D1, R2). Tiene licencia MIT y su código está disponible en GitHub. La versión actual es la 0.1.0, una beta temprana orientada a desarrolladores.

El contexto tiene su miga, y hay que tenerlo en cuenta porque es importante. En enero de 2026 Cloudflare compró la empresa detrás de Astro, el framework que está creciendo más rápido en el mundo del desarrollo web para sitios de contenido. Dos meses después anuncia un CMS construido sobre Astro que aspira a sustituir a WordPress. Llámame loco pero no creo que sea una mera coincidencia.

Detrás del proyecto está Matt Kane, que lleva dos años en el equipo core de Astro y ha trabajado a jornada completa en EmDash desde mediados de enero. No es un experimento de fin de semana ni un proyecto hecho con vibe coding, aunque Cloudflare sí reconoce que ha usado agentes de IA durante el desarrollo (¿y quién no?).

La pregunta que todo el mundo se hace es obvia, ¿de verdad puede esto competir con WordPress?

Para empezar a tener claro algo el contexto, WordPress lleva 23 años, lo usa el 43% de la web y tiene detrás una comunidad de millones de desarrolladores, diseñadores, creadores de contenido y empresas. EmDash tiene dos meses de vida y una versión 0.1.0.

Qué ofrece EmDash

El paquete técnico es interesante, eso hay que reconocerlo. EmDash está escrito de arriba abajo en TypeScript y funciona como una integración de Astro. Añades EmDash a tu configuración de Astro y tienes un CMS completo con panel de administración, API REST, sistema de identificación, librería de medios y sistema de plugins (aunque aún no haya ninguno).

El contenido se almacena como Portable Text, que es JSON estructurado en lugar de HTML. Esto tiene una ventaja clara para trabajar con agentes de IA, ya que un modelo de lenguaje puede leer y modificar el contenido directamente sin tener que analizar HTML.

Cada instancia de EmDash incluye un servidor MCP (Model Context Protocol) integrado, una CLI (interfaz de comandos) para gestión automatizada y Agent Skills, documentos estructurados para que, en este caso, los agentes de IA entiendan cómo funciona el CMS.

La identificación usa passkeys por defecto, eliminando las contraseñas del proceso. Incluye perfiles de usuario (administrador, editor, autor, colaborador) con permisos detallados, y trae compatibilidad nativa para x402, un estándar abierto de micropagos por HTTP que permite cobrar por el acceso al contenido sin necesidad de suscripciones. La idea es que los agentes de IA que consumen contenido puedan pagar automáticamente por ello.

Es serverless, lo que significa que en Cloudflare escala a cero cuando no hay tráfico (no pagas por servidores parados) y se levanta en milisegundos cuando llega una petición. También puedes ejecutarlo en cualquier servidor con Node.js y SQLite, aunque pierdes varias de las funcionaliades más llamativas.

La licencia MIT y lo que cambia respecto a WordPress

Este es uno de los puntos que más atención merece (o al menos a mi) y que menos se está analizando. EmDash usa licencia MIT, mientras que WordPress usa GPL. ¿Y? Pues resulta que la diferencia es enorme.

La GPL de WordPress obliga a que cualquier código que se distribuya como parte de WordPress (plugins y temas incluidos) mantenga la misma licencia. En la práctica, esto significa que si desarrollas un plugin para WordPress y lo distribuyes, tu código tiene que ser GPL. Puedes venderlo, sí, pero cualquiera que lo compre tiene derecho a redistribuirlo gratis. Esta dinámica ha generado un ecosistema peculiar donde la confianza y el soporte son el verdadero producto, no el código en sí.

Con la MIT de EmDash, los plugins pueden tener la licencia que quiera el desarrollador. Si quieres hacer un plugin comercial con código cerrado, puedes. Si quieres usar MIT, también. Si quieres usar GPL, adelante. La elección es tuya, igual que cuando publicas un paquete en NPM o PyPI.

Cloudflare argumenta que esto libera a los desarrolladores del lock-in del ecosistema de WordPress, donde la GPL combinada con la necesidad de visibilidad en el directorio oficial crea una situación en la que muchos desarrolladores sienten que no tienen más remedio que regalar su código para existir.

Tiene su punto, y en parte estoy de acuerdo en que es al tiempo fortaleza y debilidad de WordPress, pero también hay que ver la otra cara, y es que la GPL de WordPress no ha sido solo una limitación, ha sido también un motor de crecimiento.

El hecho de que todo el código sea abierto y redistribuible ha creado un ecosistema donde miles de desarrolladores construyen sobre el trabajo de otros, donde puedes aprender mirando el código de cualquier plugin y donde la barrera de entrada para participar es muy baja. Eso no se consigue con licencia MIT por arte de magia, se consigue con comunidad, y la comunidad de EmDash ahora mismo no existe, y bajo ese modelo no tengo certezas pero tampoco dudas de que la tónica no será compartir mediante GPL.

Hay otro ángulo que se discute poco, y es que la GPL de WordPress genera una especie de contrato social, de manera que si yo desarrollo un plugin y lo publico, sé que cualquiera puede coger mi código, mejorarlo y redistribuirlo. Eso duele a veces, pero también significa que el conocimiento fluye y que la comunidad se beneficia del trabajo de todos.

Con MIT cada desarrollador puede cerrar su código y llevárselo a casa. Eso es más «libre» en el sentido empresarial, pero puede fragmentar el ecosistema. Mira lo que pasa con los paquetes de NPM, donde millones de librerías, muchas abandonadas, con licencias variadas y sin la cohesión que tiene el directorio de WordPress.

La MIT también facilita algo que Cloudflare menciona de pasada pero que tiene miga. Me refiero a cómo los plugins se ejecutan en un entorno de pruebas aislado y no comparten código con EmDash, no hay argumento posible para forzarles una licencia.

En WordPress la comunidad lleva años debatiendo si los plugins deben ser GPL obligatoriamente o no, y la respuesta oficial siempre ha sido que sí, porque comparten código con WordPress. EmDash corta ese debate de raíz por arquitectura.

La MIT es atractiva para empresas y desarrolladores comerciales, la GPL ha demostrado que funciona para construir un ecosistema masivo. Cuál es «mejor» depende de lo que valores más, pero la licencia sola no construye nada. lo que construye un ecosistema es la gente que participa en él, y esa gente de momento no está en EmDash.

El argumento de (falta de) seguridad de los plugins

La seguridad es el caballo de batalla del anuncio de Cloudflare, y le dedican más de un cuarto del texto y lo ponen en el mismo título. El argumento es que el 96% de las vulnerabilidades de seguridad en WordPress vienen de los plugins, y eso se debe a que un plugin de WordPress tiene acceso directo a la base de datos y al sistema de archivos del sitio, no hay aislamiento.

Cuando instalas un plugin le estás dando las llaves de toda la casa. Seguramente me habrás oído a mi mismo criticar el abuso de esto en ocasiones.

EmDash resuelve esto ejecutando cada plugin en su propio entorno de pruebas aislado mediante lo que Cloudflare llama Dynamic Workers (aislados V8). Un plugin declara en un manifiesto qué permisos necesita (leer contenido, enviar emails, acceder a una API externa en un dominio concreto) y solo puede hacer eso, nada más. Si un plugin está comprometido el daño se limita a lo que tenía permiso para hacer.

El concepto está bien. Desde el punto de vista de la arquitectura de software, un modelo de permisos explícitos y aislamiento por defecto es mejor que acceso total y confianza ciega, eso es difícil de discutir. Pero hay varios matices que Cloudflare pasa por alto.

El primero lo apuntó Matt Mullenweg en su respuesta (¿o pensabas que se iba a quedar callado?), y es que los plugins WordPress puedan tocar todo el sistema es una decisión de diseño, no un accidente.

La flexibilidad total de los plugins es lo que ha permitido que WordPress se adapte a prácticamente cualquier caso de uso. Desde tiendas online con WooCommerce hasta aplicaciones web complejas, pasando por intranets corporativas y sitios de membresía. Esa flexibilidad tiene un coste en seguridad, sí, pero también es la razón por la que WordPress sirve para tantas cosas.

Con el modelo de EmDash, un plugin solo puede hacer lo que declara en su manifiesto. Esto es más seguro, pero también es más limitado.

Muchos de los plugins más populares de WordPress necesitan acceso profundo al sistema para funcionar. Piensa en plugins de caché que modifican cómo WordPress genera las páginas, plugins de SEO que tocan prácticamente todo, plugins de seguridad que monitorizan el sistema de archivos, constructores de páginas que cambian cómo se renderiza el contenido.

Con un modelo de permisos estricto muchos de estos casos de uso son difíciles o imposibles de cubrir. Mullenweg lo resumió bien diciendo que el concepto de entorno de pruebas separado, o sandbox, se rompe en cuanto miras lo que hacen la mayoría de plugins en el mundo real.

El segundo matiz tiene que ver con las cifras, y es que Cloudflare dice que el 96% de las vulnerabilidades vienen de plugins, y es verdad. Pero según los datos de Patchstack solo el 17% de esas vulnerabilidades son de alta severidad, es decir, que se podrían explotar a gran escala de forma automatizada. La mayoría son de riesgo bajo o medio, afectan a plugins con pocas instalaciones y requieren condiciones específicas para ser explotadas.

La seguridad de plugins es un problema real de WordPress, pero presentarlo como una crisis generalizada que justifica cambiar de CMS es exagerar la situación.

Y el tercer matiz es el más gordo, y es eso de que el sandboxing de EmDash solo funciona en Cloudflare, por si no te habías dado cuenta.

Si ejecutas EmDash en un servidor Node.js cualquiera los plugins se ejecutan en el proceso principal sin aislamiento, exactamente como en WordPress pero sin su ecosistema de herramientas de seguridad (Wordfence, Sucuri, Patchstack…) ni sus dos décadas de parches y lecciones aprendidas.

La funcionalidad estrella del producto solo funciona si pagas. Los Dynamic Workers requieren una cuenta de pago de Cloudflare, desde 5 dólares al mes. ¡Sorpresa!

Te lo resumo en que sí, es código abierto pero con arquitectura cerrada. EmDash es técnicamente libre, pero su principal valor está atado a un único proveedor.

Mullenweg, por cierto, también dijo algo que me parece relevante, y es que cree que el problema de seguridad de plugins de WordPress se podrá resolver en los próximos 18 meses con IA (y se le olvidó decir que gracias al equipo de plugins). Hablamos de ayudas para la revisión automatizada de código, detección de vulnerabilidades en tiempo real, análisis estático más inteligente.

No sé si 18 meses es realista, o lo mismo se queda corto, pero tiene todo el sentido. Si WordPress resuelve el problema de seguridad de plugins sin necesidad de cambiar de CMS el argumento principal de EmDash se debilita mucho.

Hay un punto adicional que conviene mencionar, por si las dudas, y es que WordPress no está parado. El equipo de revisión de plugins procesa una cola de más de 800 plugins pendientes con tiempos de espera de al menos dos semanas, y eso es un cuello de botella claro.

Herramientas como Patchstack ya monitorizan vulnerabilidades en tiempo real, y hosting como Cloudflare (sí, el mismo Cloudflare que ahora lanza EmDash) o SiteGround aplican reglas de firewall específicas para WordPress que bloquean exploits conocidos antes de que lleguen al sitio.

La seguridad de WordPress no depende solo del código, depende de todo un ecosistema de protección que ha ido madurando con los años. Y sí, también gracias a esos (malísimos) plugins de seguridad para WordPress que se meten en tu sistema y … lo protegen.

Resuelve problemas de ingenieros, no de usuarios

Aquí es donde el análisis se pone interesante de verdad, porque toca la desconexión entre lo que EmDash ofrece y lo que la gente que usa un CMS necesita.

Cloudflare ha montado algo que resuelve los problemas que Cloudflare entiende mejor que nadie, la seguridad de plugins, escalado serverless, experiencia de desarrollo moderna, integración con IA. Todo eso tiene sentido si miras el mundo desde dentro de una empresa de infraestructura. Pero la persona que tiene un blog, una tienda online o la web de su restaurante no está pensando en aislamiento V8 ni en arquitectura serverless.

El usuario actual de WordPress, o cualquiera que necesite una solución de este tipo, un CMS, está pensando en responder emails, publicar en redes, actualizar su web, entender por qué ha bajado el tráfico y vender más. En esto estaremos de acuerdo que, siendo realistas, nada puede competir con WordPress y todo su enorme ecosistema y conocimiento acumulado.

Mira el anuncio de Cloudflare, de las más de 2.700 palabras, la inmensa mayoría hablan de arquitectura técnica, modelo de seguridad, compatibilidad con frameworks y estándares de pago. La parte que tiene que ver con lo que un usuario real hace con un CMS (publicar contenido, diseñar su web, gestionar su negocio) es mínima.

Y luego está la experiencia de uso real. EmDash no tiene un maquetador visual de páginas, usa TinyMCE como editor de texto, que es el editor clásico que WordPress dejó atrás en 2018 cuando lanzó Gutenberg. Mullenweg lo llamó «una regresión» y sugirió que deberían adoptar Gutenberg, que está liberado precisamente para que otros CMS lo usen.

La instalación requiere CLI y configuración técnica. No existe el famoso «instalar en 5 minutos» de WordPress, y por supuesto no vas a encontrar un instalador a 1 clic en todos los proveedores de hosting.

Luego, la interfaz de administración se parece a WordPress y no al mismo tiempo (será por eso lo del sucesor espiritual), pero con los bordes sin pulir de un producto en fase muy temprana. Sinceramente, esta parte me parece muy pobre, más viniendo de Cloudflare, hasta yo pongo más cuidado en la interfaz de mis plugins.

Es verdad que esto es temporal, y seguro que Cloudflare saca un instalador fácil desde su propia plataforma, y que la experiencia de usuario mejorará con el tiempo. Pero a día de hoy, EmDash es un producto para desarrolladores que se mueven cómodos con TypeScript, la terminal y el ecosistema de Cloudflare, para el resto de la gente, no está listo.

¿Es entonces EmDash una alternativa real a WordPress?

Ahora mismo no, ni de lejos.

Y no solo por cuestiones técnicas, que también, sino por una razón mucho más de fondo, que WordPress no es solo un CMS, es un ecosistema.

Son más de 60.000 plugins, miles de temas, agencias que viven de ello, freelances que dan de comer a sus familias con WordPress, empresas de hosting que han construido todo su negocio alrededor de WordPress, comunidades locales que organizan meetups y WordCamps.

Hay gente que lleva 15 o 20 años trabajando con WordPress y ha construido herramientas, conocimiento y relaciones dentro de esa comunidad. Esa gente no busca cambiar de motor, busca que el motor que ya tiene funcione mejor.

Lo escribí hace poco en un artículo sobre las alternativas con IA a WordPress, cuando alguien te vende la idea de que puedes crear tu web con IA y olvidarte de WordPress, casi siempre se está saltando la parte difícil, esas pequeñas cosas como el mantenimiento, el SEO, las actualizaciones, la seguridad, el soporte, las integraciones con terceros, la escalabilidad.

WordPress resuelve todas esas necesidades y problemas porque tiene 23 años de desarrollo y una comunidad enorme trabajando en ello.

EmDash tiene una arquitectura moderna, un modelo de seguridad interesante y el respaldo de una empresa potente. Pero EmDash no tiene comunidad, no tiene ecosistema, no tiene plugins, no tiene temas y no tiene los miles de tutoriales, foros y recursos que hacen que cualquiera pueda resolver cualquier problema con WordPress buscando cinco minutos en Google o en tu IA favorita.

¿Puede EmDash tener futuro?

Por supuesto, si Cloudflare invierte en serio, si atrae a desarrolladores, si la comunidad crece y si el producto madura, pero eso lleva años, no meses. Ghost, Craft y Statamic son CMS técnicamente excelentes que llevan años intentando crecer y ninguno ha conseguido construir un ecosistema comparable al de WordPress, y los tres tienen mucha más ventaja que EmDash en madurez de producto.

¿Para quién podría tener sentido EmDash ahora mismo?

Principalmente para desarrolladores de TypeScript que ya trabajan con Astro y Cloudflare, que quieren un CMS ligero para proyectos nuevos y que se sienten cómodos con un producto en beta temprana. Un nicho pequeño, pero tiene su sitio.

¿Para quién no tiene sentido EmDash?

Aquí la lista es enorme:

• Para cualquiera que tenga un sitio en WordPress y se esté planteando migrar.
• Para cualquiera que necesite un CMS listo para producción.
• Para cualquiera que dependa de plugins específicos de WordPress.
• Para cualquiera que quiera un constructor visual de páginas.
• Para la inmensa mayoría de la gente que usa un CMS para gestionar su negocio online.

Un detalle claro es que EmDash incluye herramientas para importar contenido desde WordPress (exportación WXR y un plugin exportador propio), eso te dice mucho sobre de dónde esperan que vengan sus usuarios.

Pero migrar contenido es la parte fácil, lo difícil es migrar la funcionalidad, me refiero a tus formularios de contacto, tu pasarela de pago, tu sistema de reservas, tu plugin de SEO con años de configuración, tus redirecciones, tus integraciones con email marketing. Todo eso no existe en EmDash y no va a existir en mucho tiempo.

WordPress tiene problemas a resolver, como la seguridad de plugins, la complejidad creciente, el rendimiento en hosting compartido, la guerra política interna que lleva arrastrando más de un año.

Pero la solución a esos problemas no es tirar WordPress a la basura y empezar de cero con un producto que tiene dos meses de vida, la solución es mejorar WordPress, y ahí es donde la energía de esta comunidad debería estar.

Me preocupa también el mensaje que hay detrás del lanzamiento, porque Cloudflare es una empresa que cotiza en bolsa y que gana dinero vendiendo infraestructura.

EmDash, por muy Open Source y MIT que sea, está diseñado para funcionar mejor en Cloudflare, es una herramienta para vender más servicios de Cloudflare. Y eso no es malo en sí mismo (las empresas viven de vender cosas), pero conviene tenerlo presente cuando lees la parte del «sucesor espiritual«.

El espíritu de WordPress es que funciona en cualquier sitio, desde un hosting barato hasta un servidor propio en tu garaje. El espíritu de EmDash es que funciona mejor si pagas a Cloudflare.

EmDash es un proyecto técnicamente interesante que merece seguirle la pista, pero llamarlo «sucesor espiritual de WordPress» es, como mínimo, prematuro. Y hasta aquí un mucho de información y un poco de mi opinión, ahora te toca a ti decidir.

Para que la cosa no quede aquí. ya tengo varios artículos más, ahora ya sí guías y tutoriales:

• Cómo instalar y empezar a usar EmDash
• Cómo migrar de WordPress a EmDash (y lo contrario)
• Qué es eso del x402 del que se habla en el proyecto EmDash

Y por si quieres verlo más en directo, también una presentación en vídeo y en directo:

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!