Self-hosting de Next.js con Docker o Vercel: cuando gana cada uno

Hacer self-hosting de Next.js significa ejecutar tu build de produccion con output: 'standalone' dentro de un contenedor Docker, en un servidor que controlas tu, en lugar de hacer push a Git y dejar el runtime en manos de Vercel. El codigo de la aplicacion es identico en ambos casos. La decision va de quien carga con el trabajo operativo y que te da ese trabajo a cambio: coste, control y limites.

La diferencia pesa sobre todo cuando un SaaS pasa del trafico de proyecto personal al uso real. En una app pequena, el plan gratuito de Vercel es dificil de discutir. En una app que sirve cientos de miles de visitas al mes, la factura y los limites de la plataforma empiezan a condicionar las decisiones de arquitectura. Aqui abajo tienes la comparacion que usamos cuando un cliente nos pregunta donde desplegar. Si ademas estas eligiendo runtime a nivel de funcion, esa es otra decision que cubrimos en edge runtime vs node runtime.

La version corta

Elige Vercel cuando el equipo es pequeno, el trafico es imprevisible y el tiempo de quien programa vale mas que la factura de hosting. Elige Docker self-hosted cuando el trafico es constante y alto, cuando necesitas procesos largos que las funciones serverless cortan, o cuando la residencia de los datos y el control del gasto pesan mas que la comodidad. Casi todos los productos empiezan por lo primero y pasan a lo segundo solo cuando lo obligan los numeros.

Vercel o Docker self-hosted: la comparacion honesta

Donde gana el self-hosting

El coste a gran escala

Una carga de 500.000 visitas al mes que en Vercel cuesta unos 600 $ puede bajar a unos 90 $ en un VPS gestionado con Coolify, alrededor de un 85% menos (MassiveGRID). El ahorro viene del precio fijo del servidor: sin coste por usuario, y sin recargo de ancho de banda a 0,15 $ por gigabyte mas alla del terabyte incluido (precios de Vercel).

Sin techo de ejecucion

En el plan Pro, las funciones de Vercel se paran a los 300 segundos (limites de las funciones de Vercel). Un proceso Node self-hosted puede generar un informe, un PDF o una llamada larga a un modelo de IA durante todo el tiempo que haga falta.

Los datos junto al computo

Puedes ejecutar Postgres en la misma red Docker que la app y bajar la latencia hacia la base de datos casi a cero. Ayuda con datos regulados que tienen que quedarse en una region concreta, y con consultas frecuentes que pagan un coste de ida y vuelta en una base de datos gestionada.

Sin lock de plataforma

El output standalone es Node puro. Corre en cualquier VPS, cualquier nube, o en Kubernetes. Cambiar de proveedor es un nuevo despliegue, no una reescritura.

Donde gana Vercel

Cero operaciones

Despliegues con git push, SSL automatico, ningun servidor que parchear. Para un founder en solitario o un equipo de tres, las horas que ahorras valen mas que la factura.

La red edge y el pipeline de imagenes funcionan solos

CDN global, optimizacion de imagenes e ISR funcionan sin configuracion. En self-hosting, cada una es un trabajo que asumes tu, y algo que se puede romper.

Las preview en cada pull request

Incluidas. Quien revisa abre una URL en vivo por cada rama sin pensarlo.

Escala sin que lo vigiles

Los picos de trafico son problema de la plataforma, no un aviso a las dos de la manana para quien este de guardia.

Los detalles que nadie cuenta hasta produccion

sharp

La traza standalone a menudo deja fuera sharp, el modulo nativo que Next.js usa para optimizar imagenes. Lo instalas a mano en la fase runner del Docker o las imagenes se rompen en el primer despliegue (guia de self-hosting de Next.js).

La cache ISR

Por defecto, la cache es el sistema de archivos local de una sola instancia. Levanta dos instancias detras de un balanceador y se desincronizan. El ISR multi-instancia necesita un cache handler propio sobre almacenamiento compartido, normalmente Redis (guia de self-hosting de Next.js).

Los archivos estaticos

El servidor standalone sirve los archivos estaticos, pero no esta pensado para eso. Bajo carga, servir los assets desde Node le quita CPU al renderizado. Pon delante una CDN o Nginx.

El uptime

Ningun SLA gestionado. Si el VPS se cae, la app se cae. Antes de lanzar, cuenta con monitorizacion, backups y una via de rollback, no despues del primer corte.

Que usamos nosotros y por que

Para las nuevas builds de SaaS empezamos por Vercel. Al principio el trafico es desconocido y el equipo es pequeno, asi que pagar por tener cero operaciones es la decision correcta. Nuestra propia web la llevamos igual. Cuando un producto alcanza un trafico estable y previsible, o necesita procesos largos, o maneja datos con reglas de residencia, lo movemos a una build Docker self-hosted detras de un proxy inverso, con Redis para la cache ISR y una CDN delante de los assets estaticos. El momento del cambio nunca es cuestion de principios. Es el mes en que la factura de Vercel, o un limite de la plataforma, cuesta mas que el tiempo operativo de llevarlo en casa. Quien hace self-hosting reporta unas cinco horas para montar el pipeline y entre 10 y 20 horas al ano para mantenerlo (Autonoma). Cuenta ese tiempo antes de decidir.