Vercel Puts Your Whole Stack in One Project, One Preview URL

Vercel opened beta access to Vercel Services on July 1, a platform change that lets a Next.js frontend and a FastAPI, Flask, Express, Hono, Go or Rust backend deploy from the same project instead of two separate ones (Vercel changelog, July 2026). The feature, announced in June at Vercel’s Ship 2026 conference in London, targets a workaround developers have lived with for years: splitting a monorepo across multiple Vercel projects just to run a non-Next.js backend alongside the frontend.

Key Takeaways

• Vercel Services entered beta July 1, 2026, open on all plans, following its Ship 2026 announcement (Vercel blog).
• A project can now hold multiple services (independently built units, each auto-detected and provisioned for its framework), including first-class Go and Rust support alongside FastAPI, Flask, Express and Hono.
• Every commit gets one shared preview URL spanning the frontend and every backend service, and deploys are atomic: everything ships or rolls back together.
• Service bindings let one service call another directly, without a public route. Vercel injects the target’s URL into an environment variable, and the call stays off the internet (Vercel changelog).
• Billing follows existing Vercel Functions pricing (Active CPU, memory, invocations, Fluid compute); binding calls are billed as service requests, separate from CDN requests (Vercel docs).

The workaround this replaces

Before Services, a full-stack change that touched a frontend, an API layer and a background worker meant three separate Vercel projects, three preview deployments, and someone stitching the URLs together by hand to test the change end to end. Routing between those projects went over the public internet even when the traffic was purely internal, and a rollback on one project didn’t guarantee the others rolled back with it.

Vercel Services collapses that into one project. Services are declared with a services key in vercel.json, and incoming requests route to the right one via rewrite rules at request time. A service stays internal by default; a project only exposes it publicly if a top-level rewrite says so (Vercel docs).

Private calls, atomic deploys

The part with no precedent on Vercel before now is service bindings. When one service declares a binding to another, Vercel injects the target’s URL as an environment variable the calling service reads at runtime, and the request never leaves Vercel’s internal network (Vercel changelog). That closes a gap that mattered for anything handling credentials or internal data. A backend calling another backend no longer needs a public endpoint just to talk to itself.

Atomic deployment is the other half. Frontend, backend and any other services in a project deploy and roll back as one unit, so a backend-only change still builds against a full, working preview of the entire stack rather than a solo function.

Vercel’s take, and the trade-off it doesn’t mention

Vercel frames the underlying model, framework-defined infrastructure, as anti-lock-in: write code for your framework, and Vercel provisions the infrastructure around it rather than making you write to a Vercel-specific API (Vercel blog). That’s a defensible claim at the level of application code.

It’s a harder claim to make about the operational layer Services adds on top. Routing rules, service bindings and environment-variable injection now live in vercel.json and are specific to how Vercel wires services together. There’s no standard this maps onto elsewhere. A team that adopts bindings for internal service-to-service auth is writing infrastructure-as-config that doesn’t travel to another platform without a rewrite. None of that makes Services a bad feature. The preview-URL and atomic-deploy problems it solves were real, and the old multi-project workaround was painful. It does mean the convenience comes bundled with more Vercel-specific surface area to migrate away from later, not less.

What to do

Services is in beta on every plan, so trying it doesn’t require an enterprise contract or a waitlist approval. Teams already fighting multi-project monorepo setups are the clearest fit: add a services block to vercel.json, confirm which services need public rewrite rules, and check the new pricing model before moving anything that pushes meaningful traffic through a binding, since service requests bill separately from ordinary CDN requests.