Desplegar Next.js en Cloudflare Workers sin Vercel: @opennextjs/cloudflare

Vercel es el camino de menor resistencia para desplegar Next.js. Pero cuando un cliente ya tiene su dominio, DNS y otros servicios en Cloudflare, añadir Vercel como segundo proveedor es una factura y una superficie de configuración extra que no siempre se justifica. Ahí es donde entra @opennextjs/cloudflare.

Qué hace el adaptador

OpenNext transforma el build estándar de Next.js en algo que un Worker de Cloudflare puede ejecutar: SSR, API routes, middleware y App Router funcionando sobre el runtime de Cloudflare en lugar del runtime de Vercel. El comando npm run build:cf genera esa build adaptada; npm run deploy:cf la sube con Wrangler.

Lo que se gana

Todo bajo un mismo proveedor: dominio, DNS, base de datos (D1), CDN y ahora también el hosting de la app. Una sola factura, un solo dashboard, y latencia mínima entre el Worker y D1 porque ambos corren en el edge de Cloudflare.

Lo que se complica

Cloudflare Workers usa el runtime Edge, no Node.js completo. Cualquier código que dependa de APIs de Node (algunos paquetes de procesamiento de imágenes, ciertos SDKs) puede no funcionar sin adaptación. La optimización de imágenes de next/image requiere Cloudflare Image Resizing en lugar del optimizador nativo de Vercel. Y el preview local con Wrangler (wrangler dev) funciona mejor en Linux o WSL que en Windows nativo.

Turbopack, con cuidado

Un aviso real de producción: combinar Turbopack con @opennextjs/cloudflare puede generar un ChunkLoadError al desplegar. Hasta que el adaptador tenga soporte estable de Turbopack, el build de producción para Cloudflare debe forzar el compilador clásico de Webpack.

Cuándo lo elijo

Si el cliente ya vive en el ecosistema Cloudflare (dominio, D1, Workers), muevo el hosting ahí también. Si el proyecto es una landing simple sin necesidades de edge, Vercel sigue siendo más simple de configurar y no hay razón para complicarlo.