Vercel activa Basic build machines para Pro y Enterprise

Qué cambió exactamente en los planes de Vercel

Vercel abrió la opción de Basic build machines para cuentas Pro y Enterprise. El hardware detrás de esa opción es modesto a propósito: 2 vCPU y 8 GB de RAM, con una tarifa de US$0,0035 por vCPU por minuto, lo que en la práctica son US$0,007 por minuto de build.

El cambio fue publicado en el changelog de Vercel y llega pocos meses después de que las Elastic build machines pasaran a disponibilidad general (GA) —esas son las que ajustan recursos automáticamente y siguen siendo la recomendación por defecto para nuevos proyectos en Pro y Enterprise. En otras palabras: Vercel mantiene una opción "barata y predecible" al lado de la opción "caro y elástico", y ahora deja elegirla desde la configuración del proyecto, el panel del equipo o la CLI (vc project update --build-machine basic con vercel CLI 59.6.0 o superior).

Un detalle útil para founders con cuenta Hobby: las máquinas que ya usaban Hobby (también 2 vCPU) ahora simplemente se renombran como Basic, así que no hay cambio de tarifa para quienes estén en ese tier gratuito.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Cuándo tiene sentido pagar menos por build?

Basic build machines están pensadas para aplicaciones pequeñas, micrositios o agentes que compilan con pocos recursos. Si tu proyecto cabe en 2 vCPU y 8 GB sin tirar timeouts, no necesitas pagar elástico.

En la práctica, los casos donde conviene activarlas son:

Landing pages y sitios de marketing en Next.js, Astro o SvelteKit con pocas rutas estáticas y poco código de servidor.
Agentes internos y bots que generan artefactos web sencillos (v0-style, sitios one-shot, herramientas internas) y no mueven grandes dependencias.
MVPs y side projects que están pre-tracción y donde cada minuto de build pesa en la factura de fin de mes.
Proyectos con builds muy frecuentes y livianos —el costo por minuto se vuelve relevante cuando se acumulan cientos de builds al día.

Donde no conviene: monorepos grandes, builds con compilación pesada (Rust, imágenes Docker, generación de PDFs en build time, etc.), o proyectos donde la variabilidad del tiempo de build justifica el escalado automático de las Elastic.

La lectura de fondo: Vercel está segmentando su pricing

Que Vercel publique Basic como opción explícita —en lugar de dejar las Elastic como único plan— es un movimiento interesante para una compañía que en septiembre de 2025 cerró una Serie F de US$300 millones con valoración de US$9.300 millones, según reportó Reuters. La empresa tiene 550 empleados a 2025, mantiene Next.js como framework open source de referencia y aloja alrededor del 1,9% de todos los sitios web del mundo según W3Techs (cifra recogida por Wikipedia). A esa escala, cualquier decisión de pricing es un termómetro de hacia dónde se mueve la estrategia de márgenes.

La movida confirma dos tendencias que se ven en el sector PaaS:

Más granularidad en planes de cómputo, dejando al cliente elegir entre "predecible y barato" (Basic) y "variable y cómodo" (Elastic). Es la misma lógica que ya aplican AWS, GCP o Fly.io con sus tiers de instancias.
Diferenciación por perfil de usuario: el founder que apenas arranca no debería pagar lo mismo que el equipo de ingeniería con CI/CD pesado. Hasta ahora, Vercel cobraba por minutos de build a una sola tarifa; ahora separa el costo del hardware subyacente.

Para un founder hispanohablante esto es relevante porque el grueso del ecosistema startup en LATAM y España corre workloads chicos, no plataformas tipo Netflix. Pagar Elastic para una landing de 10 páginas es tirar dinero.

¿Qué significa esto para tu startup?

Si hoy despliegas en Vercel Pro o Enterprise, el switch está a un comando de distancia. Tres acciones concretas para esta semana:

Audita tus proyectos: entra al dashboard y revisa cuánto dura cada build. Si la mayoría termina bien por debajo de los 2 vCPU disponibles, cambia a Basic desde Project Settings → Build and Deployment → Build Machine, o vía CLI con vc project update --build-machine basic.
Mide el ahorro durante 30 días: deja Basic en dos o tres proyectos de bajo tráfico y compara la factura de builds contra el mes anterior con Elastic. La diferencia puede ser material si tienes varios proyectos satélite.
Deja Elastic en lo que de verdad escale: monorepos, apps con SSR pesado o builds de imágenes deben quedarse en Elastic. La nueva opción no es para ahorrar a cualquier costo, es para no pagar de más donde no hace falta.

Si empiezas desde cero, prueba primero Basic; si empiezas a ver timeouts o builds que se quedan cortos de memoria, sube a Elastic. Es un toggle, no una commitment.