# Services

Services are available in [Beta](/content/docs/release-phases#beta/index.html) on [all plans](/content/docs/plans/index.html).

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.

Looking for the earlier `experimentalServices` configuration? See [Experimental Services](/content/docs/services/experimental/index.html). The `services` model described here replaces it for new projects.

## [How services work](/content/docs/services#how-services-work/index.html)

A service is an independently built unit within your project.
At build time, Vercel builds each service separately. At request time, Vercel routes incoming requests to the correct service based on the rewrite rules in your `vercel.json`.

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

- A Next.js frontend at `/`
- A Python FastAPI backend, e.g. at `/backend`
- A Go server, e.g. at `/svc/go`

All services share the same deployment.

## [When to use services](/content/docs/services#when-to-use-services/index.html)

Services are valuable when you have:

- A polyglot monorepo: For example, 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.

## [Quick start](/content/docs/services#quick-start/index.html)

Define services in `vercel.json` using the `services` key. A service is internal by default and will not be routable from the Internet unless you expose it.
To route a service publicly, include a top-level rewrite rule that targets the service as `destination`:

### vercel.json

```json
{
  "services": {
    "my_frontend": {
      "root": "frontend/"
    },
    "my_backend": {
      "root": "backend/",
      "entrypoint": "main:app"
    }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "my_backend" } },
    { "source": "/(.*)", "destination": { "service": "my_frontend" } }
  ]
}
```

The two top-level rewrites are what expose these services. Without them, neither `my_frontend` nor `my_backend` would receive any public traffic. With the rewrites in place:

- Any request under `/api/`, such as `/api/users`, routes to `my_backend`.
- Every other path routes to `my_frontend`.

For the smallest possible setup, a single service with a catch-all rewrite:

### vercel.json

```json
{
  "services": { "api": { "root": "api/" } },
  "rewrites": [ { "source": "/(.*)", "destination": { "service": "api" } } ]
}
```

Because every public request enters through the top-level route table, your deployment has one public surface. Firewall, Deployment Protection, redirects are configured once at the top level and apply across all services, instead of being redefined per service.

Read [Service Routing](/content/docs/services/routing/index.html) to learn more about service public routing configuration.

## [Calling another service](/content/docs/services#calling-another-service/index.html)

A service can call another service directly over an internal [binding](/content/docs/services/bindings/index.html), without going through the public internet. The calling service declares the binding, and Vercel injects the target service's URL as an environment variable for your server-side code to use.

Bindings are how services communicate privately. The target stays unreachable from the internet unless a separate top-level rewrite exposes it, so a binding grants internal access without creating a public route. See [Service bindings](/content/docs/services/bindings/index.html) to declare and use them.

## [Using custom container images with services](/content/docs/services#using-custom-container-images-with-services/index.html)

Vercel builds each service according to the specified (or auto-detected) `runtime` and `framework` settings. If you prefer or require the service package to be built as a container (Docker) image instead, set the `runtime` setting for the service to `container`.

### vercel.json

```json
{
  "services": {
    "frontend": {
      "runtime": "container",
      "root": "frontend/"
    },
    "backend": {
      "runtime": "container",
      "root": "backend/"
    }
  }
}
```

See [Container Images](/content/docs/functions/container-images/index.html) for more information about using container images with Vercel.

## [Top-level configuration in services mode](/content/docs/services#top-level-configuration-in-services-mode/index.html)

When a project does not define `services`, Vercel evaluates `vercel.json` normally. When `services` is present, the top-level keys split into two groups:

- Public routing and URL behavior stay at the top level, where they own public traffic for the whole deployment. See [Routing](/content/docs/services/routing/index.html).
- Build and runtime fields are not valid at the top level, because their owner would be ambiguous across services. `functions`, `installCommand`, `buildCommand`, `devCommand`, `ignoreCommand`, `outputDirectory` and `framework` keys should be moved into the relevant service.

See [Service configuration reference](/content/docs/services/config-reference/index.html) for all configuration options that can be set in a service configuration object.

## [Local development](/content/docs/services#local-development/index.html)

Run all your services together locally with `vercel dev`:

### Terminal

```
vercel dev
```

to run everything locally without authenticating with the Vercel Cloud, add the `-L` flag (short for `--local`):

### Terminal

```
vercel dev -L
```

In both cases, generated binding environment variables are injected automatically, so calls between services work the same locally as in production.

## [Learn more](/content/docs/services#learn-more/index.html)

- [Routing](/content/docs/services/routing/index.html): How public requests reach services and how to control the path your code sees.
- [Service bindings](/content/docs/services/bindings/index.html): How one service calls another.
- [Pricing and Limits](/content/docs/services/pricing/index.html): How billing works for services and which limits apply.
- [Queues with services](/content/docs/queues/concepts#queues-with-services/index.html): How a service consumes queue messages.
- [Experimental Services](/content/docs/services/experimental/index.html): The earlier `experimentalServices` configuration model.
- [Services guides](/content/kb/vercel-services/index.html): Guides and examples for deploying with Vercel Services.