Vercel sube a 2 GB el límite de capas de su registro Docker

Vercel eleva a 2 GB el límite por capa de su Container Registry

Vercel subió de 500 MB a 2 GB el tamaño máximo de cada capa comprimida de imagen en su Container Registry, un salto de 4x que deja intacto el tope total de 15 GB por imagen. Para un equipo pequeño, la lectura práctica es directa: si tu Dockerfile tenía capas partidas artificialmente para esquivar el límite anterior, ese trabajo ya no hace falta.

El registro sigue funcionando con los comandos estándar de Docker —docker push, docker pull y docker tag— y el repositorio se crea automáticamente en el primer push. La línea que documenta Vercel es docker buildx build --push -t vcr.vercel.com/team/project/repository:tag .

¿Por qué importa el tamaño de una capa y no solo el total?

Una imagen de contenedor es una pila de capas: cada instrucción del Dockerfile genera una, y Docker reutiliza las que no cambiaron. El límite por capa define cuánto puede pesar un solo bloque; el límite total define cuánto puede pesar la suma.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Con un techo de 500 MB por capa, los proyectos que arrastran artefactos pesados —pesos de modelos, runtimes con librerías de GPU, monorepos con dependencias enormes— tenían que repartir ese contenido en varias capas o sacarlo de la imagen y descargarlo en tiempo de ejecución. Con 2 GB por capa, ese reparto forzado desaparece en la mayoría de los casos.

Lo que no cambia es el tope de 15 GB por imagen. Si tu build se pasa de ahí, el problema no era la granularidad de las capas: es el tamaño del artefacto, y se resuelve con builds multi-etapa, imágenes base más livianas o dejando fuera lo que no hace falta en producción.

Login OIDC en GitHub Actions: menos secretos guardados

El cambio menos visible es probablemente el más valioso desde seguridad. Vercel permite autenticar workflows de GitHub Actions con la acción vercel/vcr-action/login usando GitHub OIDC, lo que elimina la necesidad de credenciales de registro de larga vida.

Traducción para un equipo chico: en lugar de guardar un token del registry como secreto de repositorio —que hay que rotar, que se filtra en un log y que alguien termina copiando a un archivo de entorno—, el workflow pide un token efímero a GitHub y Vercel lo valida. Menos superficie de ataque y menos tareas de mantenimiento.

Repositorios públicos y compartidos entre equipos

Los repositorios del registro pueden hacerse públicos para acceso de solo lectura por cualquier equipo de Vercel, o compartirse con equipos específicos —hasta 100— desde el dashboard o con vercel vcr permissions.

Vercel indica que las Vercel Managed Images sobre las que corre Vercel Sandbox se sirven desde repositorios públicos comunes, construidos con la misma función que cualquier equipo puede usar para sus propias imágenes. Es una señal de que la compañía usa internamente el mecanismo que ofrece a sus clientes, aunque también implica que esa forma de publicación es central para su propio producto.

Para gestionar repositorios, imágenes y tags hay comandos vercel vcr disponibles desde Vercel CLI v58.3.0 o superior. Y si la optimización en segundo plano de una imagen falla, el dashboard la marca con estado de error: volver a hacer push de la misma imagen reintenta la conversión.

¿Cómo se comparan los registries de AWS, Azure y Google?

Vercel entra a un terreno donde los precios y las estructuras cambian mucho según el proveedor. La comparativa de TechTarget sobre registries de nube describe tres modelos: AWS ECR cobra por almacenamiento y por ancho de banda, con transferencia gratuita hacia instancias EC2 en la misma región; Azure Container Registry divide el servicio en tres niveles con precio fijo diario y almacenamiento incluido, cobra el ancho de banda aparte y factura los builds a US$0.00005 por segundo de CPU; Google Container Registry se parece a ECR en estructura y guarda los datos en un bucket multirregional por defecto.

La redundancia geográfica también separa a los tres: Google la ofrece por defecto, Azure permite configurar geo-replicación solo en su nivel premium y ECR está diseñado como servicio regional, siempre según la misma comparativa de TechTarget.

El contexto de por qué los equipos terminaron mirando registries privados viene de antes. Cuando Docker Hub empezó a limitar la tasa de pulls en sus planes anónimos y gratuitos, Amazon recomendó identificar las imágenes públicas en uso y copiarlas a un registro privado como ECR, o pasar a una suscripción paga, según reportó SD Times. En ese mismo movimiento, AWS anunció un registro público propio para distribuir imágenes.

¿Qué significa esto para tu startup?

Revisa tu Dockerfile y borra las capas artificiales. Si en algún momento partiste un artefacto grande en dos o tres capas solo para no pasar de 500 MB, consolídalas. Menos capas también significa un Dockerfile más legible para quien entre al equipo después.
Migra el login de tu CI a OIDC. Si guardas un token del registry como secreto en GitHub, cambia a vercel/vcr-action/login. Es una de las mejoras de seguridad con mejor relación esfuerzo/beneficio que puedes hacer esta semana.
Mide el total antes de celebrar. El tope de 15 GB por imagen sigue ahí. Un docker image inspect sobre tu imagen de producción te dice si el cuello de botella real era la capa o el tamaño total.
Usa repositorios compartidos para las imágenes base. Si tu equipo mantiene una imagen base común para varios servicios, publicarla y compartirla con permisos explícitos evita el clásico de que cada repo se construya su propia base y ninguna coincida.

Conclusión

El cambio de 500 MB a 2 GB por capa es de esos que no generan titulares grandes pero sí eliminan fricción diaria: menos capas, builds más simples y un registro que ya no obliga a diseñar el Dockerfile alrededor de una limitación. Sumado al login por OIDC y a los permisos por equipo, Vercel empuja su registro como una pieza más de la plataforma y no como un servicio aparte.

Para un founder, la pregunta útil no es si el número es grande, sino si su pipeline actual sigue pagando el costo de un límite que ya no existe.