Vercel Container Registry No Longer Needs Raw Docker Commands
A new vercel vcr command group builds, pushes and manages container images from the terminal, instead of routing everything through raw Docker.

Vercel’s CLI can now build, push and manage container images without shelling out to Docker first. A new vercel vcr command group, shipped Aug. 20, 2026, wraps Vercel Container Registry (VCR) in first-party tooling: authenticate, build-and-push in one step, and inspect repositories and tags, all from vercel itself (Vercel changelog, Aug. 20, 2026).
What shipped
vercel vcr login docker authenticates Docker, Podman or Buildah against VCR with a short-lived token scoped to the current project, replacing the manual credential dance a registry normally requires. vercel vcr build docker --push builds the current directory and pushes it in one step; vercel vcr build docker ./app my-api:1.2.3 --push does the same with an explicit path and tag (Vercel CLI docs, “vercel vcr”). Repositories still create themselves automatically on first push, or explicitly via vercel vcr add, and standard tooling keeps working unchanged — docker push vcr.vercel.com/<team>/<project>/<repo>:<tag> still lands an image the same way it did before the CLI existed.
VCR itself is not new. It launched in beta June 30, 2026 at Vercel Ship, alongside Dockerfile-based Vercel Functions, with 10 GB of image storage included per month and $0.10 per GB-month beyond that (Vercel changelog, “Introducing VCR,” June 30, 2026; Container Registry limits and pricing). Until this update, using it meant treating VCR like any other OCI-compliant registry: raw docker login and docker push, no visibility into repositories or tags without leaving the terminal for the dashboard. A separate, smaller change landed days earlier too — vercel vcr config <repository> --public <true|false> toggles a repository’s visibility from the CLI, the kind of incremental surface area that signals the registry is still being actively built out, not left to coast on its beta launch.
Why this matters
Vercel has spent this year turning containers from an edge case into a supported path: Dockerfile Functions in June let any language deploy like a Next.js app, Vercel Sandbox picked up managed container images in August, and a microservices beta reorganized multi-service projects around services as first-class configuration. Each of those pieces needed somewhere to store an image, and until now that somewhere was a bare registry endpoint a developer had to talk to with generic Docker commands. Native CLI support is the unglamorous last step that makes VCR feel like part of the platform rather than infrastructure bolted on next to it. It’s the same shift Vercel made years ago when it stopped treating deployments as “just upload some files.”
It’s still not a complete container platform. Vercel has no Docker Compose deployment target — running several services together means using services inside one project, not pointing a Compose file at Vercel — so teams with an existing multi-container docker-compose.yml still have rework ahead of them regardless of how good the registry tooling gets.
Key Takeaways
vercel vcris a new CLI command group:login,build --push,add, and repository/tag inspection, all without leaving the terminal.vercel vcr build docker --pushbuilds and pushes in a single command; short-lived, project-scoped tokens replace manual registry credentials.- VCR launched in beta June 30, 2026, with 10 GB of included storage and $0.10/GB-month beyond that; raw
docker pushtovcr.vercel.comstill works unchanged. - Vercel still has no Docker Compose deployment target — multi-service projects use its
servicesconfiguration instead.
What to do
If a project already pushes to VCR by hand, swap in vercel vcr login and vercel vcr build --push to cut the credential setup out of CI. Teams still deciding whether to adopt VCR at all now have one less reason to hold off: registry management no longer means bouncing between generic Docker commands and the Vercel dashboard to see what’s actually stored.


