Dónde desplegar Next.js en 2026: Vercel, Cloudflare o AWS

¿Dónde conviene desplegar una web Next.js? La respuesta corta: si la web puede exportarse como estática, en cualquier CDN — la decisión es trivial y cuesta céntimos al mes. Si necesita servidor, Vercel es la opción por defecto, Cloudflare la de mejor precio/rendimiento y AWS, Google Cloud y Azure las de mayor control para quien ya opera en ellas.

Este artículo desarrolla esa respuesta. En Next.js vs WordPress explicamos cuándo conviene construir una web con Next.js; la pregunta que llega justo después es dónde alojarla, y ahí el ruido es considerable: Vercel parece obligatorio, AWS parece imposible y cada proveedor asegura ser la opción evidente. Ordenamos las cinco alternativas serias de 2026 con el criterio que usamos en nuestros proyectos y con la ventaja de poder enseñar nuestra propia infraestructura como ejemplo.

Antes de elegir proveedor: ¿tu web necesita servidor?

La comparativa de proveedores es la segunda pregunta. La primera, la que de verdad decide precio y complejidad, es qué necesita tu web para funcionar:

• Web estática. Todas las páginas se generan al compilar (output: 'export') y el resultado son archivos HTML, CSS y JavaScript. No hay servidor ejecutando nada en cada visita: cualquier CDN del mundo sabe servir archivos, así que todos los proveedores valen y compites solo por precio, que ronda lo simbólico. Es el caso de la mayoría de webs corporativas, portfolios y blogs — incluida esta.
• Web con servidor. Hay páginas que se generan en el momento (SSR), se regeneran cada cierto tiempo (ISR) o mezclan parte estática y parte dinámica en la misma URL (PPR, el prerrenderizado parcial de Next.js 16). Aquí sí hay que ejecutar código en cada visita, y la pregunta cambia: ya no es "¿cuánto cuesta?" sino "¿este proveedor soporta bien las funciones de Next.js que uso?". La respuesta varía mucho más de lo que el marketing sugiere.

La trampa habitual es la segunda opción por inercia: muchos proyectos arrastran SSR que no necesitan —una web corporativa cuyo contenido cambia dos veces al mes no necesita generar nada por visita— y acaban pagando servidor, arranques en frío y complejidad por costumbre. Nuestro consejo antes de mirar proveedores: pregunta si tu web puede ser estática. Si la respuesta es sí, la decisión de hosting pasa de estratégica a trivial, y los Core Web Vitals salen casi aprobados de serie.

Un nombre que aparecerá varias veces: OpenNext, un proyecto de código abierto que traduce lo que produce next build al formato de otras plataformas (Cloudflare, AWS Lambda, Netlify). Es la pieza que ha cambiado el tablero en los últimos años: gracias a OpenNext, "Next.js completo" ya no significa "solo Vercel".

La letra pequeña del export estático

La vía estática es la más barata y portable, pero conviene firmarla sabiendo lo que pone en las cláusulas: sin servidor, todo lo que se genera en el momento de la visita desaparece. Las páginas se construyen por adelantado al publicar, así que cada cambio de contenido implica regenerar la web —un proceso automático que tarda minutos—, y lo que dependía de un servidor se resuelve por otras vías: las redirecciones se configuran en el CDN, las imágenes se optimizan al publicar o con un servicio externo, y el multiidioma se organiza con la estructura de URLs (/es/, /en/), como hace esta misma web.

Hay además un par de ajustes de fontanería que nadie cuenta hasta el primer disgusto: un almacén de archivos no se comporta exactamente igual que un servidor web, y hay que indicarle cómo resolver las direcciones cuando alguien recarga una página interior —esta web lleva esa configuración activada precisamente por eso— y qué puede guardar el navegador en caché y durante cuánto tiempo, para que publicar una versión nueva no le rompa la web a quien está navegando en ese momento.

Nada de esto es un impedimento: es media hora de configuración bien documentada, se hace una vez y queda hecha. Pero explica por qué "subir los archivos y listo" casi nunca es literalmente el último paso.

Vercel: la opción por defecto, con razón

Vercel es la empresa que crea Next.js, y se nota: es el único sitio donde todo funciona sin configurar nada. Conectas el repositorio de GitHub y cada push despliega solo; cada pull request genera una URL de previsualización para revisar los cambios antes de publicar; ISR, PPR, use cache, optimización de imágenes y streaming funcionan de serie, sin adaptadores ni letra pequeña.

Lo bueno:

• Cero fricción. Del repositorio a producción en minutos, con previews por rama que cambian la forma de revisar el trabajo en equipo.
• Compatibilidad total garantizada. Cada función nueva de Next.js funciona en Vercel el día que se publica. En el resto de plataformas, los adaptadores van semanas o meses por detrás con lo más nuevo.
• Capa gratuita generosa para proyectos personales (el plan Hobby no permite uso comercial).

Lo menos bueno:

• El precio escala por uso y por asiento. El plan Pro parte de unos 20 $ por miembro del equipo al mes, y sobre eso se factura el consumo: ancho de banda, ejecuciones de funciones, optimización de imágenes. Para una web corporativa es más que suficiente y predecible; en proyectos con tráfico fuerte, la factura merece vigilancia — los sustos de facturación de Vercel son un género propio en los foros.
• Dependencia del proveedor. No es un secuestro —el código Next.js es tuyo y portable—, pero cuanto más uses sus servicios satélite (analítica, feature flags, colas), más cuesta mudarse.

Para quién: equipos que quieren invertir su tiempo en el producto y no en infraestructura, proyectos que usan lo último del framework, y cualquier web con servidor donde el coste de un DevOps supere el sobreprecio de Vercel — que es la mayoría de las pymes.

Cloudflare: el mejor precio/rendimiento de 2026

Cloudflare llegó a esta batalla desde su terreno natural —la red— y en 2026 es la alternativa más seria a Vercel. Las webs estáticas se sirven gratis desde su red global, sin límite práctico de tráfico. Y para webs con servidor, el adaptador oficial OpenNext para Cloudflare ejecuta Next.js sobre Workers, su plataforma de computación distribuida.

Lo bueno:

• El ancho de banda no se cobra. Es la diferencia estructural con casi todos los demás: un pico de tráfico no es un pico de factura.
• Precios de otra liga. El plan de pago de Workers parte de 5 $ al mes, y la capa gratuita aguanta proyectos reales, no solo demos.
• Red enorme: la web se sirve desde cientos de ciudades, con latencias excelentes en cualquier continente.

Lo menos bueno:

• Compatibilidad muy buena, no total. El adaptador OpenNext cubre SSR, ISR y la gran mayoría de funciones, pero lo más nuevo del framework llega con retraso y el runtime de Workers no es Node.js puro: alguna dependencia con requisitos exóticos puede protestar. Para una web normal no lo notarás; para una aplicación compleja, conviene probarlo antes de comprometerse.
• La experiencia de desarrollo (previews, panel, logs) es correcta pero un escalón por debajo del pulido de Vercel.
• Los bloqueos de LaLiga en España. Desde 2025, LaLiga bloquea por orden judicial direcciones IP de Cloudflare durante las jornadas de fútbol para combatir las retransmisiones piratas. Como esas IPs son compartidas, el bloqueo arrastra a miles de webs legítimas que no tienen nada que ver: tiendas, medios y webs corporativas inaccesibles desde varios operadores españoles mientras dura el partido. Cloudflare lo pelea en los tribunales, pero sigue ocurriendo; si tu público está en España, es un riesgo real que hay que poner en la balanza.

Para quién: proyectos con tráfico alto o creciente donde la factura de ancho de banda manda, webs estáticas que quieren el mejor CDN gratuito del mercado, y equipos con algo de músculo técnico que prefieren pagar 5 $ donde otros pagan 200 $.

AWS: control total, con las mangas remangadas

AWS es la nube más usada del mundo y ofrece no una sino tres formas de desplegar Next.js, de menos a más trabajo:

1. S3 + CloudFront, para webs estáticas: los archivos se suben a un bucket de S3 y CloudFront los sirve como CDN global. Es la arquitectura de esta misma web y la desgranamos más abajo. Coste para una web corporativa: céntimos al mes.
2. AWS Amplify Hosting, la opción "estilo Vercel" de Amazon: conectas el repositorio y despliega solo, con soporte de SSR incluido. Menos pulido que Vercel y con menos compatibilidad fina, pero razonablemente cómodo.
3. OpenNext + SST, para SSR serio: el adaptador reparte Next.js entre Lambda (funciones), S3 (estáticos) y CloudFront (CDN), todo en tu propia cuenta. Máximo control, máxima responsabilidad.

Lo bueno: control absoluto de cada pieza (cabeceras, caché, seguridad, dominios, certificados), costes de infraestructura pura sin intermediario, e integración natural si tu backend ya vive en AWS — formularios con Lambda, correo con SES, lo que sea.

Lo menos bueno: AWS no te lleva de la mano. La curva de aprendizaje es real, la consola es un laberinto célebre y el tiempo de configuración inicial se mide en días, no en minutos. El ahorro en factura se paga en horas de ingeniería; si no las tienes en casa, el balance cambia de signo.

Para quién: empresas que ya operan en AWS, proyectos con requisitos finos de seguridad o cumplimiento, y webs estáticas gestionadas por una agencia que —como nosotros— amortiza la configuración entre varios proyectos.

Google Cloud: contenedores y escala a cero

La vía natural de Google Cloud para Next.js es Cloud Run: empaquetas la aplicación en un contenedor Docker (Next.js lo pone fácil con output: 'standalone') y Cloud Run lo ejecuta, escalando de cero a miles de instancias según el tráfico. Si nadie visita la web, no pagas nada; el precio es un arranque en frío ocasional de un par de segundos en la primera visita tras un rato de calma.

Para quien prefiera algo más guiado existe Firebase App Hosting, que entiende Next.js de fábrica: conectas el repositorio y él monta por debajo Cloud Run y el CDN de Google, al estilo Vercel. Y para la vía puramente estática, el veterano Firebase Hosting sigue siendo el atajo del ecosistema: un solo comando publica la web, y su archivo de configuración resuelve las URLs y las redirecciones sin pelearse con ningún CDN.

Lo bueno: el modelo de contenedor es el más portable que existe —ese mismo Docker corre en Azure, en un VPS o en tu portátil—, el escalado a cero es ideal para proyectos con tráfico irregular, y la factura es infraestructura pura.

Lo menos bueno: al ejecutar Next.js "tal cual" en un contenedor, las optimizaciones finas que dependen de infraestructura especializada (ISR distribuido, PPR servido desde el borde) funcionan en modo servidor clásico, no en su mejor versión. Y aunque menos que AWS, Google Cloud también pide oficio.

Para quién: equipos que ya trabajan con contenedores o en el ecosistema Google, aplicaciones con backend propio donde Next.js es una pieza más, y proyectos que valoran la portabilidad por encima del último truco del framework.

Azure: la opción del contrato ya firmado

Seamos francos: casi nadie elige Azure para Next.js por méritos técnicos del hosting; se elige porque la empresa ya vive en el ecosistema Microsoft y el contrato, el proveedor aprobado y el equipo de sistemas ya están ahí. Y es un motivo perfectamente válido.

Las rutas: Azure Static Web Apps para webs estáticas (con capa gratuita y despliegue desde GitHub Actions muy bien resuelto, herencia de que GitHub es de Microsoft), y App Service o Container Apps para SSR, ejecutando Next.js como aplicación Node o contenedor. Un detalle mejor resuelto que en la mayoría: las reglas de rutas, redirecciones y seguridad se declaran en un único archivo de configuración, legible y versionado junto al código. El soporte del Next.js con servidor, en cambio, sigue en fase de vista previa y con restricciones serias, así que la vía fiable para SSR en Azure es el contenedor, con las mismas ventajas y renuncias que en Cloud Run.

Para quién: organizaciones con Microsoft 365, Active Directory y política de proveedor único. Si no es tu caso, hay opciones mejores en esta lista.

Comparativa: Next.js en Vercel, Cloudflare, AWS, Google Cloud y Azure

La lectura honesta de la tabla: Vercel gana en experiencia, Cloudflare en economía, y las tres nubes grandes en control. No hay columna perfecta; hay proyectos distintos.

Costes reales: los dos mitos que conviene desmontar

Mito 1: "Vercel es caro". Para el 90 % de las webs corporativas, no lo es: con tráfico normal, el plan Pro de un solo asiento (unos 240 $/año) cubre de sobra una web que factura gracias a su presencia digital, y elimina un coste que en las otras nubes es invisible pero real: las horas de configurar y mantener infraestructura. Vercel se vuelve caro en dos escenarios concretos: mucho ancho de banda (vídeo, imágenes pesadas, tráfico masivo) y equipos grandes pagando por asiento.

Mito 2: "AWS es barato". La factura lo es; el coste total, depende. Nuestra web cuesta céntimos al mes en infraestructura, pero detrás hay horas de configuración de CloudFront, políticas de caché, cabeceras de seguridad y pipeline de despliegue que alguien tiene que saber hacer y mantener. Ese conocimiento nosotros lo amortizamos entre proyectos; para un equipo sin experiencia en AWS, esas horas valen más que años de plan Pro de Vercel.

Para ponerle números al ancho de banda, que es donde de verdad se separan las facturas: el exceso en el plan Pro de Vercel ronda los 0,15 $ por GB; CloudFront cobra 0,085 $/GB después de un terabyte mensual gratuito — y el tránsito interno de S3 a CloudFront no se factura —; Google Cloud y Azure se mueven entre 0,085 y 0,12 $/GB; y en Cloudflare la cifra es sencillamente cero. Con el tráfico de una web corporativa, todo esto es ruido; sirviendo terabytes de imágenes o vídeo, es la diferencia entre céntimos y una factura de cuatro cifras — hasta el punto de que hay empresas que mantienen la aplicación en su plataforma de siempre y mudan solo los archivos pesados a Cloudflare o Bunny.net.

Con horizonte de tres años y una web corporativa estática de tráfico moderado, la diferencia real entre proveedores es de decenas de euros al año — ruido comparado con lo que cuesta el desarrollo. La decisión de hosting solo mueve dinero de verdad cuando hay servidor, tráfico fuerte o equipo grande. Ahí es donde la tabla de arriba importa.

Cómo lo hacemos nosotros: esta web, en AWS

Esta misma web que estás leyendo es un export estático de Next.js 16 servido desde Amazon S3 con CloudFront como CDN. Pudiendo alojarla gratis en Vercel o Cloudflare, elegimos AWS por tres motivos que ilustran bien cuándo compensa este camino:

1. Ya vivíamos ahí. Los formularios de contacto de la web los procesa una función Lambda tras API Gateway; añadir el hosting a la misma cuenta simplifica dominios, certificados y facturación.
2. Control fino de las cabeceras. Al ser un export estático, las cabeceras de seguridad no pueden configurarse desde Next.js (eso requiere un servidor); en CloudFront se definen en una Response Headers Policy asociada a la distribución: HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy y una Content-Security-Policy ajustada a los orígenes exactos que la web usa. Ese nivel de control es justo lo que las plataformas gestionadas abstraen.
3. El coste es simbólico. Almacenamiento en S3 y tráfico de CloudFront para una web corporativa: céntimos al mes, literalmente.

¿El resultado se nota? Los números dicen que sí: 96/100 de rendimiento móvil en PageSpeed Insights con LCP de 2,2 segundos — las cifras completas, con confesión de error incluida, están en Next.js vs WordPress. Aunque la parte honesta es reconocer que una web estática bien hecha habría puntuado parecido en cualquiera de los cinco proveedores: la arquitectura pesa más que el logo del CDN.

Y la moraleja generalizable: elegimos AWS porque ya teníamos el conocimiento y la cuenta. Si no hubiera sido así, esta web estaría en Cloudflare o Vercel y no habríamos perdido nada importante.

El hosting no lo es todo: servicios externos que completan el stack

Elegir dónde se sirve la web resuelve solo una parte del proyecto. En cuanto hay usuarios, formularios o contenido multimedia aparecen necesidades que el hosting no cubre: una base de datos, correo transaccional, imágenes optimizadas, saber qué falla en producción. La forma moderna de resolverlas no es contratar un servidor más grande, sino componer servicios especializados, casi todos con capa gratuita — y con una propiedad que encaja con la tesis de este artículo: se conectan por URL y clave de API, así que funcionan exactamente igual desde Vercel que desde un contenedor en Cloud Run, y no te atan a ningún proveedor de hosting.

Los que más repetimos en proyectos Next.js:

Dos matices de quien ha montado unos cuantos de estos puzles. El primero: cada pieza gratuita es una factura potencial y un proveedor más que gestionar — añade servicios cuando el proyecto los pida, no como coleccionista; una web corporativa estática no necesita ninguno de la tabla, quizá salvo la analítica. El segundo, en la dirección contraria: estos servicios son justo lo que permite mantener la web estática o casi estática durante más tiempo — un formulario contra Resend o una búsqueda contra Supabase no obligan a convertir toda la web en una aplicación con servidor, y esa frontera bien defendida es la que mantiene el hosting en la casilla de los céntimos.

Nuestra recomendación según el proyecto

• Web corporativa, portfolio o blog (estática): cualquiera de los cinco sirve; Cloudflare si quieres la mejor capa gratuita, AWS si ya operas allí. La decisión es de céntimos: no le dediques más de una tarde.
• Aplicación con usuarios, SSR y equipo pequeño: Vercel. El sobreprecio se paga solo en tiempo de desarrollo no perdido.
• Proyecto con tráfico alto o creciente: Cloudflare. El ancho de banda gratuito cambia la economía del proyecto (con el matiz de los bloqueos de LaLiga si tu público está mayoritariamente en España).
• Empresa que ya opera en AWS, Google Cloud o Azure: su nube, con OpenNext (AWS), contenedor en Cloud Run (Google) o contenedor en App Service (Azure). La coherencia operativa vale más que la comodidad marginal.
• Presupuesto cero y proyecto personal: Cloudflare o el plan Hobby de Vercel (recordando que este último no admite uso comercial).
• Máxima portabilidad como requisito: contenedor Docker (output: 'standalone') desde el día uno; correrá igual en cualquier nube y en cualquier VPS.

¿Tu proyecto no encaja limpio en ninguna casilla? Es lo normal. En nuestro servicio de desarrollo web la infraestructura viene incluida en la conversación desde el primer día, porque el mejor despliegue es el que se decide antes de escribir la primera línea.

Conclusión: la arquitectura decide, el proveedor ejecuta

Si hay una idea que llevarse de este artículo es que la pregunta "¿dónde despliego Next.js?" se responde en dos pasos. Primero, la arquitectura: si tu web puede ser estática, la decisión es trivial y baratísima, y cualquiera de los cinco proveedores la servirá rápido y bien. Segundo, solo si hay servidor de por medio: Vercel compra tiempo, Cloudflare compra margen, y AWS, Google Cloud y Azure compran control — cada uno con su factura, en euros o en horas.

Lo que no recomendamos es decidirlo por inercia o por miedo: ni Vercel es un peaje obligatorio, ni AWS es territorio prohibido, ni el proveedor de moda es garantía de nada. Es una decisión de proyecto, como el framework o el CMS. Si quieres que la tomemos contigo —o que auditemos lo que ya tienes desplegado—, hablemos.