EmDash y Vinext salieron con horas de diferencia: el presupuesto de portabilidad que usamos antes de adoptar la pila de un proveedor

El 28 de septiembre de 2026, Cloudflare lanzó dos productos con dos horas de diferencia: EmDash 1.0, un CMS open source que pone tu capa de contenido sobre el runtime de Cloudflare, y Vinext 1.0, una herramienta que desacopla Next.js de cualquier plataforma. Uno profundiza en la pila; el otro te compra la salida. La respuesta correcta a los dos es la misma — no "cuál es mejor", sino un presupuesto de portabilidad: decidir de antemano cuánto de tu pila debe ser exportable, y probarlo con un test de salida antes de adoptar, no después de necesitar irte.

No es una respuesta evasiva. Es la única posición que resiste lo que pasó después: días después del lanzamiento, el fundador de WordPress, Matt Mullenweg, publicó un rebujo llamando a EmDash un vehículo para vender servicios de Cloudflare, mientras la cobertura de The Verge señalaba que nadie podía mostrar una forma limpia de exportar un sitio EmDash productivo fuera de Cloudflare. Ambas críticas apuntan al mismo punto ciego de toda agencia: los equipos evalúan lo que una pila hace el día uno y nunca precian lo que cuesta deshacerla.

Lo que salió el 28 de septiembre, y por qué el pareja importa

EmDash 1.0 salió a las 13:00 UTC. Es un CMS completo en TypeScript construido sobre Astro, con licencia MIT, y tres ideas hacen todo el trabajo pesado:

• Plugins en sandbox. Cada plugin corre en un runtime aislado — un Dynamic Worker en Cloudflare, un proceso hijo de workerd en Node.js — sin acceso al contenido, los medios, los secretos o la red del sitio salvo que un manifiesto declare una capacidad y el administrador la apruebe. El argumento es arquitectónico: Cloudflare cita los datos de Patchstack: el 96% de los problemas de seguridad de WordPress se originan en plugins, y solo 2025 produjo más vulnerabilidades de alta severidad en el ecosistema WordPress que los dos años anteriores combinados.
• Un registro que Cloudflare dice no poseer. Los paquetes de plugins se publican en el AT Protocol con registros firmados por el autor, así que el catálogo es un libro mayor firmado, no una tienda privada. Los servicios de agregación y moderación también son open source.
• Una superficie nativa para agentes. Un servidor MCP integrado, Agent Skills y un constructor de sitios con IA llamado EmDash Build — apuntado directamente a agencias que entregan sitios de cliente con IA en el medio.

Vinext 1.0 llegó a las 14:51 UTC: una herramienta que corre cualquier app de Next.js — Pages Router o App Router — sobre Vite, para que el mismo build se despliegue en Cloudflare Workers, Netlify o AWS Lambda. npx vinext check te dice si tu proyecto califica; npx vinext init lo convierte.

Misma empresa, mismo día, vectores opuestos. Un producto asume que tu capa de contenido vive en Cloudflare. El otro existe justamente para que un framework deje de asumir una plataforma. Que un proveedor lance los dos te dice exactamente dónde viven su apalancamiento y su miedo — y es la preparación más limpia posible para la pregunta que nos importa: ¿qué tan profunda puede ser la pila de un solo proveedor?

El argumento del lock-in, con la evidencia a favor de ambos

El rebujo de Mullenweg del 2 de abril al anuncio original de EmDash vale la pena leerlo más allá de los titulares: "Creo que EmDash se creó para vender más servicios de Cloudflare", escribió, y más filudo: "Si quieres adoptar un CMS que funcione de forma fluida con Cloudflare y que te haga difícil cambiar de proveedor algún día, EmDash es una opción increíble." Sobre la seguridad de plugins, sostiene que el poder sin restricciones de los plugins de WordPress es una característica, no un fallo — posición que Joost de Valk contrató con una analogía: es como argumentar que como una app del teléfono necesita la cámara, toda app debería tener root del teléfono.

La evidencia de Cloudflare no es marketing: el código es MIT, el sandbox de plugins demuestra que corre fuera de Cloudflare (mismos manifiestos, mismas APIs de capacidades, workerd como subproceso) y el protocolo del registro no está en manos de Cloudflare para revocarlo. Pero la cobertura de The Verge planteó la capa que open sourcear no resuelve: todavía no existe una ruta soportada para exportar un sitio en vivo completo — contenido, enlaces a medios, configuración de caché, enrutamiento — y aterrizarlo sin cambios en otro lado.

Ambos tienen razón en capas distintas, y esa es toda la lección:

La licencia te habla de la capa uno. El lock-in vive en las capas dos y tres. Casi todo argumento de "es open source, no hay lock-in" — de cualquier proveedor — deja de contar discretamente en la capa uno.

El presupuesto de portabilidad: tres capas, un test de salida

Preciamos las decisiones de pila en tres capas antes de recomendar nada a un cliente. Cada capa recibe un presupuesto explícito — cuánto de ella podemos amarrar al proveedor — y cada capa tiene una prueba, no una promesa.

1. Portabilidad del contenido. ¿Puedo sacar cada entrada como archivos estructurados o JSON hoy mismo, con el esquema intacto, sin pedir permiso? El contenido es la capa sin reemplazo: las plantillas se reescriben, los plugins se cambian, pero un modelado de contenido mal hecho multiplica cada salida futura.
2. Portabilidad del código. ¿Viven las plantillas y componentes en un repositorio que yo controlo, y compilan con la cuenta del proveedor desconectada? Si la respuesta requiere el build pipeline del proveedor, no tienes portabilidad de código; tienes una copia de respaldo.
3. Portabilidad del runtime. ¿La cosa corre de verdad — mismo comportamiento, plugins incluidos — en un runtime que el proveedor no controla? El camino Node.js de EmDash es la mejor respuesta que cualquier CMS ha dado a esta pregunta, pero "corre" y "corre igual a escala" son afirmaciones distintas, y la migración propia de Cloudflare es la prueba: su blog necesitó Workers Cache y un object cache sobre KV para sentirse bien.

El test de salida son cuatro preguntas escritas que exigimos antes de aprobar una pila:

• ¿Cuál es el comando de exportación y cuánto tarda sobre un dataset completo?
• ¿Qué servicios de esta pila tienen equivalente de pago solo en este proveedor?
• ¿Qué se rompe primero si este proveedor desaparece mañana?
• ¿Quién del equipo lo ha corrido en otro lado?

Los equipos que no pueden responder la pregunta dos por escrito ya la respondieron: nadie preció la salida.

Cómo lo aplicamos a nuestra propia pila — y cuándo elegiríamos EmDash igual

mintec.co es un build estático de Astro: el contenido vive como archivos Markdoc en un repositorio Git, editado desde un admin de Keystatic, desplegado en Cloudflare Pages, sin base de datos en runtime. Portabilidad de contenido y de código pasan sin esfuerzo, y la capa de runtime son archivos estáticos que cualquier CDN sirve. No es superioridad moral — es una decisión de presupuesto. Nuestro sitio es content-driven, y hemos visto lo que cuestan las salidas de verdad: nuestra migración de WordPress a Astro cubrió 2.500+ páginas en tres idiomas, y solo la migración de contenido tomó 8 días hábiles contra un presupuesto de 3 (el TTFB pasó de 680ms a 98ms y Lighthouse de 38 a 97 — la ganancia fue real, el asiento de eyección salió caro). Priorizamos la portabilidad de contenido precisamente porque es la capa más lenta de deshacer.

Tampoco coincidimos por reflejo con el encuadre anti-EmDash. Si estás manejando un sitio de cliente con varios editores, un ecosistema de plugins, publicación programada y agentes que empujan actualizaciones por un servidor MCP, la convergencia de EmDash te compra cosas reales: ningún plugin PHP con root de base de datos, ninguna factura de CMS por usuario, ningún hosting separado para la capa de admin. Ese es exactamente el perfil donde elegiríamos un CMS con capacidades agénticas antes que uno basado en archivos — y donde el problema de sobre-compra composable-vs-headless que ya escribimos apunta al otro lado: compra la plataforma, acepta el acoplamiento, pero firma el test de salida al momento del contrato.

Para sitios content-driven que nunca necesitan un marketplace de plugins, el patrón local-first sigue ganando en costo y salida — es la capa a la que volvemos por defecto, y es lo que corrermos nosotros mismos. Y cuando la pregunta es más estrecha — ¿debería esta app quedarse en Cloudflare o no — ya publicamos el framework que usamos para decidir si mover mintec.co fuera de Pages, donde la dirección de la plataforma importó más que su precio.

El cierre

EmDash es el intento más creíble de reemplazo de WordPress que alguien ha lanzado, y su sandbox de plugins resuelve un problema real de arquitectura de seguridad respaldado por datos. También está optimizado para un proveedor cuyo negocio es venderte el runtime, y hoy no tiene una salida directa. Esas dos frases no se contradicen — ese es justamente el punto de un presupuesto de portabilidad. Decide qué capas estás dispuesto a amarrar, escribe el test de salida antes del contrato, y trata a cualquier proveedor — Cloudflare, Sanity, Vercel, a nosotros — que argumente que el lock-in solo vive en la capa de la licencia como si estuviera respondiendo una pregunta distinta a la que hiciste.