Vercel Just Ate Your Backend

On June 30, 2026, Vercel shipped four products in one day. Read them separately and you see feature updates. Read them together, and the company just turned itself into a different kind of business.

The four: Vercel Services (run multiple frameworks in one project), VCR — Vercel Container Registry (an OCI-compliant image registry), Run any Dockerfile on Vercel (Dockerfile.vercel is now a first-class citizen), and Vercel Sandbox custom images (boot a sandbox from your own root filesystem). (vercel.com/blog/dockerfile-on-vercel, vercel.com/blog/vercel-services-run-full-stack-on-vercel, vercel.com/changelog/introducing-vcr-vercel-container-registry)

Vercel is no longer selling you a frontend platform. It just shipped the missing pieces to host your entire backend. The line between "deploy tool" and "cloud" just got blurry.

What "full stack on Vercel" actually means

For years, the standard Vercel-plus-backend pattern looked like this: Next.js on Vercel, a Go or Python service on Railway or Fly, a database on Neon, secrets in .env, and CORS rules held together with prayer.

Vercel Services breaks that pattern. You declare multiple services in vercel.json — a Next.js frontend, a FastAPI backend, a worker — and Vercel handles builds, routing, internal traffic, and atomic rollbacks for the whole graph. Services talk to each other over a private network. The frontend reaches the backend through BACKEND_INTERNAL_URL, an env var Vercel injects at deploy. No public routing. No CORS. (vercel.com/blog/vercel-services-run-full-stack-on-vercel)

The dashboard now shows a service graph, not a list of deployments. Logs filter by service. vercel dev runs the whole stack locally. This is the workflow you had to glue together yourself last year. Vercel just absorbed the glue.

The container registry matters more than the Dockerfile

A Dockerfile on Vercel would have been useless without something to fix the cold-start problem. Container images are large, and "download the whole image, then run" kills serverless economics.

VCR solves it. When you push to the registry, Vercel precompiles the image in the background into the same "optimized boot image" format Sandbox Snapshots use. When a container boots, the platform streams the snapshot and decompresses on demand — your server starts handling requests before the full image is in place. (vercel.com/blog/dockerfile-on-vercel, vercel.com/blog/optimizing-vercel-sandbox-snapshots)

This is the piece that lets Vercel claim "container" without breaking serverless. The Dockerfile is the API. The boot snapshot is the magic. VCR is the storage that makes the magic repeatable.

The pricing tell

Look at the pricing model and the strategy becomes obvious. Vercel bills Active CPU time — the period your code is actually executing, not wall time. (vercel.com/blog/introducing-active-cpu-pricing-for-fluid-compute)

An idle Rails server parked on a slow query doesn't burn money. A long-running agent waiting on a model API doesn't burn money. This pricing only makes sense if Vercel wants the workload mix that spends most of its time idle: AI agents, async jobs, scrapers, model pipelines.

They are not chasing the "always-on SaaS backend" market — AWS, Fly, Railway have that locked up. They are chasing the workload mix that the next five years of AI software will create. A static Rails app on Vercel is fine. A 200-agent fleet that mostly waits on tokens is the bull case.

What this breaks

Three things just got weaker:

1. Railway, Render, Fly.io. The "Vercel doesn't do backend" objection is gone. You can now run a Rails API on Vercel with the same git push workflow you use for Next.js. The migration cost of consolidating onto Vercel just dropped to a weekend.
2. AWS App Runner, GCP Cloud Run, ECS Fargate. The "Vercel is a frontend tool, real backends go to a real cloud" story is harder to tell when the same dashboard hosts both.
3. ECR, Docker Hub, GHCR as a default. VCR is OCI-compliant, so the lock-in is light. But once your build pipeline pushes to VCR and your Functions and Sandboxes pull from VCR, you stop noticing the registry exists. That's the lock-in you don't see coming.

Six days earlier, on June 17, Vercel Connect shipped — short-lived credentials agents request at runtime, scoped to the task. (vercel.com/blog/vercel-connect) No more long-lived .env secrets leaking through agent logs. The platform is being built in pieces, and each piece removes a reason your backend lives somewhere else.

Functions on Pro and Enterprise can now run for up to 30 minutes, and Python backends can ship with up to 500 MB of dependencies. (vercel.com/changelog/vercel-functions-can-now-run-up-to-30-minutes) That single line item — 30-minute functions — is the change most people will underestimate. It quietly turns Vercel into a viable home for batch jobs, video transcoding, long-running scrapers, and the slow tails of agent workflows. Workloads that used to require a separate worker tier now live next to your frontend.

The unit economics argument

Most teams that move off Railway or Fly to Vercel won't move because of features. They'll move because of billing.

Active CPU pricing plus per-second granular billing plus a built-in CDN plus built-in observability plus zero-config TLS plus a registry that already authenticates with your deploys — that bundle is hard to assemble elsewhere without a FinOps team. AWS gives you each piece; AWS does not give you a single number on the invoice that matches your code's behavior.

Vercel's bet is that the next wave of applications — agentic, idle-heavy, multi-service — will care more about a single predictable bill than about picking the cheapest primitive for each workload. The 2019-era playbook of "frontends in Vercel, long-running in Fly, queues in Upstash, database in Neon, secrets in 1Password" only made sense when the integration tax was low. The integration tax is now high. Vercel is making the tax disappear at the cost of higher per-unit prices. For the right kind of workload, that trade pays.

The line between "deploy tool" and "cloud" is gone

Vercel still bills itself as "the frontend cloud." Read the changelog from the last month and that copy is out of date. Compute, registry, sandboxed agent execution, queues, workflows, cron, marketplace databases, secure networking, short-lived credentials — the list of "things a backend needs" that Vercel now ships natively is longer than the list of things it doesn't.

The honest read: Vercel is becoming the cloud for AI-shaped applications — small frontends, lots of async work, agents that spin up code and throw it away, services that talk to other services, and a registry that holds the container images doing all of it. It is not trying to be AWS. It is trying to be the cloud for the kind of software that didn't exist in 2019.

If you are paying Railway plus Cloudflare plus Vercel for one app, the urge to consolidate just got strong. The question is not whether Vercel can do your backend. It can. The question is whether Vercel becomes your cloud, or just your favorite deploy button.

The way to find out: ship one service on Vercel this quarter. Not a migration. A small new service. See what breaks. See what surprises you. By the time you have a real answer, the feature list will have moved twice.

---

Sources: Run any Dockerfile on Vercel · Vercel Services: Run full stack on Vercel · Introducing VCR: Vercel Container Registry · Vercel Sandbox custom images · Vercel Connect · Active CPU pricing · Optimizing Sandbox Snapshots · Next.js 16.3: Instant Navigations