Vercel launches Vercel Services: frontend and backend deployed together in one project

Vercel has introduced Vercel Services, a new feature that runs several frameworks at once — for example, a Next.js frontend and a FastAPI backend — within a single Vercel Project, with shared deployments and an internal network between services.

How to set up Vercel Services

Services are defined in vercel.json under the "services" key. Each service gets a path (root) and a framework or entrypoint, and public traffic routing is configured through rewrites. You can route public traffic to the frontend service only, leaving the backend reachable exclusively from inside the project.

• Services are configured through the "services" key in vercel.json
• Example from Vercel's documentation: a my_frontend service on Next.js and a my_backend service on FastAPI (entrypoint main:app)
• The backend in the example has no public route — only the my_frontend service can reach it, over the internal network
• The Deployments panel visualizes the service graph, and the Logs UI lets you filter logs by individual service
• The vercel dev command automatically starts all services locally, mirroring the production environment

What problem does combining services solve?

Until now, teams that paired a JavaScript frontend with, say, a Python backend in one product usually had to split them across different cloud platforms. Vercel's historical strength has been frontend deployment built around Next.js, while backend services on FastAPI, Django, or Flask tended to land on separate hosting platforms. In practice, that meant two independent CI/CD systems, two sets of logs and monitoring, and manually syncing frontend and backend versions on every release. Vercel Services closes this gap: the configuration for multiple full-fledged frameworks and services lives in a single vercel.json file instead of being stitched together by hand from different platforms' settings.

What atomic deployments and service bindings provide

Atomic deployments ensure that a project's frontend, backend, and other services deploy and roll back in sync, not one by one. Shared preview deployments show how a single change affects every service at once. A separate bindings configuration lets services call each other directly, bypassing the public internet: for example, a BACKEND_INTERNAL_URL key is automatically injected into the frontend's environment variables and points to the backend's internal address.

What this means

Vercel Services closes a long-standing gap between the frontend and backend halves of a single product, which often lived in different clouds with their own development and deployment processes. For teams combining a JavaScript frontend with, say, a Python backend on FastAPI, it means one deployment, a shared preview environment, and direct internal communication between services without a reverse proxy or CORS configuration. For the platform, it is also a way to keep teams inside its ecosystem that previously moved the backend part of their projects to third-party hosts simply because Vercel offered no convenient way to keep the whole stack in one place.

Frequently asked questions

What is Vercel Services?

It is a Vercel feature for running 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 lives in vercel.json under the "services" key.

Do services need a reverse proxy to talk to each other?

No. According to Vercel's documentation, services can be attached to a shared routing table and connected through bindings without a reverse proxy and without configuring CORS.