Vercel adds Dockerfile Functions and Services with VCR registry

• vercel shipped Dockerfile-based Functions, so Vercel Functions can now deploy any OCI image instead of forcing a single runtime path.
• vercel and rauchg introduced Vercel Services, which groups multiple services into one project with atomic deploys, rollbacks, a single preview URL, and private networking.
• vercel_dev added VCR, a container registry for storing team images that can be reused in Functions or Sandboxes.
• vercel_dev framed the pricing model around active CPU, while rauchg said the new Dockerfile path still scales to zero.
• vercel_dev also raised the Fluid compute package cap from 250 MB to 5 GB, and rauchg said function duration now reaches 30 minutes.

You can deploy any OCI image, browse the Services docs, and check the new Vercel Container Registry. The interesting bit is how cleanly these pieces fit together: Dockerfile Functions cover the runtime escape hatch, Services turns multi-framework apps into one deploy unit, and VCR gives those containers a home inside Vercel's own workflow.

The headline feature is simple: a Dockerfile now works as a function entrypoint on Vercel. According to vercel_dev, that means deploying any OCI image with automatic scaling, observability, and active-CPU billing attached.

The examples around the launch were aimed at runtimes Vercel historically did not own end to end. ctatedev described the update as opening the door to Go, Rails, Spring Boot, Express, Laravel, .NET, FastAPI, and even a web server behind nginx, while MelkeyDev highlighted a plain Go Dockerfile running unchanged on Vercel.

Services is the second half of the launch. Instead of splitting a stack across separate projects, vercel_dev said teams can declare multiple services under a services key in vercel.json and route between them explicitly.

rauchg summarized the behavior as one Vercel project for a Python API, an Express server, and a React SPA, with:

• local runs through vc dev
• atomic deployment and rollback
• shared observe, monitor, and debug flows
• internal networking between services

The official docs describe the same model in more formal terms: Vercel Services gives a full-stack app one preview URL and a private network between its components.

VCR is Vercel Container Registry. vercel_dev said it stores a team's container images so they can be used in Functions or Sandboxes.

That fills in a missing platform piece. Dockerfile Functions lets Vercel execute arbitrary images, Services organizes multi-service apps around them, and VCR keeps those images inside Vercel's own deployment path instead of pushing teams toward an external registry for every step.

Vercel also widened the function envelope. vercel_dev raised the Fluid compute package limit to 5 GB, a 20x jump from the old 250 MB cap, specifically calling out Python data and AI libraries, browser automation, image processing, and larger backend apps.

The time limit moved too. In a reply about the same rollout, rauchg said functions now run for up to 30 minutes, with other long-duration form factors still coming.

That last change matters because it turns the Dockerfile launch from a packaging story into a workload story. The new cap gets heavier dependencies through build and deploy, and the 30-minute ceiling gives those containers room to do more than short request-response work.