En septiembre de 2024, incorporamos la compatibilidad beta para alojar, almacenar y entregar activos estáticos de forma gratuita en Cloudflare Workers, lo que hasta entonces solo era posible en Cloudflare Pages. La capacidad de alojar estos activos (tu código JavaScript, HTML y CSS del lado del cliente, así como fuentes e imágenes) era una funcionalidad fundamental que les faltaba a los desarrolladores que querían crear una aplicación integral en un Worker individual.
Hoy anunciamos diez importantes mejoras en el desarrollo de aplicaciones en Cloudflare. En conjunto, estas nuevas incorporaciones te permiten crear y alojar todo tipo de proyectos, desde simples sitios estáticos hasta aplicaciones integrales, todo ello en Cloudflare Workers:
Actualmente, Cloudflare Workers ofrece compatibilidad lista para producción, disponible de forma general con React Router v7 (Remix), Astro, Hono, Vue.js, Nuxt, Svelte (SvelteKit) y otros. En el segundo trimestre de 2025, esta misma compatibilidad se ampliará a otros marcos, como Next.js, Angular y SolidJS (SolidStart).
Puedes desarrollar aplicaciones integrales en Workers sin ningún marco: puedes "sencillamente usar Vite" y React juntos, y crear una API de backend en el mismo Worker. Si quieres ver un ejemplo, consulta nuestra plantilla de Vite + React.
El adaptador para Next.js, @opennextjs/cloudflare, que lanzamos en septiembre de 2024 como una primera versión alfa, ya es v1.0-beta, y estará disponible de forma general en las próximas semanas. Aquellos que utilicen el adaptador para OpenNext también podrán actualizar fácilmente a la API de implementaciones de Next.js anunciada recientemente.
El complemento de Cloudflare para Vite ya es v1.0 y está disponible de forma general. El complemento para Vite te permite ejecutar el servidor de desarrollo de Vite en el entorno de ejecución de Workers (workerd). Esto significa que te beneficias de todas las ventajas de Vite, como la sustitución de módulos en caliente, al mismo tiempo que puedes utilizar funciones que son exclusivas de Workers (como Durable Objects).
Ahora puedes utilizar los archivos de configuración estática _headers y _redirects para tus aplicaciones en Workers (lo que hasta ahora solo estaba disponible en Pages). Estos archivos te permiten añadir encabezados sencillos y configurar redirecciones sin ejecutar ningún código de Worker.
Además de PostgreSQL, ahora puedes conectarte a bases de datos MySQL desde Cloudflare Workers, a través de Hyperdrive. Incorpora tu base de datos MySQL existente de Planetscale, AWS, GCP, Azure u otros, e Hyperdrive se encargará de agrupar las conexiones a tu base de datos y de eliminar los recorridos de ida y vuelta innecesarios gracias al almacenamiento en caché de las consultas.
Hemos añadido más API de Node.js disponibles en Workers Runtime, como las API de los módulos crypto, tls, net y dns . También hemos aumentado el tiempo máximo de CPU para una solicitud de Workers (de 30 segundos a 5 minutos).
Ahora puedes traer cualquier repositorio de GitHub o GitLab que contenga una aplicación de Worker, y Workers Builds se encargará de implementar la aplicación como un nuevo Worker en tu cuenta. Workers Builds también se inicia mucho más rápido (hasta 6 segundos más rápido por cada compilación).
Ahora puedes configurar Workers Builds para su ejecución en ramas que no sean de producción, y las URL de vista previa se publicarán en GitHub como un comentario.
El enlace Images en Workers está disponible de forma general, lo que te permite crear flujos de trabajo más flexibles mediante programación.
Con estas mejoras, puedes crear tanto sencillos sitios estáticos como aplicaciones más complejas representadas en el lado del servidor. Al igual que Pages, solo se te aplicará una tarifa cuando se ejecute tu código Worker, por lo que puedes alojar y entregar sitios estáticos de forma gratuita. Cuando quieras llevar a cabo la representación en el servidor o necesites crear una API, solo tienes que añadir un Worker para que se encargue de tu backend. Además, cuando necesites leer o escribir datos en tu aplicación, puedes conectarte a una base de datos existente con Hyperdrive, o utilizar cualquiera de nuestras soluciones de almacenamiento: Workers KV, R2, Durable Objects o D1.
Si quieres adentrarte directamente en el código, haz clic en el siguiente botón "Implementar en Cloudflare" para implementar una aplicación de una sola página creada con Vite y React, con la opción de conectarte a una base de datos alojada con Hyperdrive:
Anteriormente, desde el principio tenías que elegir entre crear en Cloudflare Pages o en Workers (o bien utilizar Pages para una parte de tu aplicación y Workers para otra). Esto implicaba que debías averiguar qué necesitaba tu aplicación desde el principio, y esperar que, si tu proyecto evolucionaba, no te quedaras bloqueado con la plataforma y la arquitectura equivocadas. Workers se diseñó para ser una plataforma flexible, que permitiera a los desarrolladores avanzar en los proyectos según fuera necesario. Por este motivo, a lo largo de los años hemos trabajado para incorporar elementos de Pages en Workers.
Ahora que Workers permite tanto la entrega de activos estáticos como la representación en el lado del servidor, deberías empezar con Workers. Cloudflare Pages seguirá siendo compatible, pero de ahora en adelante todas nuestras inversiones, optimizaciones y trabajo en las funciones se dedicarán a mejorar Workers. Nuestro objetivo es hacer de Workers la mejor plataforma para crear aplicaciones integrales, basándonos en tus comentarios sobre lo que te ha ido bien con Pages y lo que podríamos mejorar.
Hasta ahora, desarrollar una aplicación en Pages significaba que tenías un acceso muy fácil y bien guiado, pero a la larga te podías encontrar en un callejón sin salida si tu aplicación se volvía más compleja. Si quisieras utilizar Durable Objects para gestionar el estado, tendrías que configurar un Worker completamente independiente para ello, por lo que terminarías teniendo una implementación complicada y más gastos generales. También estabas limitado a los registros en tiempo real, y solo podías implementar los cambios de una sola vez.
Cuando desarrollas en Workers, puedes vincularte inmediatamente a cualquier otro servicio de la plataforma para desarrolladores (como Durable Objects, Email Workers y otros), y gestionar tanto tu frontend como tu backend en un solo proyecto, todo ello con una única implementación. Asimismo, te beneficias de todo el conjunto de herramientas de observabilidad de Workers integradas en la plataforma, como Workers Logs. Además, si quieres implementar los cambios solo en un determinado porcentaje del tráfico, puedes hacerlo con las implementaciones graduales.
Estas últimas mejoras forman parte de nuestro objetivo de llevar lo mejor de Pages a Workers. Por ejemplo, ahora admitimos los archivos de configuración estática _headers y _redirects, para que puedas tomar fácilmente un proyecto existente de Pages (o de otra plataforma) y moverlo a Workers, sin necesidad de cambiar tu proyecto. También ofrecemos la integración directa con GitHub y GitLab mediante Workers Builds, proporcionando compilaciones e implementaciones automáticas. Asimismo, a partir de hoy las URL de vista previa se publican en tu repositorio como un comentario, y próximamente estarán disponibles los alias y los entornos de las ramas de funciones.
Si quieres saber cómo migrar un proyecto existente de Pages a Workers, lee nuestra guía para la migración.
A continuación, hablemos de cómo puedes crear aplicaciones con distintos modos de representación en Workers.
Crear sitios estáticos, SPA y SSR en Workers
Como introducción rápida, aquí tienes todas las arquitecturas y todos los modos de representación que analizaremos y que son compatibles con Workers:
Sitios estáticos: cuando visitas un sitio estático, el servidor devuelve inmediatamente los activos estáticos prediseñados (HTML, CSS, JavaScript, imágenes y fuentes). No se realiza ninguna representación dinámica en el servidor en el momento de la solicitud. Los activos estáticos se suelen generar durante la compilación y se entregan directamente desde una CDN, por lo que los sitios estáticos sean rápidos y fáciles de almacenar en caché. Este enfoque funciona bien para los sitios cuyo contenido casi nunca cambia.
Aplicaciones de una sola página (SPA): cuando cargas una SPA, el servidor envía inicialmente un shell HTML mínimo y un paquete de JavaScript (que se entregan como activos estáticos). Tu navegador descarga este código JavaScript, que luego se encarga de representar toda la interfaz de usuario del lado del cliente. Después de la carga inicial, toda la navegación se produce sin actualizaciones de página completa, normalmente a través del enrutamiento del lado del cliente. Esto genera una experiencia rápida, similar a la de una aplicación.
Aplicaciones representadas en el lado del servidor (SSR): cuando visitas por primera vez un sitio que utiliza SSR, el servidor genera una página HTML completamente representada bajo demanda para esa solicitud. Tu navegador muestra inmediatamente este código HTML completo, por lo que la primera página se carga rápidamente. Una vez cargada, JavaScript "hidrata" la página, añadiendo interactividad. Las navegaciones posteriores pueden activar nuevas páginas representadas por el servidor o, en muchos marcos modernos, pasar a la representación del lado del cliente de forma similar a una SPA.
A continuación, analizaremos cómo puedes crear este tipo de aplicaciones en Workers, empezando por la configuración de tu entorno de desarrollo.
Configuración: compilación y desarrollo
Antes de cargar tu aplicación, debes agrupar todo tu código del lado del cliente en un directorio de activos estáticos. Wrangler agrupa y compila tu código cuando ejecutas wrangler dev, pero ahora también admitimos Vite con nuestro nuevo complemento para Vite. Esta es una estupenda opción para aquellos que ya utilizan las herramientas de compilación y el servidor de desarrollo de Vite. Puedes seguir desarrollando (y probando con Vitest) utilizando el servidor de desarrollo de Vite, todo ello en el entorno de ejecución de Workers.
Para empezar a utilizar nuestro complemento para Vite, puedes crear una aplicación React utilizando Vite y nuestro complemento. Para ello, ejecuta:
npm create cloudflare@latest my-react-app -- --framework=react
Cuando abras el proyecto, deberías ver una estructura de directorios de este tipo:
...
├── api
│ └── index.ts
├── public
│ └── ...
├── src
│ └── ...
...
├── index.html
├── package.json
├── vite.config.ts
└── wrangler.jsonc
Si ejecutas npm run build, verás que aparece una nueva carpeta, /dist.
...
├── api
│ └── index.ts
├── dist
│ └── ...
├── public
│ └── ...
├── src
│ └── ...
...
├── index.html
├── package.json
├── vite.config.ts
└── wrangler.jsonc
El complemento para Vite informa a Wrangler de que este directorio /dist contiene los activos estáticos compilados del proyecto que, en este caso, incluye el código del lado del cliente, algunos archivos CSS e imágenes.
Una vez implementada, esta arquitectura de aplicación de una sola página (SPA) tendrá un aspecto similar al siguiente:
Cuando llega una solicitud, Cloudflare comprueba el nombre de la ruta y entrega automáticamente los activos estáticos que coinciden con ese nombre de ruta. Por ejemplo, si tu directorio de activos estáticos incluye un archivo blog.html, las solicitudes de example.com/blog recibirán ese archivo.
Si tienes un sitio estático creado por un generador de sitios estáticos (SSG) como Astro, lo único que tienes que hacer es crear un archivo wrangler.jsonc (o wrangler.toml) e indicar a Cloudflare dónde encontrar tus activos creados:
// wrangler.jsonc
{
"name": "my-static-site",
"compatibility_date": "2025-04-01",
"assets": {
"directory": "./dist",
}
}
Una vez que hayas añadido esta configuración, lo único que tienes que hacer es crear tu proyecto y ejecutar wrangler deploy. Todo tu sitio se cargará y estará listo para el tráfico en Workers. Una vez que tu sitio estático se haya implementado y empiecen a llegar las solicitudes, este se almacenará en caché en la red de Cloudflare.
Prueba iniciar hoy mismo un nuevo proyecto de Astro en Workers ejecutando:
npm create cloudflare@latest my-astro-app -- --framework=astro
Puedes ver nuestros otros marcos compatibles y cómo empezar en nuestras guías sobre los marcos.
Aplicaciones de una sola página (SPA)
Si tienes una aplicación de una sola página, puedes activar explícitamente el modo de aplicación de una sola página en tu configuración de Wrangler:
{
"name": "example-spa-worker-hyperdrive",
"main": "api/index.js",
"compatibility_flags": ["nodejs_compat"],
"compatibility_date": "2025-04-01",
},
"assets": {
"directory": "./dist",
"binding": "ASSETS",
"not_found_handling": "single-page-application"
},
"hyperdrive": [
{
"binding": "HYPERDRIVE",
"id": "d9c9cfb2587f44ee9b0730baa692ffec",
"localConnectionString": "postgresql://myuser:mypassword@localhost:5432/mydatabase"
}
],
"placement": {
"mode": "smart"
}
}
Al activar este modo, la plataforma asume que cualquier solicitud de navegación (las solicitudes con un encabezado Sec-Fetch-Mode: navigate) está destinada a activos estáticos y entregará index.html cuando no se pueda encontrar ningún activo estático coincidente. En el caso de las solicitudes que no sean de navegación (como las solicitudes de datos) que no coincidan con ningún activo estático, Cloudflare invocará el script de Worker. Con esta configuración, puedes representar el frontend con React, utilizar Worker para gestionar las operaciones de backend y usar Vite para la integración de ambos. Esta es una estupenda opción para traer las SPA más antiguas creadas con create-react-app, que se eliminó recientemente.
Otro aspecto a tener en cuenta en este archivo de configuración de Wrangler: hemos definido un enlace Hyperdrive y activado Smart Placement. Hyperdrive nos permite utilizar una base de datos existente y gestionar la agrupación de conexiones. Esto resuelve el continuo desafío que suponía conectar Workers (que se ejecuta en un entorno muy distribuido y sin servidor) directamente a las bases de datos tradicionales. Por diseño, Workers funciona en aislamientos V8 ligeros sin sockets TCP persistentes y con un límite estricto de CPU/memoria. Este aislamiento es excelente a efectos de la seguridad y la velocidad, pero dificulta mantener abiertas las conexiones a las bases de datos. Hyperdrive resuelve estas limitaciones, ya que funciona como "puente" entre la red de Cloudflare y tu base de datos, encargándose del trabajo más complejo de garantizar la estabilidad de las conexiones o agrupaciones para que Workers pueda reutilizarlas. Al activar Smart Placement, también garantizamos que si las solicitudes a nuestro Worker se originan lejos de la base de datos (lo que causa latencia), Cloudflare puede optar por reubicar tanto el Worker, que se encarga de la conexión a la base de datos, como el "puente" de Hyperdrive a una ubicación más cercana. a la base de datos, reduciendo los tiempos de ida y vuelta.
Ejemplo de SPA: código Worker
Veamos el ejemplo de "Implementar en Cloudflare" del principio de este blog. En api/index.js, hemos definido una API (mediante Hono) que se conecta a una base de datos alojada a través de Hyperdrive.
import { Hono } from "hono";
import postgres from "postgres";
import booksRouter from "./routes/books";
import bookRelatedRouter from "./routes/book-related";
const app = new Hono();
// Setup SQL client middleware
app.use("*", async (c, next) => {
// Create SQL client
const sql = postgres(c.env.HYPERDRIVE.connectionString, {
max: 5,
fetch_types: false,
});
c.env.SQL = sql;
// Process the request
await next();
// Close the SQL connection after the response is sent
c.executionCtx.waitUntil(sql.end());
});
app.route("/api/books", booksRouter);
app.route("/api/books/:id/related", bookRelatedRouter);
export default {
fetch: app.fetch,
};
Cuando se implementa, la arquitectura de nuestra aplicación tiene el siguiente aspecto:
Si Smart Placement mueve la ubicación de mi Worker para que se ejecute más cerca de mi base de datos, podría tener este aspecto:
Representación en el lado del servidor (SSR)
Si quieres gestionar la representación en el servidor, admitimos una serie de populares marcos integrales.
Aquí tienes una versión de nuestro ejemplo anterior, que ahora utiliza la representación del lado del servidor de React Router v7:
También puedes utilizar Next.js con el adaptador para OpenNext, o cualquier otro marco especificado en nuestras guías sobre los marcos.
Implementar en Workers, con el menor número de cambios posible
Compatibilidad con Node.js
También hemos seguido avanzando en la compatibilidad con las API de Node.js, y hemos añadido recientemente compatibilidad con los módulos crypto, tls, net y dns. Esto permite que las aplicaciones y las bibliotecas existentes que dependen de estos módulos de Node.js se ejecuten en Workers. Veamos un ejemplo:
Anteriormente, si intentabas utilizar el paquete mongodb, te encontrabas con el siguiente error:
Error: [unenv] dns.resolveTxt is not implemented yet!
Esto sucedía cuando mongodb utilizaba el módulo node:dns para realizar una búsqueda de DNS de un nombre de host. Incluso si hubieras evitado ese problema, te habrías encontrado otro error cuando mongodb intentara utilizar node:tls para conectarse de forma segura a una base de datos.
Ahora, puedes utilizar mongodb de la forma prevista porque node:dns y node:tls son compatibles. Lo mismo puede decirse en el caso de las bibliotecas que dependen de node:crypto y node:net.
Además, Workers ahora expone las variables de entorno y los secretos en el objeto process.env cuando el indicador de compatibilidad nodejs_compat está activado y la fecha de compatibilidad está establecida en 01-04-2025 o una fecha posterior. Algunas bibliotecas (y algunos desarrolladores) asumen que este objeto se rellenará con variables, y se basan en él para la configuración de nivel superior. Sin la modificación, es posible que las bibliotecas se vieran dañadas de forma inesperada y que los desarrolladores tuvieran que escribir lógica adicional para gestionar las variables en Cloudflare Workers.
Ahora puedes acceder a tus variables de la misma forma que en Node.js.
const LOG_LEVEL = process.env.LOG_LEVEL || "info";
Tiempo adicional de CPU de Worker
También hemos aumentado el tiempo máximo de CPU por solicitud de Worker (de 30 segundos a 5 minutos). Esto permite que las operaciones que requieren muchos recursos informáticos se ejecuten durante más tiempo sin que se agote el tiempo de espera. Supongamos que quieres utilizar el módulo node:crypto, ahora compatible, para aplicar hash a un archivo muy grande. Ahora puedes hacerlo en Workers sin tener que depender de procesos externos para aquellas operaciones que consumen mucha CPU.
También hemos realizado mejoras en Workers Builds, que te permiten conectar un repositorio Git a tu Worker, para que puedas tener compilaciones e implementaciones automáticas en todos los cambios enviados. Presentamos Workers Builds durante el Builder Day 2024, y en un principio solo permitía conectar un repositorio a un Worker existente. Ahora, puedes traer un repositorio e implementarlo inmediatamente como un nuevo Worker, lo que reduce las tareas de configuración y los clics necesarios para traer un proyecto. Hemos mejorado el rendimiento de Workers Builds al reducir la latencia de los inicios de compilación en 6 segundos. Ahora se inician en 10 segundos de media. También aumentamos la capacidad de respuesta de la API, multiplicando por siete la latencia gracias a Smart Placement.
Nota: el 2 de abril de 2025, Workers Builds realizó la transición a un nuevo modelo de precios, tal y como se anunció durante el Builder Day 2024. Los usuarios del plan gratuito tienen ahora un límite de 3000 minutos de tiempo de compilación, y los usuarios de la suscripción de pago de Workers tendrán un nuevo modelo basado en el uso, con 6000 minutos gratuitos incluidos y, una vez superada esa cantidad, un precio de 0,005 USD por minuto de compilación. Para una mejor compatibilidad de las compilaciones simultáneas, los planes de pago también ofrecerán ahora seis (6) compilaciones simultáneas, lo que facilitará el trabajo en varios proyectos y monorepos. Para obtener más información sobre los precios, consulta la documentación.
También puedes configurar Workers Builds para su ejecución en ramas que no sean de producción, y las URL de vista previa se publicarán en GitHub como un comentario.
Vincula la API de Images a tu Worker
La semana pasada, escribimos una publicación en el blog que explica cómo el enlace Images permite flujos de trabajo más flexibles mediante programación para la optimización de imágenes.
Anteriormente, podías acceder a las funciones de optimización de imágenes invocando fetch() en tu Worker. Este método requiere que la imagen original sea recuperable por URL. Sin embargo, en algunos casos es posible que no se pueda acceder a las imágenes desde una URL, por ejemplo, cuando quieres comprimir las imágenes cargadas por los usuarios antes de que se carguen en tu almacenamiento. Con el enlace Images, puedes optimizar directamente una imagen operando en el cuerpo de la imagen como una secuencia de bytes.
Para obtener más información, lee nuestra guía sobre cómo transformar una imagen antes de cargarla en R2.
Empieza a desarrollar hoy mismo
Estamos deseando ver lo que desarrollarás. Seguimos trabajando en nuevas funciones y mejoras que faciliten la creación de aplicaciones, sea del tipo que sea, en Workers. A la mejora de esta tarea han contribuido en gran medida los comentarios de la comunidad, por lo que animamos a todo el mundo a unirse a nuestro Discord para participar en el debate.
Recursos útiles para empezar: