Vercel Hobby y el límite de 10GB: qué despliegues están en riesgo
Vercel Hobby puede borrar previews y puntos de rollback antes de 30 días si el equipo supera 10GB. Descubre qué protege y cómo revisar el historial.

En Vercel Hobby, los 30 días de historial de despliegues ya no garantizan que siempre haya un punto de rollback disponible. Desde el 16 de septiembre de 2026, si un equipo Hobby supera el límite de 10GB de Deployment Storage, Vercel puede eliminar de inmediato una preview antigua o un punto de restauración de producción que no esté cubierto por alguna excepción de retención.
El despliegue de producción actual sigue protegido. También lo están los despliegues con determinados alias y la preview más reciente de cada rama de Git activa. El cambio afecta a todo lo que queda fuera de esos grupos: un prototipo personal puede seguir funcionando mientras un enlace de revisión antiguo deja de hacerlo sin aviso.
Los 30 días ya no son un mínimo garantizado
La retención de despliegues determina durante cuánto tiempo Vercel conserva los archivos compilados de cada despliegue. Esos archivos permiten volver a abrir una preview anterior, llevar a producción una compilación ya probada sin generarla de nuevo o restaurar producción durante un incidente.
El periodo de retención habitual de Hobby sigue siendo de 30 días. La novedad es la regla de limpieza cuando se supera el límite: si el equipo consume más de 10GB de Deployment Storage, un despliegue sin protección puede quedar marcado para eliminación antes de que transcurran esos 30 días. Esa es la consecuencia práctica del cambio. El historial gratuito de despliegues ahora depende tanto del almacenamiento consumido como de las excepciones que se explican a continuación.
Cada proyecto Hobby conserva dos protecciones para despliegues recientes:
- Los últimos 3 despliegues creados, sin importar el tipo
- Los últimos 3 despliegues de producción con estado Ready
Hay que entenderlos como un único conjunto combinado, no como seis lugares reservados. Un despliegue de producción reciente puede pertenecer a ambos grupos. Si los tres despliegues más nuevos son también las tres versiones Ready más recientes de producción, solo esos mismos tres despliegues quedan protegidos por estas dos reglas.
Las previews ya no tienen un cupo propio de despliegues recientes. Una preview que no esté entre los tres últimos solo se conserva si cumple otra excepción.

Qué protege Vercel Hobby y qué puede desaparecer
La forma más clara de interpretar la regla es separar las protecciones que dependen de la antigüedad de las que dependen del uso que recibe el despliegue.
Estas excepciones proceden de las reglas actuales de retención de despliegues de Vercel. Guardar la URL de un despliegue no figura por sí solo entre las protecciones. Lo decisivo es la relación del despliegue con un alias, una rama, el estado de producción o su posición entre los más recientes.
Esta diferencia cambia un flujo de trabajo muy común. Es posible enviar una preview, fusionar el pull request y dar por hecho que el enlace seguirá disponible durante el resto del mes. En cuanto la rama deja de estar activa, termina la excepción que protegía su última preview. Si el equipo ya supera 10GB y el despliegue no está en ninguno de los dos grupos de tres más recientes, el enlace puede quedarse sin destino antes del día 30.
A quién afecta realmente este cambio
El caso más evidente es el de una persona que mantiene varios prototipos propios. Los proyectos antiguos pueden acumular archivos de compilación mientras los proyectos activos siguen generando despliegues. Cuando el equipo rebasa el límite, Vercel puede limpiar el historial no protegido de todo el equipo Hobby. Por eso, el punto de rollback que importa podría pertenecer a un proyecto que lleva tiempo sin tocarse.
Para quien comparte un concepto de diseño no comercial, el riesgo es distinto. La preview actual de una rama de revisión abierta está protegida; el enlace anterior que documenta una decisión de diseño quizá no lo esté. Si es imprescindible poder consultar esa compilación exacta, conviene asignarle un alias personalizado válido o adoptar otra estrategia de conservación antes de cerrar la rama.
Quien utilice los despliegues como reserva para rollbacks debería revisar el conjunto de producción reciente. Los últimos 3 despliegues de producción con estado Ready siguen protegidos, pero una versión estable anterior no está a salvo solo por tener menos de 30 días.
Un profesional independiente, una agencia o una empresa no debería basar la decisión de cambiar de plan únicamente en la retención. Hobby se limita al uso personal y no comercial. El trabajo comercial corresponde a Pro aunque consuma menos de 10GB, de modo que este cambio en el historial de despliegues refuerza una decisión de plan que ya existía.
Los equipos Hobby que no superan 10GB no entran en esta nueva limpieza inmediata. Sus despliegues siguen la política habitual de 30 días y sus excepciones. Los equipos Pro y Enterprise también quedan fuera de este cambio específico de Hobby: sus periodos de retención predeterminados y sus cantidades de despliegues recientes protegidos son mayores.
Cómo auditar el historial que todavía importa
La revisión debe empezar en el nivel del equipo. El límite de 10GB corresponde al equipo Hobby, pero las pistas útiles están repartidas entre distintos proyectos.
Revisa los dos medidores de almacenamiento
Selecciona el equipo correcto en Vercel, abre Usage y elige Deployment Storage. Examina tanto Deployment Storage, que incluye los resultados de compilación y los recursos estáticos, como Functions Storage, donde se contabilizan los paquetes de funciones. En cada métrica, abre Projects para localizar qué proyectos concentran más archivos almacenados.
Anota qué despliegues no puedes perder
En cada proyecto de gran tamaño, abre Deployments. Registra el despliegue que está en producción, la compilación de producción a la que realmente volverías, cualquier URL de preview que siga formando parte de una revisión o aprobación y toda compilación antigua necesaria para una auditoría o una comprobación de regresión. Esa lista define la necesidad; el registro de despliegues solo muestra el inventario.
Asocia cada despliegue imprescindible con una protección
Comprueba si cada elemento está entre los últimos 3 creados, entre los últimos 3 despliegues Ready de producción, si tiene un alias que cumple los requisitos o si es la última preview de una rama activa. No cuentes por separado los dos grupos de tres cuando un mismo despliegue aparezca en ambos.
Conserva la excepción o conserva el código fuente
Mantén activa la rama de revisión mientras todavía se necesite su última preview. Si encaja en el flujo de trabajo, asigna un alias personalizado a cualquier despliegue que no sea de producción y deba conservarse. Para el resto, verifica que el commit de origen, la configuración y los datos externos necesarios para reconstruirlo estén disponibles fuera del historial de despliegues.
Elimina el almacenamiento que ya no cumple ninguna función
Cuando las personas responsables confirmen qué se puede descartar, elimina los alias personalizados obsoletos y cierra los pull requests abandonados mediante el proceso habitual del repositorio. Después, revisa la vista Resources del despliegue más grande para detectar recursos estáticos o paquetes de Functions sobredimensionados. La página Usage permite localizar un proyecto, pero no identifica el archivo, despliegue o paquete exacto que origina el total.
La guía de optimización del almacenamiento de Vercel recomienda comparar, después de un cambio, el mismo equipo, las dos métricas de almacenamiento, los mismos proyectos y el mismo periodo de 30 días. La limpieza por retención y la reducción del tamaño de las compilaciones resuelven problemas diferentes: la primera disminuye con el tiempo el historial almacenado; la segunda reduce el tamaño de los nuevos despliegues.
La limpieza y Pro tienen efectos económicos distintos
Para un proyecto personal y no comercial, limpiar es la opción sin costo de suscripción. Implica renunciar al historial que ya no cumple ninguna función, reducir el tamaño de los resultados cuando sea posible y mantenerse por debajo del límite de Hobby. El costo es operativo: habrá menos previews antiguas que consultar y menos compilaciones de producción disponibles para un rollback.
Pasar a Pro no cuesta $0.10. En Pro, Deployment Storage y Functions Storage tienen cada uno un precio publicado de $0.10 por GB al mes, por lo que conservar 10GB de una de esas métricas durante un mes tiene un precio publicado de $1. Sin embargo, el plan parte de una cuota mensual de plataforma de $20, que incluye un puesto con capacidad de despliegue y $20 de crédito mensual para uso de infraestructura. Cada puesto adicional de Owner o Member con capacidad de despliegue suma otros $20 al mes. Los puestos Viewer son gratuitos.
La regla de decisión es sencilla. No hay que comparar «eliminar el historial» con «pagar $1 por almacenamiento», sino la limpieza con el plan mensual completo de $20. Después, se deben sumar todos los puestos de despliegue adicionales y comprobar si el crédito incluido cubre el almacenamiento real del equipo y el resto de su consumo de infraestructura. El desglose completo de precios de Vercel explica los demás componentes de la factura.
Para un prototipo personal, $20 al mes puede valer más que el historial conservado. En un proyecto comercial, los requisitos del plan resuelven la cuestión antes que la retención. Para un negocio con una sola persona a cargo del desarrollo que ya necesita Pro, la retención predeterminada más amplia y la protección de más despliegues recientes forman parte del valor que ya está pagando.
Qué conviene hacer el lunes
Si el equipo Hobby supera o está cerca de 10GB, el primer paso es abrir la página Usage e identificar qué proyectos concentran más Deployment Storage y Functions Storage. Después, hay que señalar los enlaces de preview y los puntos de rollback exactos que todavía cumplen una función de negocio o revisión. Esos elementos deben protegerse de forma deliberada; el historial que ya no sirve puede descartarse.
Si el equipo se mantiene con holgura por debajo de 10GB, no hace falta una limpieza urgente. Basta con tener presente la política habitual de 30 días, sobre todo antes de cerrar una rama cuya preview todavía necesita alguien.
Si el proyecto es comercial, la limpieza de Hobby no debe considerarse una estrategia a largo plazo. Hay que presupuestar la cuota completa de Pro, reservar el acceso de despliegue para quienes lo necesiten, asignar puestos Viewer gratuitos al resto y comparar esa factura con el costo de reconstruir un flujo de revisión o rollback perdido.
Para recibir cada semana un análisis como este, claro y directo, suscríbete al boletín.
- Última actualización
- 17 sept 2026
- Categoría
- Explained







