Vercel launches Vercel Services—unified frontend and backend deployment in one project

Vercel has introduced a new capability called Vercel Services, which allows running multiple frameworks — for example, a Next.js frontend and a FastAPI backend — within a single Vercel Project with shared deployments and internal networking between services.

How to configure Vercel Services

Services are described in the vercel.json file under the "services" key: for each service, you specify the path (root) and framework or entry point (entrypoint), and public traffic routing is configured via rewrites. Public traffic can be directed only to the frontend service, leaving the backend accessible exclusively from within the project.

• Service configuration — via the "services" key in vercel.json
• Example from Vercel documentation: my_frontend service on Next.js and my_backend service on FastAPI (entrypoint main:app)
• Backend in the example has no public route — only accessible to my_frontend service through internal networking
• The Deployments panel shows visualization of the service graph, and the Logs UI allows filtering logs by individual service
• The command vercel dev automatically launches all services locally, replicating the production environment

What problem does combining services solve

Previously, teams that combined a JavaScript frontend and, for example, a Python backend in a single product typically had to split them across different cloud platforms: Vercel has historically been strong in frontend deployment based on Next.js, while backend services on FastAPI, Django, or Flask typically went to separate hosting platforms. In practice, this meant two independent CI/CD systems, two sets of logs and monitoring, and manual synchronization of frontend and backend versions with every release. Vercel Services closes this gap: configuration of multiple full-fledged frameworks and services is described in one vercel.json file, rather than assembled manually from settings of different platforms.

What atomic deployments and service bindings provide

Atomic deployments ensure that frontend, backend, and other project services deploy and rollback in sync, not separately. Shared preview deployments show how a single change affects all services at once. A separate bindings configuration allows services to call each other directly, bypassing the public internet: for example, the key BACKEND_INTERNAL_URL is automatically passed to the frontend's environment variables and points to the backend's internal address.

What this means

Vercel Services closes a long-standing gap between frontend and backend parts of a single product, which previously often lived in different clouds with their own development and deployment processes. For teams combining a JavaScript frontend and, for example, a Python backend on FastAPI, this means unified deployment, shared preview flow, and direct internal connectivity between services without reverse proxies and CORS configuration. For the platform, this is also a way to retain within its ecosystem teams that previously left with the backend portion of the project to third-party hostings simply because Vercel did not offer a convenient way to keep the entire stack in one place.

Frequently asked questions

What is Vercel Services?

It is a Vercel capability to run multiple services — for example, a Next.js frontend and a FastAPI backend — within a single Vercel Project with shared routing, atomic deployments, and automatic scaling; configuration is specified in vercel.json under the "services" key.

Do services need a reverse proxy to communicate with each other?

No. According to Vercel documentation, services can be connected to a shared routing table and their interaction configured via bindings without a reverse proxy and without CORS configuration.