La adquisición de Deno por parte de Cloudflare significa que los usuarios de Deno Deploy deben trasladar sus cargas de trabajo de producción antes de que el servicio de alojamiento cierre alrededor de abril de 2027. Cloudflare Workers es el destino compatible para los clientes de pago, pero la migración no es automática: los equipos deben auditar las API de Deno, las dependencias, las variables de entorno, la semántica del almacenamiento y las pruebas. El entorno de ejecución independiente de Deno tendrá un plazo más amplio, mientras que JSR seguirá en línea.
¿Qué adquirió Cloudflare de Deno?
Cloudflare y Deno anunciaron el 9 de octubre de 2026 que todo el equipo de Deno se incorporaría a Cloudflare, con unas condiciones económicas no reveladas. Cloudflare clasificó el acuerdo como una adquisición. Los ingenieros trabajarán con los equipos de Cloudflare Workers y Durable Objects, incluidos los esfuerzos para combinar los proyectos workerd y celld.
La adquisición de Deno por parte de Cloudflare es principalmente un acuerdo sobre el equipo y la tecnología, no una promesa de conservar todos los productos de Deno. Cloudflare quiere ampliar el modelo de programación de Workers, incluidas las implementaciones autogestionadas, mientras que Deno señaló el estado persistente, los WebSockets y la ejecución serverless de bajo coste para agentes de IA como áreas de interés.
Deno también declaró en su anuncio del 9 de octubre de 2026 que seguiría dando soporte a rusty_v8 y trabajaría para integrar el proyecto con el runtime workerd de Cloudflare. Estos planes pueden influir en las futuras herramientas para desarrolladores, pero Cloudflare no había publicado un calendario detallado de integración a 13 de octubre de 2026.
La distinción es importante. Los desarrolladores obtienen una dirección estratégica, no una garantía general de compatibilidad. Los equipos que utilicen dependencias generadas también deberían revisar los riesgos de seguridad creados por cadenas de dependencias escritas por IA mientras hacen inventario de los paquetes para el traslado.
¿Cuándo cerrarán Deno Deploy y el runtime de Deno?
Deno Deploy funcionará durante seis meses después del anuncio del 9 de octubre de 2026, lo que implica un cierre alrededor del 9 de abril de 2027. Deno no ha anunciado una fecha exacta de cierre. En cambio, el runtime independiente de Deno recibirá durante un año versiones mensuales de seguridad y correcciones de errores, lo que implica que el equipo actual seguirá desarrollándolo aproximadamente hasta el 9 de octubre de 2027.
Deno Deploy es la plataforma de alojamiento gestionado que ejecuta aplicaciones de Deno sin que los equipos tengan que administrar sus propios servidores. Su fecha límite es la urgente: el tráfico de producción, las tareas programadas, el almacenamiento y los secretos necesitan un sustituto antes de que desaparezca el servicio.
El runtime independiente es diferente. Su código fuente seguirá siendo abierto, y el alojamiento autogestionado en una máquina virtual o un contenedor seguirá siendo técnicamente posible durante el periodo de soporte. Sin embargo, una vez finalizado el compromiso de un año, el equipo actual de Deno dejará de desarrollar el runtime. Podría surgir un fork comunitario, pero ningún plan de producción debería dar por hecho ese resultado.
| Producto | Compromiso publicado | Fecha límite práctica | Acción requerida |
|---|---|---|---|
| Deno Deploy | Seis meses más desde el 9 de octubre de 2026 | Alrededor del 9 de abril de 2027; fecha exacta no anunciada | Trasladar el alojamiento, los datos, la configuración y el tráfico |
| Runtime de Deno | Un año de correcciones mensuales desde el 9 de octubre de 2026 | Alrededor del 9 de octubre de 2027; versión final exacta no anunciada | Elegir un runtime mantenido o asumir el mantenimiento propio |
| Registro JSR | Seguirá operativo después del 9 de octubre de 2026 | No hay ningún cierre programado en 2026 | Probar los consumidores en los runtimes de destino |
Un sencillo cálculo de calendario deja patente el riesgo: un equipo que empiece en enero de 2027 solo tendría unos tres meses antes de la fecha límite implícita de Deno Deploy. Reserva tiempo para un ensayo de datos y una ventana de reversión, en lugar de tratar abril de 2027 como el inicio de la migración.
¿A qué deben migrar los usuarios de Deno Deploy en Cloudflare Workers?
Los usuarios de Deno Deploy deben migrar el código de la aplicación, la configuración, los secretos, las tareas programadas, las conexiones con servicios y los datos persistentes antes de aproximadamente abril de 2027. Según el anuncio de Deno de 2026, los clientes de pago recibirán asistencia para migrar a Cloudflare Workers, pero a 13 de octubre de 2026 no se había anunciado ninguna utilidad pública ni garantía general de conversión de cargas de trabajo.
Empieza por hacer inventario, no por reescribir. El código basado en Fetch, Request, Response, Web Crypto y los módulos ECMAScript estándar se traslada con mayor facilidad. Las llamadas al espacio de nombres Deno.* el acceso al sistema de archivos, los subprocesos y el modelo de permisos de Deno requieren una revisión más minuciosa porque Cloudflare Workers sigue un modelo de ejecución y seguridad diferente.
La adquisición de Deno por parte de Cloudflare también cambia la forma en que las aplicaciones reciben la configuración. El código de Deno Deploy suele llamar a Deno.env.get(). Workers normalmente pasa las variables, los secretos y los recursos de servicio mediante la vinculación env del gestor de solicitudes; process.env está disponible en los escenarios aplicables de compatibilidad con Node.js.
La documentación de Cloudflare de 2026 indica que cada entorno de Wrangler necesita sus propias variables y vinculaciones porque no se heredan. Esta regla, fácil de pasar por alto, puede producir una implementación de staging que funciona y una implementación de producción con recursos ausentes.
Utiliza la siguiente secuencia de migración para mantener visibles los cambios de la aplicación, los datos y las operaciones:
- Inventario
espacio de nombres Deno.*API, permisos, llamadas al sistema de archivos y a subprocesos, paquetes de npm y JSR, variables de entorno, secretos, tareas de cron, colas, bases de datos y almacenamiento de objetos. - Sustituye las llamadas específicas de la plataforma por interfaces propiedad de la aplicación antes de elegir servicios equivalentes de Workers.
- Crea variables de Workers para la configuración no secreta, carga los valores sensibles como secretos y declara las vinculaciones por separado en cada entorno de Wrangler.
- Exporta los datos de producción, ensaya las importaciones transformadas y conserva exportaciones para la reversión antes de cambiar el DNS o dirigir el tráfico.
- Ejecuta las pruebas unitarias, de integración y de dependencias dentro del runtime de Workers y, después, utiliza tráfico en sombra o lecturas duales cuando la carga de trabajo lo permita.
Cloudflare recomienda su integración de Vitest para Workers para las pruebas unitarias y createTestHarness() para las pruebas de integración en 2026. Las pruebas pueden ejecutarse dentro del entorno de Workers y probar directamente los enlaces configurados. Esto resulta más útil que una suite de pruebas exclusiva de Node.js que nunca interactúa con el entorno de destino.
¿Puede ejecutarse código de Deno sin cambios en Cloudflare Workers?
El código de Deno puede ejecutarse sin cambios en Cloudflare Workers únicamente cuando se mantiene dentro de los estándares web compatibles y utiliza dependencias admitidas. La documentación de Cloudflare de 2026 describe la compatibilidad de Workers con Node.js como un subconjunto: algunas API están implementadas por completo, otras parcialmente y ciertos polyfills del empaquetador pueden generar errores al invocarse. Por tanto, las pruebas a nivel de API son obligatorias.
La instalación de paquetes requiere especial atención. Los paquetes de JSR pueden ejecutarse en Workers mediante la capa de compatibilidad con npm de JSR, pero los jsr: especificadores de importación generalmente necesitan convertirse en dependencias instaladas mediante un gestor de paquetes. La documentación de JSR de 2026 indica que debes confirmar el archivo generado .npmrc.
La capa de compatibilidad instala JavaScript transpilado en lugar de TypeScript nativo y no admite publicar con npm publish. Los mantenedores de paquetes deben seguir utilizando jsr publish o deno publish. JSR no tiene previsto cerrar; su infraestructura se trasladará a Cloudflare.
La compatibilidad de las dependencias supone un riesgo mayor que la sintaxis. Una biblioteca puede instalarse correctamente y, aun así, llamar a una API de Node.js parcialmente compatible solo bajo carga o durante una ruta de error poco habitual. Los equipos que adopten asistentes que generan código deberían aplicar el mismo análisis de paquetes que se explica en nuestra guía sobre cómo los agentes de programación de IA están cambiando el desarrollo de software.
Mi opinión: reescribir código portable basado en estándares web sería una pérdida de tiempo. Aísla primero los puntos específicos del entorno de ejecución y, después, migra un límite cada vez. Este enfoque también conserva una vía de salida si los precios, los límites o la dirección del producto de Workers dejan de encajar con el servicio.
¿Cómo deberían trasladarse los datos de Deno KV al almacenamiento de Cloudflare?
Deno KV no tiene un destino automático equivalente en Cloudflare Workers, según las directrices de migración de Deno de 2026. Los equipos deben seleccionar el almacenamiento según el comportamiento: Workers KV para datos con muchas lecturas y consistencia eventual, Durable Objects para estados transaccionales con consistencia fuerte, D1 para datos relacionales basados en SQLite o R2 para objetos compatibles con S3.
Los nombres pueden inducir a error en este caso. Workers KV no es un sustituto semántico directo simplemente porque ambos productos contengan «KV». Trasladar bloqueos de coordinación, contadores o comprobaciones de unicidad a un almacén con consistencia eventual puede provocar fallos de corrección que las pruebas habituales de casos favorables no detecten.
Durable Objects encaja mejor cuando los datos y la coordinación deben tener una consistencia fuerte, pero introduce enlaces específicos de Cloudflare y un modelo de estado orientado a objetos. D1 es adecuado para consultas relacionales. R2 gestiona el almacenamiento de objetos, mientras que Hyperdrive puede conectar Workers con bases de datos externas compatibles.
Exporta primero. Transforma después. A continuación, compara el número de filas, el número de claves, los valores de una muestra y las invariantes a nivel de aplicación después de la importación. En un almacén con 10 millones de registros en 2026, incluso un error de conversión del 0.01% implica 1.000 registros incorrectos, por lo que una validación basada únicamente en porcentajes puede ocultar daños importantes.
El alojamiento autónomo basado en contenedores evita una reescritura inmediata de la aplicación, pero transfiere a tu equipo la aplicación de parches, la supervisión y la seguridad del host. Esta compensación operativa es especialmente relevante al analizar amenazas como agentes maliciosos que atacan hosts de Docker.
¿Qué ruta de migración se adapta a cada tipo de proyecto de Deno?
La respuesta adecuada a la adquisición de Deno por parte de Cloudflare depende del tipo de despliegue. Los usuarios de Deno Deploy necesitan un alojamiento de sustitución antes de aproximadamente abril de 2027; los equipos que utilizan el entorno de ejecución independiente disponen aproximadamente hasta octubre de 2027 para elegir una opción mantenida; los publicadores que solo usan JSR pueden continuar, pero deberían probar por separado la compatibilidad con Cloudflare Workers, Node.js y los navegadores.
Aplicaciones de Deno Deploy
Cloudflare Workers es la ruta compatible para los clientes de pago y probablemente el camino operativo más corto. Aun así, identifica todos los enlaces y las garantías de almacenamiento antes de comprometerte. El alojamiento autónomo de Deno puede dar margen, pero convierte la migración de plataforma en un problema de infraestructura y de mantenimiento futuro del entorno de ejecución.
Servicios independientes de Deno
Fija una versión conocida de Deno, aplica las versiones mensuales prometidas durante el periodo de mantenimiento de 2026–2027 y decide pronto entre Node.js, Bun, otro entorno de ejecución mantenido o un mantenimiento autónomo deliberado. Coloca las funciones específicas de Deno detrás de adaptadores para que la lógica de negocio no dependa directamente de un único espacio de nombres.
Publicadores de paquetes de JSR
Los publicadores de JSR no necesitan abandonar el registro. Sí necesitan pruebas de compatibilidad independientes para Workers, Node.js y los navegadores, porque publicar correctamente en JSR no dice nada sobre la compatibilidad de las API exclusivas de Deno en otro entorno de ejecución.
La dependencia de un proveedor no es automáticamente negativa. Durable Objects, D1 y R2 pueden eliminar una parte considerable del trabajo de infraestructura. Integrarse profundamente con Cloudflare tiene sentido cuando el ahorro operativo supera el coste futuro de sustituir esos enlaces; de lo contrario, mantén el código central del dominio basado en estándares web y limita las llamadas a la plataforma a adaptadores estrechos.
Preguntas frecuentes
¿Va a cerrar Cloudflare JSR?
Cloudflare no va a cerrar JSR según los planes anunciados el 9 de octubre de 2026. Deno afirmó que el registro de paquetes seguiría funcionando y que su infraestructura se trasladaría a Cloudflare.
¿Migrará Cloudflare automáticamente los proyectos de Deno Deploy?
No se había garantizado públicamente ninguna migración automática a fecha del 13 de octubre de 2026. Deno prometió asistencia para la migración de los clientes de pago de Deno Deploy que se trasladaran a Cloudflare Workers, pero los equipos aún deben validar el código, los enlaces, las dependencias y los datos.
¿Pueden los desarrolladores seguir alojando Deno por su cuenta después de 2027?
Los desarrolladores pueden seguir ejecutando el código de código abierto de Deno después de que finalice el periodo de mantenimiento anunciado, alrededor de octubre de 2027. El equipo actual de Deno no se ha comprometido a continuar el desarrollo más allá de ese periodo, por lo que el mantenimiento de seguridad y la compatibilidad pueden depender de colaboradores externos.
¿Admite Cloudflare Workers todas las API de Node.js?
Cloudflare Workers no admite completamente todas las API de Node.js en 2026. Cloudflare documenta implementaciones completas, implementaciones parciales y polyfills del empaquetador que pueden generar errores al invocarse, por lo que las dependencias de producción requieren pruebas en el entorno de ejecución.