Era una noche de jueves y el sitio Next.js de un cliente acababa de entrar en lo que solo puedo describir como una espiral de timeouts. Funciones serverless colgadas en 9.8 segundos, usuarios viendo pantallas en blanco, y yo comprobando frenéticamente el panel de Vercel a medianoche tratando de averiguar si realmente habíamos alcanzado un límite del plan o si el código simplemente era terrible. (Fue ambos, honestamente.) Ese proyecto estaba en el plan Hobby. Probablemente no debería haber estado.
He desplegado bien más de 12,000 sitios en Seahawk Media a lo largo de los años. Vercel es parte de nuestro stack constantemente, especialmente para trabajo con Next.js, nada más se le acerca en términos de experiencia de desarrollador. Pero el plan Hobby tiene bordes afilados que son fáciles de pasar por alto hasta que un proyecto te muerde. Así que aquí está mi análisis real de dónde están esos bordes y cuándo empiezan a importar.
Qué Te Da Realmente el Plan Hobby
Seamos precisos. A partir de 2024, el plan Hobby de Vercel te da:
100 GB de ancho de banda por mes
6,000 minutos de compilación por mes
Tiempo máximo de ejecución de funciones serverless de 10 segundos
100 invocaciones de funciones serverless por día... espera, no. Ese límite no existe. Pero hay un límite de 100 GB-horas de ejecución de funciones serverless por mes
Ejecución de edge functions de 500,000 invocaciones por mes
1 compilación concurrente a la vez
Despliegues limitados solo a cuentas personales (sin equipos)
No se permite uso comercial según los términos de Vercel
Ese último es el que confunde a más gente que cualquier límite técnico. El plan Hobby es explícitamente para proyectos personales y no comerciales. Si estás desarrollando para un cliente que paga o ejecutando cualquier tipo de negocio en él, ya estás violando los términos de servicio. He visto a freelancers hacer esto durante años y es una responsabilidad esperando ocurrir.
El Tiempo Máximo de 10 Segundos de las Funciones
Este es el que afecta a la gente. Diez segundos suenan como mucho hasta que haces una llamada a una API de terceros que toma 4 segundos, ejecutas lógica de base de datos que suma otros 3, y luego haces algo con la respuesta. De repente estás en 9.2 segundos sin margen.
En el plan Pro ese límite sube a 60 segundos (y hasta 900 segundos con configuración en Enterprise). No es una diferencia menor. Es la diferencia entre una integración que funciona y un producto que está fundamentalmente roto para ciertos casos de uso.
Build Minutes: Dónde Desaparecen Más Rápido de lo Que Esperas
6,000 build minutes al mes suena generoso. Y para un proyecto personal único probablemente lo es. El problema es que ese número se erosiona más rápido de lo esperado una vez que estás iterando en serio.
En 2021 estaba ejecutando un proyecto paralelo, un agregador de contenido construido en Next.js con aproximadamente 400 páginas estáticas. Tenía ISR configurado pero también estaba haciendo reconstrucciones completas frecuentes mientras experimentaba con la capa de datos. Consumí aproximadamente 4,200 build minutes en tres semanas. No porque los builds fueran lentos, sino porque los estaba disparando constantemente.
Cada build en un sitio Next.js de complejidad media puede ejecutarse fácilmente 4-8 minutos. Si haces push a main 15 veces al día durante desarrollo activo (que es normal para mí), eso son 60-120 build minutes gastados en un solo día. Haz eso durante una semana y habrás consumido la mitad de tu asignación mensual.
No hay rollover. Los minutes no se transfieren de un mes a otro. Y cuando llegas a cero, tus deployments se detienen. Punto final.
Cómo Ralentizar el Consumo
Algunas cosas que hago en proyectos del plan Hobby para preservar build minutes:
Haz push a una rama que no sea producción para cambios experimentales. Solo haz merge a main cuando algo esté realmente listo.
Usa vercel --prebuilt con outputs cacheados donde los artefactos de build no hayan cambiado significativamente.
Configura el paso de compilación ignorado de Vercel para omitir compilaciones cuando solo ciertos archivos cambian (como actualizaciones de readme o commits sin código).
Agrupa los commits. En lugar de hacer push de 6 pequeñas correcciones por separado, prepáralas y haz push una sola vez.
Nada de esto es revelador. Pero en la práctica, la mayoría de los desarrolladores en planes Hobby simplemente hacen push libremente y se preguntan por qué se quedan sin minutos antes del 20 del mes.
Ancho de banda: Usualmente Bien, Ocasionalmente No
100 GB de ancho de banda al mes es donde el plan Hobby es realmente bastante razonable. Para un proyecto personal, un portafolio, un blog pequeño, incluso un proyecto SaaS lateral modesto con algunos cientos de usuarios, probablemente no alcances ese límite.
Donde duele es en sitios pesados en imágenes sin una capa CDN adecuada al frente, o sitios que reciben un pico repentino. Tuve un cliente, un músico, cuyo sitio estaba en mi cuenta Vercel personal durante un período de transición (incorrecto de mi parte, lo sé, uso comercial y todo eso). Una de sus canciones fue incluida en una playlist de tamaño decente y el sitio recibió alrededor de 40,000 visitas en 48 horas. El uso de ancho de banda se disparó. Afortunadamente estuvimos por debajo del límite pero fue lo suficientemente cercano como para que los moviera de Hobby inmediatamente.
Si estás usando Next.js Image Optimisation, ten en cuenta que las imágenes optimizadas servidas a través de Vercel cuentan contra tu ancho de banda. Y el plan Hobby tiene un límite de 1,000 imágenes de origen para optimización al mes. Es un límite del que casi nadie habla y te atrapará definitivamente si estás ejecutando un portafolio de fotografía o cualquier sitio con contenido pesado en imágenes.
El Tema del Uso Comercial Merece Más Atención
Quiero volver a esto porque creo que es genuinamente poco apreciado en los círculos de freelancers.