Cloudflare activa Node.js por defecto en todos los Workers: qué cambia, qué revisar y cómo desactivarlo

Sí, cambió algo importante el 4 de agosto de 2026: desde esa fecha, todo Worker de Cloudflare con una compatibility_date igual o posterior a 2026-08-04 ejecuta Node.js habilitado por defecto — node:crypto, node:fs, node:stream, node:net y el resto de módulos built-in funcionan sin declarar ninguna flag. La buena noticia: en la mayoría de los casos no tienes que hacer nada. La mala: hay una trampa silenciosa entre el bundler y el runtime que ya se llevó horas de debugging a más de un equipo, y la forma de "apagar" Node.js requiere dos flags, no una. Esto es lo que realmente cambió, qué revisar en tu proyecto y cuándo conviene quedarte fuera de la nueva normalidad.

Qué cambió exactamente (sin humo)

Cloudflare publicó el cambio en su changelog oficial el 4 de agosto de 2026: los Workers con fecha de compatibilidad 2026-08-04 o posterior activan las flags nodejs_compat y nodejs_compat_v2 por defecto. Traducción práctica:

• Todos los módulos built-in de Node.js soportados por el runtime están disponibles sin configuración: node:crypto, node:buffer, node:stream, node:net, node:dns, node:fs, node:http, y más.
• Los paquetes npm que dependen de esas APIs — drivers de base de datos, librerías de auth, utilidades de streams — funcionan sin tocar wrangler.toml.
• Los proyectos nuevos ya no necesitan agregar ninguna flag.
• Los proyectos existentes pueden actualizar su fecha de compatibilidad sin quitar las flags que ya tengan: wrangler, Miniflare, el plugin de Vite de Cloudflare y Vitest Pool Workers las ignoran por redundantes.

La regla aplica a cualquier código que corra sobre el runtime de Workers, incluidas las Functions de Cloudflare Pages (mismo runtime, misma palanca: la compatibility_date de tu proyecto). Si tu sitio corre en Pages — como el nuestro en Astro sobre Cloudflare Pages —, esta noticia te toca de lleno aunque no escribas una sola línea de Workers.

La trampa que no aparece en el anuncio

El changelog es corto y suena a "todo mejora". Pero la semana siguiente, el 12 de agosto, Cloudflare lanzó wrangler 4.122.0 con un fix que delata el problema real: los bundlers solo aplicaban los polyfills de Node.js cuando la flag aparecía explícitamente en la configuración. Resultado: un Worker con fecha de compatibilidad ≥ 2026-08-04 recibía las APIs de Node en tiempo de ejecución, pero sin los polyfills en el bundle — y process.env podía terminar sustituido por un objeto vacío en tiempo de build. Es decir: el código funcionaba en local y explotaba en producción con variables de entorno "inexistentes", o fallaba en el deploy por imports que el bundler no resolvía.

Si vas a subir la fecha de compatibilidad de un proyecto existente, este es el orden correcto:

1. Actualiza wrangler primero (≥ 4.122.0) para que el bundler y el runtime interpreten la misma configuración.
2. Actualiza la compatibility_date en tu wrangler.toml o en el dashboard de Pages.
3. Quita las flags nodejs_compat / nodejs_compat_v2 redundantes (opcional, pero deja la config honesta).
4. Revisa el tamaño del bundle: las APIs de Node añaden peso real al artefacto.
5. Verifica process.env y los imports de módulos node:* en el build de producción, no solo en local.

Antes vs. después: la tabla que importa

Cuándo conviene desactivarlo (sí, hay casos)

Node.js por defecto es una victoria de ergonomía: elimina fricción con el ecosistema npm y acerca Workers a la experiencia de desarrollo "normal". Pero default-on también significa que todo lo que no usas entra al bundle: módulos que antes el árbol de dependencias no necesitaba resolver ahora pueden arrastrar polyfills, y eso se paga en tamaño de artefacto, cold starts y superficie de ataque.

Tres escenarios donde recomendamos desactivarlo explícitamente:

• Workers pequeños y de alta frecuencia (middlewares de edge, rewrites, A/B flags): si tu código no importa ningún módulo node:*, el costo de Node.js es puro overhead.
• Proyectos con requisitos de seguridad estrictos: menos APIs disponibles = menos superficie de explotación. En stacks de alta regulación, el principio de mínima exposición manda.
• Equipos con dependencias legacy que resuelven process u otros globals de Node con shims propios: la activación por defecto puede chocar con esos shims y producir comportamientos dobles.

La forma de apagarlo, ojo, requiere las dos flags — no_nodejs_compat y no_nodejs_compat_v2 — porque cada una tiene su propio valor por defecto desde la nueva fecha. Un solo no_nodejs_compat sin su compañera deja la puerta medio abierta.

Por qué esto importa para tu arquitectura edge

Este cambio no es solo una flag: es la señal más clara de hacia dónde va la plataforma. Cloudflare compró el equipo de Astro en enero de 2026 y desde entonces el framework y el runtime evolucionan juntos — esta misma semana, el adaptador @astrojs/cloudflare 14.2.1 exigía Astro 7.2.0 porque importa símbolos nuevos del core. La dirección es inequívoca: el edge quiere ser indistinguible de Node, y la barrera de entrada para migrar aplicaciones tradicionales a Workers acaba de bajar un escalón.

Para equipos que todavía están decidiendo su arquitectura, esto cambia una de las objeciones clásicas al edge ("no puedo usar mi librería X porque necesita Node"). Ya no es excusa. La decisión ahora es más honesta: no "¿puedo correr esto en el edge?" sino "¿debería?". Y ahí entra el análisis de siempre: latencia de cold start, límites del runtime, persistencia y vendor lock-in — los mismos criterios que usamos al comparar rendimiento de edge vs. serverless tradicional y al elegir entre renderizado en el borde y arquitecturas híbridas.

Si vienes de un stack clásico (WordPress, Node en VPS), el camino de migración a Pages con Node.js por defecto es más corto que nunca — y bastante menos traumático que lo que documentamos en nuestra migración de Next.js a Astro + Cloudflare Pages. La advertencia sigue siendo la misma que con cualquier cambio de plataforma: actualiza tus herramientas antes de subir la fecha, lee el changelog con el detalle que merece, y no asumas que "por defecto" significa "gratis".

La conclusión corta: Cloudflare acaba de hacer que Node.js sea la línea base del edge, no una opción. Para la mayoría, es una mejora silenciosa. Para los que ya viven en la plataforma — como nosotros con Astro + Cloudflare Pages en producción —, es un recordatorio de que la fecha de compatibilidad es una decisión de arquitectura, no un campo de formulario. Revísala, actualiza wrangler y decide conscientemente si quieres el Node.js nuevo por defecto… o si prefieres apagarlo con sus dos flags y pagar solo por lo que usas.