Experimental Services

Services let you deploy multiple backends and frontends within a single Vercel project. For example, a Next.js frontend and a FastAPI backend in the same repository deploy together with shared routing, environment variables, and a unique domain, replacing the need to split monorepos into separate Vercel projects.

A service is an independently built unit within your project that is deployed to the same domain under a unique subpath. At build time, Vercel builds each service separately. At request time, Vercel routes incoming requests to the correct service based on the URL path prefix.

A project can contain multiple services across different frameworks or runtimes, such as:

• A Next.js frontend at /
• A Python FastAPI backend, for example at /backend
• A Go server, for example at /svc/go

All services share the same deployment URL.

Services are valuable when you have:

• A polyglot monorepo: A JavaScript frontend and a Python backend in the same repository that you want to deploy as one project.
• Multiple backends: Several API services, each with its own dependencies and build step.

If your project uses a single framework (for example, a Next.js app with API routes), you don't need services. If your monorepo contains separate applications that you would prefer to mount under separate domains, consider deploying them as separate projects in a monorepo instead.

Define services in vercel.json using the experimentalServices key:

{
  "experimentalServices": {
    "web": {
      "entrypoint": "apps/web",
      "routePrefix": "/"
    },
    "api": {
      "entrypoint": "backend/main.py",
      "routePrefix": "/server"
    }
  }
}

To deploy a project that uses multiple services, your project framework setting must be set to Services and experimentalServices must be present in vercel.json.

When a project has multiple experimental services, Vercel merges their routes into a single routing table and distributes incoming requests based on each service's route prefix.

Each web service has a routePrefix that determines which requests it receives. Vercel evaluates prefixes from longest to shortest (most specific first), with the primary service (prefix /) as the catch-all.

For example, with a Next.js frontend at / and a FastAPI backend at /svc/api:

When you configure routePrefix, Vercel automatically mounts backend services at that base path, so you do not need to configure a framework-specific root path for backends.

For frontend frameworks such as Next.js mounted on a subpath, you still need to configure the app's base path (for example, basePath in next.config.js) to match routePrefix.

Vercel automatically generates environment variables so services can communicate with each other.

For each web service, Vercel injects:

For example, for a project with two services, a Next.js "frontend" mounted at the root and a FastAPI "backend" mounted at "svc/api", Vercel would generate the following environment variables:

Client-side variables use relative paths (the route prefix only) to avoid CORS issues. The browser resolves them against the current origin, so they work across preview deployments and custom domains.

If you define an environment variable with the same name in your project settings, your value takes precedence.

Run all services together locally, without authenticating with the Vercel Cloud, by adding the -L flag (short for --local):

vercel dev -L