# Vercel Services

> Configure and troubleshoot Vercel Services for multiple frontends and backends in one project. Use when composing a polyglot or multi-service application on one Vercel deployment; defining the `services` key, service-targeted rewrites, or service bindings in `vercel.json`; or running all services with `vercel dev`.

Fuente: https://skillsagentes.com/skills/vercel/vercel-plugin/vercel-services
Markdown: https://skillsagentes.com/skills/vercel/vercel-plugin/vercel-services.md

Repositorio: https://github.com/vercel/vercel-plugin
Autor: vercel
Licencia: NOASSERTION
Actualizado: hace 18 días
Coste de contexto: 79 tok instalada, 2.7k tok al activarse, 2.7k tok con todos los archivos del bundle
Bundle: 1 archivo, 11 KB
Permisos que pide: ninguno declarado

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent claude-code
# Cursor
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent cursor
# Codex
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent codex
# Gemini CLI
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent gemini
# Windsurf
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent windsurf
# Cline
npx -y skills add vercel/vercel-plugin --skill vercel-services --agent cline
```

## Archivos

- SKILL.md — 11 KB

## SKILL.md

Reproducido tal cual desde vercel/vercel-plugin bajo NOASSERTION. Esta sección es el documento original y está en inglés.

# Vercel Services

Use the `services` model whenever one application is made of multiple tightly coupled components, such as a frontend plus a backend, that should deploy to one Vercel project.

Services build independently but ship together as one deployment. That buys skew protection between frontend and backend, preview environments where every service is in sync, atomic deployments and rollbacks of the whole app, and private service-to-service communication through bindings. Public traffic enters through one ordered route table.

## Choose the right structure

| Need | Use |
| --- | --- |
| Multiple tightly coupled components, such as a frontend and a backend, that should ship as one app | Vercel Services |
| One framework can own the whole app, such as Next.js with Route Handlers | One normal Vercel project without Services |
| Teams own their services and deploy and roll back on their own cadence | Separate Vercel projects in a monorepo |
| Independently deployed frontends must render as one site | Vercel Microfrontends |

The benefits and the drawback are the same fact: every deployment ships all services together. Reach for separate projects only when you specifically need to deploy or roll back one service independently of the others.

Do not introduce Services just to split one framework into arbitrary processes. Use it when an independently built component has a real runtime, framework, dependency, or ownership reason to exist.

## Define services and public ingress

Each service requires a `root` relative to `vercel.json`. Let Vercel detect the framework unless pinning it is necessary. Set `entrypoint` relative to the service root when the runtime needs one.

```json filename="vercel.json"
{
  "services": {
    "frontend": {
      "root": "apps/web",
      "bindings": [
        {
          "type": "service",
          "service": "backend",
          "format": "url",
          "env": "BACKEND_INTERNAL_URL"
        }
      ]
    },
    "backend": {
      "root": "apps/backend",
      "entrypoint": "main:app"
    }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "backend" } },
    { "source": "/(.*)", "destination": { "service": "frontend" } }
  ]
}
```

The top-level rewrites expose the services. A service without a matching top-level rewrite is private: not reachable from the public internet, only through bindings.

Keep configuration ownership clear:

- Keep public `rewrites`, `redirects`, `headers`, and other URL behavior at the top level.
- Put `functions`, `installCommand`, `buildCommand`, `devCommand`, `ignoreCommand`, `outputDirectory`, and framework settings on the service that owns them.
- Put service-local `headers`, `redirects`, `rewrites`, or `routes` inside a service only when they should run after public ingress selects that service.
- Set `runtime: "container"` when a service must build from a Dockerfile or OCI image. Use `entrypoint` for a nonstandard Dockerfile and `command` to override the image command.

## Route requests correctly

Top-level rewrites are evaluated in order. Put specific rules before the catch-all.

Routing into a service is final. If the selected service returns a 404 or 405, Vercel does not try the next top-level rewrite.

Split the URL namespace by what the frontend needs:

- Frontends without their own server routes, such as Vite or Create React App builds, let the backend own all of `/api`.
- Frameworks with their own API routes, such as Next.js, share the namespace: send only a sub-namespace such as `/api/v1/(.*)` or specific prefixes such as `/api/users/(.*)` to the backend, and let the framework keep the rest.

The service receives the original request path. With the example above, `GET /api/users` reaches `backend` as `/api/users`, not `/users`. Either make the backend handle the prefix, such as FastAPI `root_path`, or strip it with a service-scoped rewrite:

```json filename="vercel.json"
{
  "services": {
    "backend": {
      "root": "apps/backend",
      "entrypoint": "main:app",
      "rewrites": [
        { "source": "/api/:path(.*)?", "destination": "/:path" }
      ]
    }
  }
}
```

An SPA service that serves a static `index.html`, such as a Vite build, needs a service-scoped catch-all so deep links resolve:

```json filename="vercel.json"
{
  "services": {
    "frontend": {
      "root": "apps/web",
      "rewrites": [
        { "source": "/(.*)", "destination": "/index.html" }
      ]
    }
  }
}
```

Do not set `path` on a service destination. The field is accepted by the schema but has no effect at request time. Reshape paths with a service-scoped rewrite or a `request.path` transform in the service's own `routes` instead.

## Serve a service on a subdomain

Host-matched top-level rewrites can put a service on its own subdomain, such as `api.example.com`, while the catch-all serves the frontend:

```json filename="vercel.json"
{
  "rewrites": [
    {
      "source": "/(.*)",
      "has": [{ "type": "host", "value": "api.example.com" }],
      "destination": { "service": "backend" }
    },
    { "source": "/api/(.*)", "destination": { "service": "backend" } },
    { "source": "/(.*)", "destination": { "service": "frontend" } }
  ]
}
```

Subdomains resolve only where that domain is attached: production, or a custom environment with a custom domain. Preview deployments get a single generated URL, so keep the subpath rewrite alongside the host rule and point the frontend at the relative path, for example `NEXT_PUBLIC_API_URL=/api`, so every preview calls its own deployment.

## Call services privately with bindings

Declare a binding on the caller service, name the target service, and choose the environment variable that receives the generated URL. Do not hardcode deployment hostnames or manually set binding variables.

```ts
const url = new URL('/api/users', process.env.BACKEND_INTERNAL_URL);
const response = await fetch(url);
```

Bindings are deployment-aware and do not create public routes. They are available to functions at runtime, not during builds or in Routing Middleware. Internal calls skip the public Firewall, Deployment Protection, top-level middleware, and CDN pipeline.

Public exposure is decided only by top-level rewrites. A service with no top-level rewrite is private: it is unreachable from the public internet and only accessible through its bindings. A service with both bindings and a top-level rewrite is also reachable publicly, so do not assume binding-only access implies the routes are protected.

A binding grants network reachability, not application authentication. Add service-level authorization when the target must verify the caller.

Native Go and Rust runtime services cannot currently consume bindings. Build those callers as container services when they need bindings. Node.js and Python services can use bindings directly.

## Develop and deploy

Run every service and inject local binding variables:

```bash
vercel dev
```

Use local-only mode when cloud authentication is unnecessary:

```bash
vercel dev -L
```

Deploy the project normally with `vercel` or Git integration. All services participate in the same preview and production deployment.

## Troubleshoot

- **No public traffic reaches a service:** add a top-level rewrite targeting it.
- **The wrong service receives a request:** reorder rewrites so the most specific rule comes first and the catch-all is last.
- **A backend returns 404:** confirm its routes include the public prefix because Vercel preserves the original request path, or strip the prefix with a service-scoped rewrite.
- **An SPA returns 404 on deep links:** add a service-scoped catch-all rewrite to `/index.html`.
- **A subdomain works in production but not in previews:** preview URLs have a single host, so host rules never match there. Keep a subpath rewrite to the same service and use the relative URL in the frontend.
- **A binding variable is missing:** declare the binding on the caller and access it from runtime function code, not build code or middleware.
- **Build settings are ignored or rejected:** move top-level build and runtime fields into the owning service.
- **Framework detection is wrong:** set that service's `framework` or `entrypoint` explicitly instead of changing the whole project.

## Related skills

- Deployment commands and CI: `⤳ skill: deployments-cicd`
- Function runtime behavior and limits: `⤳ skill: vercel-functions`
- Independent frontend deployments: `⤳ skill: microfrontends`

## Dónde encaja

- Categoría: [DevOps e infraestructura](https://skillsagentes.com/categorias/devops-infraestructura.md) — Despliegues, contenedores, IaC y flujos de gestión de incidentes.
- Creador: [vercel](https://skillsagentes.com/creators/vercel.md) — 79 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Knowledge Update](https://skillsagentes.com/skills/vercel/vercel-plugin/knowledge-update.md): Corrects outdated LLM knowledge about the Vercel platform and introduces new products. Injected at session start.
- [Vercel Connect](https://skillsagentes.com/skills/vercel/vercel-plugin/vercel-connect.md): Vercel Connect expert guidance — securely obtain scoped OAuth tokens for third-party services (Slack, GitHub, MCP servers, OAuth, Snowflake) on behalf of apps or users via Vercel OIDC. Use when wiring up third-party API access, connecting to MCP servers, sending Slack messages, accessing GitHub APIs, receiving webhook events from Slack/Linear/GitHub and forwarding them to your agents and apps, or building eve agent connections.
- [Vercel Functions](https://skillsagentes.com/skills/vercel/vercel-plugin/vercel-functions.md): Vercel Functions expert guidance — Serverless Functions, Edge Functions, Fluid Compute, streaming, Cron Jobs, and runtime configuration. Use when configuring, debugging, or optimizing server-side code running on Vercel.
- [Cdn Caching](https://skillsagentes.com/skills/vercel/vercel-plugin/cdn-caching.md): Debug Vercel CDN caching — cache hit rate, stale content, revalidation behavior, ISR + PPR, per-request cache reasons (cacheReason) and PPR state (ppr_state), and costs.
- [Eve](https://skillsagentes.com/skills/vercel/vercel-plugin/eve.md): eve framework guidance for durable AI agents and agent-powered applications. Use when creating, editing, or debugging an eve project, when the user explicitly asks for eve, or when the build-agents skill has selected eve as the default framework. Covers eve's filesystem-first runtime, durable sessions, tools, skills, connections, channels, sandboxes, subagents, schedules, evals, frontend clients, and Agent Runs observability. Do not use for incidental agent mentions, generic agent-building prompts, or established non-eve stacks unless the user asks for comparison or migration.

## Skills relacionadas

- [Cdn Caching](https://skillsagentes.com/skills/vercel/vercel-plugin/cdn-caching.md): Debug Vercel CDN caching — cache hit rate, stale content, revalidation behavior, ISR + PPR, per-request cache reasons (cacheReason) and PPR state (ppr_state), and costs.
- [Create A Backend](https://skillsagentes.com/skills/vercel/vercel-plugin/create-a-backend.md): Backend architecture guidance. Use when planning, building, or migrating an API or backend; choosing between Functions, Services, containers, Workflow, Queues, and Marketplace databases; or selecting a supported backend framework or runtime.
- [Deployments Cicd](https://skillsagentes.com/skills/vercel/vercel-plugin/deployments-cicd.md): Vercel deployment and CI/CD expert guidance. Use when deploying, promoting, rolling back, inspecting deployments, building with --prebuilt, or configuring CI workflow files for Vercel.
- [Microfrontends](https://skillsagentes.com/skills/vercel/vercel-plugin/microfrontends.md): Guide for building, configuring, and deploying microfrontends on Vercel. Use this skill when the user mentions microfrontends, multi-zones, splitting an app across teams, independent deployments, cross-app routing, incremental migration, composing multiple frontends under one domain, microfrontends.json, @vercel/microfrontends, the microfrontends local proxy, or path-based routing between Vercel projects. Also use when the user asks about shared layouts across projects, navigation between microfrontends, fallback environments, asset prefixes, or feature flag controlled routing.
- [Nextjs](https://skillsagentes.com/skills/vercel/vercel-plugin/nextjs.md): Next.js App Router expert guidance. Use when building, debugging, or architecting Next.js applications — routing, Server Components, Server Actions, Cache Components, layouts, middleware/proxy, data fetching, rendering strategies, and deployment on Vercel.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)