Alternativas a Deno Deploy: qué plataforma elegir en 2026

Entre las alternativas a Deno Deploy, Cloudflare Workers es la primera que conviene evaluar: Deno la señala como destino de migración y anuncia que Deploy seguirá funcionando durante 6 meses más. Elige Netlify para un sitio con lógica en el edge basada en Deno, Supabase Edge Functions para una API respaldada por una base de datos, Vercel Functions para una aplicación cuyo framework marque el camino, o Val Town para tareas programadas pequeñas. Si tu aplicación utiliza Deno KV, decide primero cómo sustituirlo y después dónde ejecutar las funciones.

Precios y documentación verificados el 12 de octubre de 2026. Esta comparativa se basa en precios públicos, condiciones de ejecución y trabajo de migración; no incluye pruebas de despliegue con una sesión iniciada. El plazo de cierre procede del anuncio de Deno del 9 de octubre.

Alternativas a Deno Deploy: comparativa rápida

Busca el destino que conserve el comportamiento de tu aplicación y te deje menos cambios que mantener. Migrar un endpoint TypeScript que consulta una base de datos externa tiene poco que ver con trasladar una aplicación cuyas transacciones, tareas programadas y colas dependen por completo de Deno Deploy.

Los planes se documentan en Cloudflare, Netlify, Supabase, Vercel, Val Town, sus preguntas frecuentes sobre facturación y los precios de VPS de DigitalOcean. Son precios de entrada, no una garantía del importe total de tu factura mensual.

Qué anunció Deno y cómo interpretar los plazos

Deno Deploy va a cerrar; el runtime de Deno tiene un plazo de mantenimiento distinto. En el anuncio del 9 de octubre de 2026, Ryan Dahl escribió:

Deno Deploy seguirá funcionando durante seis meses antes de cerrar.

El mismo anuncio promete asistencia para los clientes de pago que migren a Cloudflare Workers. También se compromete a publicar durante otro año versiones mensuales del runtime de Deno con correcciones de errores y actualizaciones de seguridad; después, Deno dejará de desarrollarlo. El runtime seguirá siendo de código abierto. JSR, el registro de paquetes de JavaScript y TypeScript, continuará funcionando y trasladará su infraestructura a Cloudflare. Lee el anuncio de Deno.

Deno comunica plazos, no una fecha exacta de cierre. No conviertas el anuncio en una fecha límite inventada ni confundas el periodo de mantenimiento más largo del runtime con tiempo adicional para usar Deploy. Si eres cliente de pago, aprovecha la asistencia de migración y planifica juntos el traslado de la aplicación y el de sus datos.

1. Cloudflare Workers: por dónde empezar a evaluar la migración

Cloudflare Workers es una plataforma gestionada para ejecutar manejadores de solicitudes y tareas en segundo plano. Es la primera candidata porque Deno dirige expresamente a sus clientes hacia ella. Para quien tiene una API TypeScript, una base de datos externa y una tarea de limpieza programada, el trabajo principal consiste en adaptar las interfaces con el runtime y la configuración de despliegue. Una aplicación construida alrededor de Deno KV necesita, además, rediseñar el almacenamiento. Elige Workers como plataforma de destino, pero reserva presupuesto para las partes específicas de Deno que habrá que adaptar.

Ideal para: APIs, webhooks, tareas cron, colas y sitios que se beneficien de una infraestructura gestionada.
Punto fuerte: Es el destino de migración indicado por Deno e incluye servicios de almacenamiento y programación de tareas.
Precios: Workers Free; Workers Paid tiene un mínimo de $5 USD/mes por cuenta; el consumo de Enterprise se rige por su contrato.
Prueba gratuita: El plan permanente Workers Free permite evaluar el servicio sin costo.
Esfuerzo de migración: Bajo o medio para manejadores sin estado; alto si hay que rediseñar transacciones de KV y tareas en cola.

Qué cambia en tu código TypeScript

Workers utiliza el runtime workerd, no el de Deno, y no proporciona el espacio de nombres global Deno. Las interfaces web estándar, como Request, Response y fetch, ofrecen una buena base para portar el código. En cambio, Deno.serve, Deno.env, Deno.openKv y Deno.cron señalan las interfaces que tendrás que sustituir. La compatibilidad con Node.js también cubre solo una parte de sus APIs: que un paquete se importe sin errores durante el desarrollo no demuestra que sus dependencias funcionen al ejecutarlo. APIs del runtime de Workers.

Wrangler es la herramienta de línea de comandos de Cloudflare para desplegar aplicaciones. El propio tutorial de Wrangler de Deno explica cómo conservar Deno en las herramientas de desarrollo: añadir npm:wrangler, generar los tipos de Workers, exportar un módulo con un manejador fetch y empaquetar con esbuild y el complemento de Deno cuando necesites su resolución de módulos. Preparar el código con Deno no convierte al Worker desplegado en un proceso de Deno.

Traslada los secretos y el acceso a recursos a bindings, las referencias configuradas que permiten a un Worker acceder a su base de datos, su cola o sus valores de entorno. Revisa tanto las dependencias como los archivos de la aplicación: una utilidad puede ocultar una llamada al sistema de archivos aunque el manejador de tu ruta solo use APIs web. Bindings de Cloudflare.

Sustituye cada servicio según su comportamiento

La diferencia decisiva está entre Workers KV y Deno KV. Workers KV favorece las lecturas frecuentes y las escrituras relativamente poco frecuentes; las lecturas en caché pueden devolver datos desactualizados. Que ambos se llamen KV no basta para migrar reservas de inventario, saldos de cuentas o comprobaciones atómicas de unicidad. Cómo funciona Workers KV.

D1 es la vía SQL: convierte los prefijos de claves y los índices secundarios en un esquema diseñado para esos datos. Su API por lotes ejecuta sentencias dentro de una transacción, pero no traduce automáticamente una comprobación optimista de Deno. Durable Objects combina estado con una instancia de cómputo que lo coordina; merece atención cuando una entidad, como una sala o una cuenta, necesita coordinación serializada. Transacciones en D1, Durable Objects.

Para las tareas programadas, Cron Triggers utiliza un manejador scheduled y horarios en UTC. Para el trabajo diferido, Queues aporta el sistema de mensajería. Una programación indica cuándo empezar; una cola conserva el trabajo pendiente de procesar. Sustituir una no sustituye la otra. Los sitios estáticos pueden usar Workers Static Assets, manteniendo sus archivos generados separados de la lógica dinámica de las solicitudes.

Cuánto cuesta y dónde están los límites

Workers Free incluye 100,000 solicitudes al día y 10 ms de CPU por invocación. Paid incluye 10 millones de solicitudes y 30 millones de milisegundos de CPU al mes; después cobra $0.30 por cada millón adicional de solicitudes y $0.02 por cada millón adicional de milisegundos de CPU. También hay que presupuestar el consumo de bases de datos, colas y otros productos. Precios vigentes de Workers.

El tamaño del paquete ya no basta por sí solo para justificar Paid: tanto Free como Paid admiten 64 MiB sin comprimir, mientras que la memoria sigue en 128 MB. Revisa los límites vigentes y nuestra explicación sobre el tamaño del paquete y el paso al plan de pago. El análisis de Cloudflare explica cómo encajan los distintos productos de la cuenta.

1. 1

   Identifica las dependencias del runtime

   Localiza las llamadas al espacio de nombres de Deno, las importaciones por URL, el acceso al sistema de archivos, los secretos, las operaciones KV, las tareas programadas y los consumidores de colas. Separa la lógica de negocio portable de esos adaptadores.

2. 2

   Prepara el punto de entrada para Workers

   Sigue el tutorial de Wrangler de Deno: configura el manejador del módulo y los tipos generados de Workers; después prepara la compilación personalizada compatible con Deno si tus importaciones la requieren. Conserva el contrato de respuesta existente mientras cambias la forma de invocar el manejador.

3. 3

   Configura el estado y los disparadores de forma explícita

   Elige la base de datos antes de importar registros. Añade los bindings, traslada las programaciones a Cron Triggers y reescribe los productores y consumidores de colas. Documenta qué ocurre si una tarea vuelve a entregarse.

4. 4

   Ensaya antes de redirigir el tráfico

   Utiliza datos de prueba locales y un entorno de destino separado para comparar códigos de estado, cabeceras, autenticación y cambios de estado. Desplegar el código es solo una de las comprobaciones: los datos y las tareas en segundo plano deben estar listos para el mismo cambio de plataforma.

2. Netlify: para sitios con lógica ligera en el edge basada en Deno

Netlify es una plataforma de despliegue web con Edge Functions basadas en Deno. Encaja cuando el trabajo dinámico del sitio gira en torno a las solicitudes entrantes: localización, comprobaciones de autenticación, redirecciones o personalización ligera. Mantener esa lógica junto a las vistas previas de despliegue del sitio puede resultar más útil que adoptar otro modelo de infraestructura. Un manejador sin estado en el edge es un candidato razonable para migrar; un backend que dependa mucho de colas exige separar más componentes. Elige Netlify cuando el sitio web sea el producto y la lógica en el edge esté a su servicio. Descripción de Edge Functions.

Ideal para: Sitios estáticos y aplicaciones web con lógica ligera de solicitudes basada en Deno.
Punto fuerte: Edge Functions que se despliegan con el sitio, con vistas previas y reversión de despliegues.
Precios: Free $0 para siempre; Personal $9/mes; Pro $20/mes con miembros ilimitados; Enterprise a medida.
Prueba gratuita: Free incluye un límite mensual de 300 créditos.
Esfuerzo de migración: Bajo o medio para un sitio con lógica sin estado en el edge; mayor cuando hay que separar el almacenamiento, las tareas programadas y los consumidores de colas.

El runtime resulta familiar, pero cambia la interfaz de la aplicación

Una Edge Function utiliza el manejador y el contexto de Netlify. Revisa también las importaciones: Netlify documenta un archivo de mapa de importaciones independiente, en lugar del mapa incluido en deno.json, y describe el soporte de paquetes npm como beta. Es una tarea concreta de migración si el proyecto resuelve actualmente sus dependencias mediante la configuración de Deno. API de Edge Functions.

Los límites de ejecución son 50 ms de CPU por solicitud y 40 segundos para devolver las cabeceras de respuesta. Esperar a un servicio remoto y transformar un documento grande consumen recursos distintos. Una consulta de autenticación puede encajar en una función ligera en el edge; un procesamiento intensivo de CPU necesita otra vía de ejecución. Límites de Edge Functions.

Cómo sustituir Deno KV, cron y las colas

Usa Netlify Blobs para contenido al que tenga sentido acceder por clave, y Netlify Database, su servicio Postgres, cuando la aplicación necesite datos relacionales y actualizaciones transaccionales. Blobs ofrece lecturas con consistencia fuerte opcionales, pero eso por sí solo no reproduce la API atómica de múltiples claves de Deno KV. El nuevo diseño de almacenamiento debe conservar las reglas de negocio, como impedir nombres de usuario duplicados.

Scheduled Functions es una función independiente de Netlify Functions. Incluir Deno.cron en una Edge Function no le proporciona automáticamente una programación gestionada. Extrae la tarea, configura su programación y revisa su runtime por separado. Si la tarea anterior consume una cola de Deno KV, identifica expresamente el almacén persistente de mensajes y su consumidor; programar una función no traslada los mensajes en cola.

Para quien mantiene un sitio de contenidos y una tarea de sincronización cada hora, esta separación es manejable: la entrega del sitio y la personalización quedan en la plataforma web, mientras que la sincronización recibe su propia función programada y su estado persistente. Resulta menos atractiva si la mayor parte de la aplicación son procesos en segundo plano que dependen entre sí.

Calcula el costo de los créditos y del equipo

Personal incluye 1,000 créditos/mes. Los niveles de créditos de Pro son 3,000 por $20, 5,000 por $33, 10,000 por $63, 15,000 por $95 y 20,000 por $126, al mes. Los niveles superiores, a partir de 5,000 créditos, permiten trasladar los créditos mensuales no utilizados al siguiente ciclo de facturación; el nivel base no. Niveles de créditos vigentes de Netlify.

La recarga automática viene desactivada. Al activarla, Personal puede añadir 500 créditos por $5 y Pro 1,500 por $10. Agotar los créditos de la cuenta sin añadir más puede pausar sus proyectos, así que un lanzamiento público exige decidir tanto cómo desplegar como cuánto gastar. No confundas estos planes actuales por créditos con los antiguos precios de Netlify por miembro.

3. Supabase Edge Functions: para APIs respaldadas por una base de datos

Supabase Edge Functions son funciones TypeScript que se ejecutan en un runtime compatible con Deno. Encajan especialmente bien cuando la migración incluye una decisión firme de pasar a Postgres, una base de datos relacional. Una aplicación de suscripciones que recibe webhooks de pago y actualiza registros de clientes tiene aquí un destino natural. El runtime conocido reduce una parte de los cambios, mientras que el diseño de la base de datos pasa a ser el trabajo principal. Elige Supabase cuando los datos persistentes de la aplicación determinen la arquitectura. Documentación de Functions.

Ideal para: Webhooks y APIs que deban convivir con Postgres, autenticación y almacenamiento de archivos.
Punto fuerte: Funciones compatibles con Deno integradas en una plataforma de bases de datos.
Precios: Free $0/mes; Pro desde $25/mes; Team desde $599/mes; Enterprise a medida.
Prueba gratuita: Free incluye 500,000 invocaciones de Edge Functions y una base de datos de 500 MB por proyecto.
Esfuerzo de migración: Medio para manejadores compatibles; alto si Deno KV debe convertirse en un esquema relacional con nueva lógica transaccional.

Migra el modelo de datos junto con el endpoint

Sustituye las llamadas a Deno KV por acceso a Postgres. Un prefijo que agrupa los elementos guardados por un usuario se convierte en una relación consultable; una comprobación de unicidad, en una restricción o transacción de la base de datos. No conserves una colección de cadenas de claves opacas solo para simplificar en apariencia la importación si todas las consultas importantes van a tener que decodificarlas de inmediato.

Por ejemplo, un manejador de pagos puede necesitar registrar un evento y actualizar un derecho de acceso en una misma operación. El criterio de aceptación es que los reintentos no puedan conceder ese derecho dos veces. Que la nueva función devuelva una respuesta HTTP correcta no demuestra que esa regla haya sobrevivido al cambio de almacenamiento.

Supabase también ofrece Cron, que puede ejecutar operaciones de base de datos o invocar una Edge Function, y Queues, mensajería persistente respaldada por Postgres. Sustituye de forma explícita el registro de Deno.cron y el código que encola y consume mensajes de Deno KV por esos servicios. Define cómo se confirma la recepción de los mensajes y cuándo una tarea fallida vuelve a estar disponible para otro intento.

Límites de ejecución y factura inicial completa

Edge Functions permite 256 MB de memoria y 2 segundos de CPU por solicitud. La duración total máxima del worker es de 150 segundos en Free y 400 segundos en los planes de pago, pero ese tiempo adicional no amplía el presupuesto de CPU. Son límites distintos, no formas intercambiables de describir un worker de larga duración. Límites de las funciones.

Pro y Team incluyen 2 millones de invocaciones de funciones y después cobran $2 por cada millón adicional. Free permite 2 proyectos activos y pausa los proyectos inactivos después de 1 semana. Los planes de pago incluyen un crédito de cómputo de $10/mes que cubre una instancia Micro. Precios de Supabase.

Supabase resulta menos adecuado para alojar el frontend estático del sitio. La documentación de límites de sus funciones indica que servir HTML requiere un dominio personalizado; de lo contrario, una respuesta text/html se convierte en text/plain. Decide el alojamiento del frontend por separado del de la API.

4. Vercel Functions: cuando el framework web determina la migración

Vercel Functions son funciones gestionadas del lado del servidor que forman parte de un despliegue web. Encajan cuando el framework del frontend y el flujo de publicación son los motivos principales para cambiar de plataforma. Si ya estás reorganizando la aplicación alrededor de un framework compatible con Vercel, trasladar las rutas de la API a esa estructura puede tener sentido. Es una salida menos directa para un servicio Deno que, por lo demás, seguirá igual. Elige Vercel por su flujo de trabajo para aplicaciones, contemplando expresamente la adaptación del runtime y el almacenamiento.

Ideal para: Aplicaciones web articuladas alrededor de un framework, con rutas de API junto al frontend.
Punto fuerte: Un flujo unificado de despliegue de aplicaciones con funciones del lado del servidor.
Precios: Hobby $0/mes; Pro $20/mes; Enterprise a medida.
Prueba gratuita: Pro anuncia una prueba; Hobby está limitado al uso personal no comercial.
Esfuerzo de migración: Medio para adaptar el runtime y las rutas; alto si también hay que sustituir el almacenamiento y las tareas en segundo plano.

Decide entre adaptar el código o conservar un runtime comunitario

Vercel incluye Node.js entre sus runtimes compatibles y ofrece Deno mediante el runtime comunitario vercel-deno. Son opciones con responsabilidades de mantenimiento distintas. Si migras con una fecha límite, evalúa la compatibilidad de la integración comunitaria y quién la mantiene antes de convertirla en una dependencia de producción. La otra opción es adaptar el manejador y sus dependencias al runtime con soporte que utilice tu framework. Documentación de runtimes de Vercel.

Para sustituir Deno KV, elige una base de datos y cambia la API. La guía de almacenamiento de Vercel distingue entre Blob para archivos, Global Config para configuración y bases de datos del Marketplace para datos de la aplicación. Un almacén de configuración no debería convertirse en el destino predeterminado de los registros transaccionales de clientes solo porque su interfaz de clave-valor parezca cómoda.

Vercel Cron sustituye la programación, no el registro mediante código de Deno.cron. Hobby permite ejecutar una tarea una vez al día, con precisión horaria; Pro admite un intervalo mínimo de una vez por minuto. Una sincronización frecuente descarta Hobby solo por sus condiciones de programación. Uso y precios de Cron.

Vercel Queues ya está disponible en beta en todos los planes, con temas persistentes, reintentos automáticos y entrega al menos una vez. Esto la convierte en una candidata para las tareas de las colas de Deno KV, aunque sigue siendo necesario reescribir productores, consumidores y confirmaciones de recepción. Incluye su condición de beta en la decisión si esa cola es la única vía para cumplir un pedido de un cliente.

El precio cambia cuando más personas necesitan desplegar

La cuota de la plataforma Pro incluye 1 plaza con permisos de despliegue y $20 de crédito mensual de consumo. Cada plaza de pago adicional cuesta $20/mes; las plazas de solo lectura son gratuitas. El consumo que supere el crédito y los complementos de pago se cobran por separado. Detalles de facturación de Pro.

Para una empresa que abandona Deno Deploy, el precio gratuito de Hobby no sirve como presupuesto de producción. Parte del plan que admita el uso comercial y añade las necesidades de base de datos y colas. Así evitarás que una migración aparentemente económica termine acumulando facturas imprevistas.

5. Val Town: para APIs pequeñas y tareas programadas

Val Town es un entorno alojado para programas pequeños con disparadores HTTP, de correo electrónico y cron. Encaja muy bien con ese servicio pequeño que resuelve una tarea útil: un webhook que actualiza un sistema externo, una API para una herramienta interna o un resumen enviado periódicamente. Su runtime de Deno lo hace pertinente para esta migración, pero las interfaces de almacenamiento y los disparadores siguen siendo distintos. Elige Val Town cuando el proyecto sea una automatización acotada, en lugar de una plataforma que debas administrar. Documentación de Val Town.

Ideal para: APIs pequeñas, manejadores de webhooks, integraciones programadas y utilidades internas.
Punto fuerte: Código alojado con disparadores integrados y almacenamiento SQLite.
Precios: Free $0; Pro $21/mes con facturación anual; Business desde $167/mes con facturación anual; Enterprise a medida. Las preguntas frecuentes del proveedor indican suscripciones mensuales de $25 para Pro y $200 para Business.
Prueba gratuita: Free es un plan permanente, sin dominios personalizados ni vals privados.
Esfuerzo de migración: Bajo para una utilidad sin estado, medio para una tarea pequeña con datos persistentes y alto para una aplicación más grande con estado.

Los periodos de facturación importan: la página de precios con la opción anual seleccionada no debe presentarse como una suscripción cancelable cada mes por el mismo importe. Las preguntas frecuentes de Val Town aportan la comparación con el cobro mensual y confirman el uso del runtime de Deno.

La migración solo es pequeña si la tarea también lo es

Traslada el manejador a un val, el contenedor de aplicaciones con versiones de Val Town, y vincula su invocación a un disparador HTTP o cron. Si una tarea solo llama a una API externa y envía un resumen, quizá su único estado persistente sea el último elemento procesado. Eso es mucho más fácil de entender y verificar que una aplicación orientada a clientes con varias entidades transaccionales y consumidores de colas.

Sustituye Deno KV por la base de datos SQLite de cada val cuando encaje, o conserva una base de datos externa. Reescribe las búsquedas por clave y las comprobaciones atómicas como operaciones de base de datos. No des por terminada la migración si Deno.openKv sigue apuntando al almacén alojado que va a retirarse.

Si hay trabajo en cola, el diseño debe representar expresamente las tareas pendientes. Una opción es un cron que revise periódicamente una tabla de tareas, pero tendrás que implementar la toma de tareas, los reintentos y el tratamiento de duplicados. Ese diseño no conserva automáticamente el comportamiento de las colas de Deno KV.

La frecuencia, la privacidad y la duración determinan el plan

El intervalo mínimo de cron en Free es de 15 minutos y la duración total máxima es de 1 minuto por ejecución. Pro reduce el intervalo a 1 minuto y amplía el límite de ejecución a 10 minutos; la ficha de precios también indica 10 dominios personalizados y 2,000 vals privados. Precios y límites vigentes.

Un resumen público diario puede encajar en Free. Una integración privada o una tarea que necesite consultar con mayor frecuencia exige otro plan aunque tenga muy poco tráfico. La privacidad del código y el acceso al endpoint son requisitos independientes: que el código fuente sea privado no determina, por sí solo, quién puede llamar a tu endpoint HTTP.

El esfuerzo de migración es bajo para una utilidad sin estado con un disparador sencillo, medio si hay que trasladar el estado persistente de una tarea y alto si intentas reproducir dentro de Val Town el runtime y la arquitectura de datos de una aplicación mayor. Estas valoraciones describen el alcance del trabajo, no estimaciones de horas.

6. Deno en infraestructura propia: para conservar el comportamiento del runtime

Ejecutar Deno en un servidor privado virtual, o VPS, conserva el runtime y deja el alojamiento bajo tu responsabilidad. Un contenedor empaqueta el runtime y la aplicación para ejecutarlos en el servidor que elijas. Conviene considerar esta opción cuando el acceso al sistema de archivos, las APIs específicas de Deno o los procesos de larga duración concentran el trabajo de adaptación. Elige el alojamiento propio cuando mantener el runtime ahorre más complejidad de la que añade administrar el servidor. Deno publica una guía oficial de Docker.

Ideal para: Una aplicación muy dependiente de Deno cuyo responsable pueda administrar un servidor o un despliegue en contenedores.
Punto fuerte: Control sobre el runtime, el sistema de archivos y el ciclo de vida de los procesos.
Precios: El runtime de código abierto no incluye un plan de alojamiento gestionado. Como ejemplo de proveedor, DigitalOcean ofrece un Basic Regular Droplet por $4.00/mes, con 512 MiB de RAM; su opción de 1 GiB cuesta $6.00/mes.
Prueba gratuita: DigitalOcean menciona créditos promocionales, pero su página de precios no ofrece un plan gratuito permanente de Droplet.
Esfuerzo de migración: Menos trabajo de adaptación del runtime y más responsabilidad operativa; los datos alojados siguen necesitando un plan de exportación, importación y recuperación.

Estos son los precios publicados de VPS, no una recomendación de capacidad para cualquier aplicación Deno. Incluye en la decisión el almacenamiento de copias de seguridad, la monitorización y tu tiempo de administración. Un servidor que ya tengas puede evitar una nueva suscripción de alojamiento, pero seguirá generando trabajo de mantenimiento.

Qué ocurre con Deno KV y cron

Deno KV puede utilizar una ruta local persistente para la base de datos, con SQLite como motor en la CLI. Esto permite conservar más de la API de KV que una migración al servicio de almacenamiento de otro proveedor. No copia los registros alojados, no reproduce el alojamiento distribuido ni vuelve persistente el sistema de archivos efímero de un contenedor. Exporta los datos, planifica su importación, monta almacenamiento persistente y demuestra que puedes restaurar una copia de seguridad. Documentación de Deno KV.

La misma distinción se aplica a la programación. En la CLI, Deno.cron conserva el estado de ejecución en memoria, con un conjunto independiente de tareas en cada proceso. Si ejecutas varias réplicas de la aplicación, debes decidir cuál se hace cargo de cada tarea programada o cómo se coordinan. Mantener intacta la llamada a la API no conserva el servicio gestionado de programación de Deploy. Comportamiento de cron en Deno.

Para una aplicación pequeña en un único servidor, esa carga operativa puede ser aceptable. Para una empresa que necesita infraestructura redundante y en la que nadie quiere encargarse de las copias de seguridad, los parches o la recuperación, una factura pequeña de VPS puede convertirse en una distracción costosa.

workerd y celld ofrecen otra vía de alojamiento propio

El anuncio de Cloudflare menciona workerd y celld como opciones de alojamiento propio disponibles hoy. Utilizan el modelo de programación de Workers, por lo que corresponden a una aplicación ya adaptada a ese modelo; no permiten prometer que todo el código Deno existente se ejecutará sin cambios. Cloudflare también reconoce que la implementación de Durable Objects en workerd independiente tiene una limitación de escalabilidad ligada a una sola instancia, y describe la integración en workerd de trabajo e ideas procedentes de celld. Anuncio de Cloudflare.

No presupuestes ninguna de las dos opciones como una nueva suscripción gestionada con un plan gratuito inventado. El presupuesto lo forman la infraestructura y la administración que aportes. Si el equipo migra bajo presión, evalúa las capacidades disponibles ahora y el plan de recuperación que puedas mantener; los futuros trabajos de integración no sustituyen esas decisiones.

Deno en infraestructura propia puede servir de transición, pero también necesita un plan de mantenimiento del runtime a largo plazo, dado el periodo de soporte anunciado por Deno.

Elige según lo que ejecuta tu proyecto

La decisión cambia cuando lo más difícil de trasladar es el estado y no el código. Valora el esfuerzo a partir de cambios identificables: bajo significa adaptar un manejador o la compilación sin tocar el estado externo; medio añade cambios en la integración con el runtime o en la API de almacenamiento; alto añade el rediseño de transacciones, el traslado de trabajo en cola o nuevas responsabilidades operativas. Incluso una aplicación pequeña puede exigir mucho esfuerzo de migración si su funcionamiento correcto depende de esos comportamientos.

Para funciones TypeScript sin APIs específicas de Deno, empieza por Workers. Conserva el contrato de solicitudes y respuestas y después adapta el punto de entrada y el despliegue. Netlify gana atractivo cuando esas funciones modifican las solicitudes de un sitio; Supabase, cuando trabajan principalmente con su base de datos. Vercel destaca cuando el framework de la aplicación ya es el motivo del cambio. Un manejador sin estado suele ser el caso de menor esfuerzo en cualquiera de estos destinos.

Para Deno KV, elige primero el modelo de almacenamiento. El contenido con muchas lecturas puede encajar en Workers KV o Netlify Blobs. Los registros transaccionales apuntan a D1, Postgres u otra base de datos diseñada para respetar la regla necesaria. La coordinación puede justificar Durable Objects. Una utilidad pequeña quizá solo necesite SQLite de Val Town. KV local en infraestructura propia permite conservar más código, pero deja la persistencia y la recuperación bajo tu responsabilidad. Considera cualquier migración de KV alojado como un trabajo de alcance al menos medio hasta que el inventario de transacciones e índices demuestre lo contrario.

Para cron, compara las condiciones de ejecución. Un informe diario y una tarea que consulta con frecuencia necesitan planes distintos. Workers Cron Triggers es la primera vía gestionada que conviene evaluar; Val Town resulta atractivo para una tarea acotada; Supabase Cron encaja con el mantenimiento de bases de datos; Netlify Scheduled Functions, con tareas asociadas a un sitio. La restricción diaria de Vercel Hobby lo descarta para tareas frecuentes. Volver a registrar una programación es poco trabajo; evitar efectos solapados puede no serlo.

Para las colas, traslada juntos los mensajes pendientes y su consumidor. Cloudflare Queues y Supabase Queues son destinos definidos; Vercel Queues añade una opción en beta. La migración abarca la identidad de los mensajes, los reintentos, las confirmaciones de recepción y las tareas que ya están esperando. Un temporizador no basta como sustituto. El alcance es alto cuando el trabajo pendiente corresponde a compromisos con clientes que ya han pagado.

Para sitios estáticos, traslada primero los archivos generados y evita adaptar código de servidor innecesario. Workers Static Assets y Netlify son candidatos directos; incluye Vercel si el framework del sitio se beneficia de su flujo de trabajo. Revisa por separado redirecciones, cabeceras, formularios, autenticación y rutas dinámicas. Migrar archivos puramente estáticos requiere menos esfuerzo que trasladar un sitio que genera respuestas personalizadas en cada solicitud.

Cómo migrar Deno KV sin alterar el comportamiento de la aplicación

Un despliegue de código y una migración de datos tienen criterios de éxito distintos. El código cumple cuando responde correctamente; la migración, cuando el destino conserva los registros y las reglas que hacen correctas esas respuestas.

Antes de exportar, inventaría las funciones de KV que utilizas: claves compuestas tipadas, búsquedas por prefijo, caducidad, índices secundarios, comprobaciones optimistas de versión, actualizaciones atómicas y observadores de cambios. La guía de KV de Deno muestra por qué un conjunto de claves puede representar más comportamiento de la aplicación de lo que sugiere un simple volcado de objetos.

Un índice de nombres de usuario sirve de ejemplo. Si la aplicación guarda un registro de usuario y otro que relaciona su nombre con ese usuario, copiar ambos registros no basta. La nueva lógica de escritura debe conservar esa relación y rechazar actualizaciones incompatibles. Del mismo modo, una marca de tiempo que hacía caducar una sesión necesita una política explícita en el destino: importar el valor sin reproducir ese comportamiento puede mantener la sesión válida más tiempo del debido.

Para las colas, lleva una lista separada del trabajo pendiente, completado y fallido siempre que el origen lo permita. Decide si dejarás que el consumidor antiguo termine los pendientes antes del cambio o si trasladarás las tareas con identificadores que permitan repetirlas sin riesgo. La idempotencia significa que repetir una tarea no repite su efecto en el negocio. Es la propiedad que evita que reintentar una tarea de envío de recibos mande varios recibos o que repetir un mensaje de tramitación genere trabajo duplicado.

1. 1

   Define cómo se escribirán los datos durante la copia

   Haz una copia de seguridad del origen y decide cómo gestionar las escrituras mientras copias. Una pausa breve de escritura puede encajar en una aplicación pequeña; un método de sincronización más complejo exige reconciliar los datos. Evita que los cambios simultáneos se pierdan silenciosamente entre la exportación y el cambio de plataforma.

2. 2

   Verifica los registros y su comportamiento

   Compara cantidades por tipo de entidad, valores representativos y codificación de claves. Prueba envíos duplicados, actualizaciones en conflicto, caducidades y registros ausentes con datos de prueba controlados. Comprueba el resultado de negocio esperado, no solo que la nueva API responda con éxito.

3. 3

   Transfiere juntos el tráfico y la responsabilidad de las tareas

   Redirige las solicitudes solo cuando el estado del destino esté listo. Desactiva o transfiere las programaciones y los consumidores antiguos para que ambas plataformas no produzcan el mismo efecto. Vuelve a configurar los secretos y los destinos de los webhooks de forma explícita.

4. 4

   Supervisa y conserva una forma viable de volver atrás

   Monitoriza errores, tareas fallidas y eventos de negocio después del cambio. Conserva la copia de seguridad del origen. Si el destino ya ha aceptado nuevas escrituras, volver atrás exige un plan de reconciliación de datos; no basta con revertir el DNS.

En tu próxima sesión de trabajo, prepara el inventario y decide el destino de la operación con estado más difícil de trasladar. Adapta esa operación antes de pulir el resto de la migración. Te permitirá detectar más riesgos que trasladar otro endpoint de comprobación de estado sin datos persistentes.

Cómo seleccionamos estas opciones

Estas vías se eligieron por las cargas que puede tener una aplicación de Deno Deploy: funciones HTTP, estado persistente, tareas programadas, trabajo en cola y archivos estáticos. Cloudflare aparece primero porque Deno lo señala como destino de migración. Netlify, Supabase y Val Town entran por su ejecución basada en Deno y por su encaje en aplicaciones distintas; Vercel, por su flujo de despliegue web; el alojamiento propio, por el control del runtime.

Los precios y las capacidades se contrastaron con las páginas públicas de los proveedores el 12 de octubre de 2026. Las valoraciones de esfuerzo describen los cambios que requieren esas interfaces documentadas. No son tiempos de migración medidos, resultados de pruebas de carga ni afirmaciones de haber probado los servicios con una sesión iniciada. Los servicios de nube de propósito general quedaron fuera de la selección porque añadir más proveedores no resolvería las decisiones centrales sobre runtime, estado y responsabilidad de las tareas.

Qué conviene evitar en esta migración

Evita sustituir mecánicamente el Deno KV transaccional por Workers KV. Elígelo solo cuando su comportamiento de lectura y escritura encaje con los datos. Un almacenamiento económico no compensa que se rompan las garantías de consistencia de la aplicación.

Evita Netlify Edge Functions para procesamiento intensivo de CPU en segundo plano. Su presupuesto de ejecución por solicitud en el edge es un límite útil, no algo que puedas ignorar esperando que un plan de pago cambie el modelo de ejecución.

Evita Vercel Hobby para una aplicación comercial en producción. La página de precios lo limita al uso personal no comercial. Sus restricciones de cron también lo descartan al comparar planes gratuitos para tareas frecuentes.

Evita Val Town Free si el código fuente debe ser privado. Las condiciones del plan importan antes que el volumen de tráfico. Evita también tratar Supabase Edge Functions como el sustituto predeterminado de un sitio estático convencional; elige expresamente dónde alojar el frontend.

Evita el alojamiento propio si nadie se hace cargo de la recuperación. Ejecutar el proceso es la parte sencilla. Alguien debe poder restaurar datos, reiniciar servicios y explicar qué programador de tareas queda al mando después de una interrupción.

Preguntas antes de migrar de Deno Deploy

¿Cuándo cierra Deno Deploy?

El anuncio establece un periodo de funcionamiento de seis meses, no una fecha exacta. Usa ese plazo y no lo sustituyas por el periodo más largo de mantenimiento del runtime.

¿Puedo seguir usando Deno al salir de Deno Deploy?

Sí. Netlify Edge Functions, Supabase Edge Functions y Val Town ofrecen ejecución basada en Deno o compatible con él; un VPS o un contenedor permiten ejecutar Deno por tu cuenta. Cada plataforma gestionada tiene sus propias APIs y límites. Conservar Deno no mantiene automáticamente la base de datos KV alojada, las programaciones ni la cola.

¿Puedo trasladar Deno KV directamente a Cloudflare KV?

Solo si también adaptas la API y confirmas que Workers KV satisface los requisitos de consistencia de la aplicación. Las comprobaciones atómicas, transacciones, índices y observadores de Deno KV necesitan sustitutos explícitos. Para registros transaccionales, evalúa D1 u otra base de datos; para estado coordinado por entidad, considera Durable Objects.

¿Qué plan gratuito puede ejecutar mi tarea cron?

Comprueba primero la frecuencia, los límites de ejecución, la privacidad del código y las condiciones de uso comercial. Val Town Free tiene un intervalo mínimo de 15 minutos y un límite de 1 minuto por ejecución. Vercel Hobby se limita a tareas diarias y uso personal no comercial. Workers Free tiene un presupuesto de CPU ajustado; Netlify y Supabase tienen sus propios recursos compartidos incluidos en el plan. Que programar la tarea sea gratis no demuestra que toda su ejecución lo sea.