{"id":27070,"plugin_id":"plugin_connector_690a90ec05c881918afb6a55dc9bbaa1","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-06T18:03:11.833Z","digest":"3fbecba022b1d2ba1b0dbc2ee1662025070d76b3b6bd4d3f0083ca84a73c546f","against":24897,"payload":{"description":"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`.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":144},{"relative_path":"references/experimental-services.md","size_in_bytes":2907}],"name":"vercel-services","skill_md_contents":"---\nname: vercel-services\ndescription: 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`.\nsummary: Compose multiple frontends and backends in one Vercel project (Beta)\nmetadata:\n  priority: 7\n  docs:\n    - \"https://vercel.com/docs/services\"\n    - \"https://vercel.com/docs/services/routing\"\n    - \"https://vercel.com/docs/services/bindings\"\n    - \"https://vercel.com/docs/services/config-reference\"\n    - \"https://vercel.com/docs/services/experimental\"\n    - \"https://vercel.com/docs/services/pricing\"\n  sitemap: \"https://vercel.com/sitemap.xml\"\n  pathPatterns:\n    - 'vercel.json'\n    - 'apps/*/vercel.json'\n  bashPatterns:\n    - '\\b(?:vercel|vc)\\s+dev\\b[^\\n]*(?:--local|-L)(?:\\s|$)'\n  importPatterns: []\n  promptSignals:\n    phrases:\n      - \"vercel services\"\n      - \"vercel service binding\"\n      - \"vercel service bindings\"\n      - \"multi-service vercel\"\n      - \"multiple services on vercel\"\n      - \"frontend and backend on vercel\"\n    allOf:\n      - [backend, vercel]\n      - [polyglot, vercel]\n      - [multiple, services, vercel]\n      - [services, vercel.json]\n      - [vercel, service, binding]\n    anyOf:\n      - \"backend\"\n      - \"monorepo\"\n      - \"polyglot\"\n      - \"service\"\n      - \"binding\"\n      - \"vercel\"\n    noneOf: []\n    minScore: 6\nretrieval:\n  aliases:\n    - Vercel Services\n    - multi-service project\n    - polyglot project\n    - service binding\n    - service rewrite\n  intents:\n    - deploy frontend and backend together in one project\n    - configure the services key in vercel.json\n    - configure service rewrites\n    - call the backend privately with a service binding\n    - keep a service private with no public route\n    - serve a service on a subdomain\n    - strip a route prefix before it reaches the backend service\n    - run all services locally\n  entities:\n    - services\n    - bindings\n    - destination.service\n    - root\n    - experimentalServices\n  examples:\n    - put a Next.js frontend and a FastAPI backend in one project\n    - deploy a Vite SPA with an Express API behind /api\n    - add a Go service to an existing Next.js project\n    - my frontend cannot reach the backend service\n    - the backend returns 404 for every /api route\n    - point api.example.com at the backend\n---\n\n# Vercel Services\n\nUse 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.\n\nServices is [in Beta on all plans](https://vercel.com/docs/services). Say so when you recommend it.\n\nServices 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.\n\n## Choose the right structure\n\n| Need | Use |\n| --- | --- |\n| Multiple tightly coupled components, such as a frontend and a backend, that should ship as one app | Vercel Services |\n| One framework can own the whole app, such as Next.js with Route Handlers | One normal Vercel project without Services |\n| Teams own their services and deploy and roll back on their own cadence | Separate Vercel projects in a monorepo |\n| Independently deployed frontends must render as one site | Vercel Microfrontends |\n\nThe 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.\n\nDo 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.\n\n## Define services and public ingress\n\nIf `vercel.json` already has an `experimentalServices` key, the project is on the earlier configuration model: read [references/experimental-services.md](references/experimental-services.md) before changing it.\n\nEach 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.\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"frontend\": {\n      \"root\": \"apps/web\",\n      \"bindings\": [\n        {\n          \"type\": \"service\",\n          \"service\": \"backend\",\n          \"format\": \"url\",\n          \"env\": \"BACKEND_INTERNAL_URL\"\n        }\n      ]\n    },\n    \"backend\": {\n      \"root\": \"apps/backend\",\n      \"entrypoint\": \"main:app\"\n    }\n  },\n  \"rewrites\": [\n    { \"source\": \"/api/(.*)\", \"destination\": { \"service\": \"backend\" } },\n    { \"source\": \"/(.*)\", \"destination\": { \"service\": \"frontend\" } }\n  ]\n}\n```\n\nThe 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.\n\nKeep configuration ownership clear:\n\n- Keep public `rewrites`, `redirects`, `headers`, and other URL behavior at the top level.\n- Put `functions`, `installCommand`, `buildCommand`, `devCommand`, `ignoreCommand`, `outputDirectory`, and framework settings on the service that owns them.\n- Put service-local `headers`, `redirects`, `rewrites`, or `routes` inside a service only when they should run after public ingress selects that service.\n- 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.\n\n## Route requests correctly\n\nTop-level rewrites are evaluated in order. Put specific rules before the catch-all.\n\nRouting into a service is final. If the selected service returns a 404 or 405, Vercel does not try the next top-level rewrite.\n\nSplit the URL namespace by what the frontend needs:\n\n- Frontends without their own server routes, such as Vite or Create React App builds, let the backend own all of `/api`.\n- 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.\n\nThe 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:\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"backend\": {\n      \"root\": \"apps/backend\",\n      \"entrypoint\": \"main:app\",\n      \"rewrites\": [\n        { \"source\": \"/api/:path(.*)?\", \"destination\": \"/:path\" }\n      ]\n    }\n  }\n}\n```\n\nAn SPA service that serves a static `index.html`, such as a Vite build, needs a service-scoped catch-all so deep links resolve:\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"frontend\": {\n      \"root\": \"apps/web\",\n      \"rewrites\": [\n        { \"source\": \"/(.*)\", \"destination\": \"/index.html\" }\n      ]\n    }\n  }\n}\n```\n\nA service destination's `path` selects which route runs inside the service without changing the path the service code sees. A query string in it adds state the service's own rules can match, such as `\"path\": \"/:path*?org=:orgSlug\"` ([routing docs](https://vercel.com/docs/services/routing)). To change the path the code sees, use a service-scoped rewrite or a `request.path` transform in the service's own `routes`.\n\n## Serve a service on a subdomain\n\nHost-matched top-level rewrites can put a service on its own subdomain, such as `api.example.com`, while the catch-all serves the frontend:\n\n```json filename=\"vercel.json\"\n{\n  \"rewrites\": [\n    {\n      \"source\": \"/(.*)\",\n      \"has\": [{ \"type\": \"host\", \"value\": \"api.example.com\" }],\n      \"destination\": { \"service\": \"backend\" }\n    },\n    { \"source\": \"/api/(.*)\", \"destination\": { \"service\": \"backend\" } },\n    { \"source\": \"/(.*)\", \"destination\": { \"service\": \"frontend\" } }\n  ]\n}\n```\n\nSubdomains 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.\n\n## Call services privately with bindings\n\nDeclare 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.\n\n```ts\nconst url = new URL('/api/users', process.env.BACKEND_INTERNAL_URL);\nconst response = await fetch(url);\n```\n\nBindings 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.\n\nEach call over a binding is billed as one [Service Request](https://vercel.com/docs/services/pricing), with no Edge Request or Fast Data Transfer charge. The bytes a service returns are still billed as Fast Origin Transfer.\n\nPublic 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.\n\nA binding grants network reachability, not application authentication. Add service-level authorization when the target must verify the caller.\n\nNative 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.\n\n## Develop and deploy\n\nRun every service and inject local binding variables:\n\n```bash\nvercel dev\n```\n\nUse local-only mode when cloud authentication is unnecessary:\n\n```bash\nvercel dev -L\n```\n\nDeploy the project normally with `vercel` or Git integration. All services participate in the same preview and production deployment.\n\n## Troubleshoot\n\n- **No public traffic reaches a service:** add a top-level rewrite targeting it.\n- **The wrong service receives a request:** reorder rewrites so the most specific rule comes first and the catch-all is last.\n- **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.\n- **An SPA returns 404 on deep links:** add a service-scoped catch-all rewrite to `/index.html`.\n- **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.\n- **A binding variable is missing:** declare the binding on the caller and access it from runtime function code, not build code or middleware.\n- **Build settings are ignored or rejected:** move top-level build and runtime fields into the owning service.\n- **Framework detection is wrong:** set that service's `framework` or `entrypoint` explicitly instead of changing the whole project.\n- **Validation rejects `services` together with `experimentalServices`:** `vercel.json` can declare only one; finish the migration in [references/experimental-services.md](references/experimental-services.md).\n\n## Related skills\n\n- Deployment commands and CI: `⤳ skill: deployments-cicd`\n- Function runtime behavior and limits: `⤳ skill: vercel-functions`\n- Independent frontend deployments: `⤳ skill: microfrontends`\n"},"changes":[{"path":"/description","type":"changed","before":"Vercel Services — deploy multiple services within a single Vercel project. Use for monorepo layouts or when combining a backend (Python, Go) with a frontend (Next.js, Vite) in one deployment.","after":"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`."},{"path":"/included_files","type":"changed","before":[{"relative_path":"agents/openai.yaml","size_in_bytes":144},{"relative_path":"references/fastapi-vite/backend/pyproject.toml","size_in_bytes":165},{"relative_path":"references/fastapi-vite/frontend/package.json","size_in_bytes":320},{"relative_path":"references/fastapi-vite/frontend/vite.config.ts","size_in_bytes":133},{"relative_path":"references/fastapi-vite/vercel.json","size_in_bytes":208}],"after":[{"relative_path":"agents/openai.yaml","size_in_bytes":144},{"relative_path":"references/experimental-services.md","size_in_bytes":2907}]},{"path":"/skill_md_contents","type":"changed","before":"---\nname: vercel-services\ndescription: \"Vercel Services — deploy multiple services within a single Vercel project. Use for monorepo layouts or when combining a backend (Python, Go) with a frontend (Next.js, Vite) in one deployment.\"\nmetadata:\n  priority: 7\n  docs:\n    - \"https://vercel.com/docs/services\"\n  sitemap: \"https://vercel.com/sitemap/docs.xml\"\n  pathPatterns:\n    - 'backend/**'\n    - 'backend/main.py'\n    - 'backend/main.go'\n    - 'backend/go.mod'\n    - 'backend/pyproject.toml'\n    - 'backend/requirements.txt'\n    - 'frontend/**'\n    - 'apps/*/backend/**'\n    - 'apps/*/frontend/**'\n    - 'services/*/vercel.json'\n    - '*/pyproject.toml'\n    - '*/go.mod'\n  bashPatterns:\n    - '\\bvercel\\s+dev\\b.*-L'\n    - '\\bpip\\s+install\\b.*fastapi'\n    - '\\buv\\s+(sync|pip|run)\\b'\n    - '\\bgo\\s+(run|build|mod)\\b'\n    - '\\bpython\\s+-m\\s+uvicorn\\b'\n    - '\\buvicorn\\b'\n  importPatterns:\n    - \"fastapi\"\n  promptSignals:\n    phrases:\n      - \"services api\"\n      - \"vercel services\"\n      - \"multi-service\"\n      - \"python backend\"\n      - \"go backend\"\n      - \"fastapi\"\n      - \"deploy backend\"\n      - \"backend and frontend\"\n      - \"multiple services\"\n    allOf:\n      - [backend, frontend]\n      - [python, vercel]\n      - [go, vercel]\n      - [backend, deploy]\n      - [service, monorepo]\n      - [fastapi, deploy]\n    anyOf:\n      - \"backend\"\n      - \"monorepo\"\n      - \"service\"\n      - \"python\"\n      - \"golang\"\n    noneOf:\n      - \"turborepo cache\"\n      - \"turbo.json\"\n      - \"aws lambda\"\n      - \"docker compose\"\n    minScore: 6\n---\n\n# Deploy multi-service projects with Vercel\n\nServices let you deploy multiple independently-built units within a single Vercel project. The typical use case is combining different runtimes (e.g. Python + JavaScript) in one deployment with shared routing and environment variables, but services work for any combination — multiple services of the same runtime, different frameworks, or a mix.\n\nThis skill covers **project structure and configuration**. For the actual deployment, defer to the **deployments-cicd** skill.\n\n## How It Works\n\nA service is an independently built unit within your project, 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 (longest prefix wins).\n\n- Services are enabled via the `experimentalServices` field in `vercel.json` (see reference project).\n- `vercel dev -L` auto-detects frameworks and runs all services locally as one application, handling routing automatically. The `-L` flag (short for `--local`) runs without authenticating with Vercel Cloud.\n- Only `vercel.json` lives at the root. Each service manages its own dependencies independently.\n\n## Configuration\n\nDefine services in `vercel.json`:\n\n```json\n{\n  \"experimentalServices\": {\n    \"web\": {\n      \"entrypoint\": \"apps/web\",\n      \"routePrefix\": \"/\"\n    },\n    \"api\": {\n      \"entrypoint\": \"backend/main.py\",\n      \"routePrefix\": \"/server\"\n    }\n  }\n}\n```\n\nThe project's Framework Preset must be set to **Services** in the Vercel dashboard.\n\n### Configuration fields\n\n| Field          | Required | Description                                                |\n|----------------|----------|------------------------------------------------------------|\n| `entrypoint`   | Yes      | Path to the service entrypoint file or directory.          |\n| `routePrefix`  | Yes      | URL path prefix for routing (e.g. `/`, `/api`, `/svc/go`). |\n| `framework`    | No       | Framework slug. Pins detection; auto-detected if unset.    |\n| `memory`       | No       | Max available RAM in MB (128–10,240).                      |\n| `maxDuration`  | No       | Execution timeout in seconds (1–900).                      |\n| `includeFiles` | No       | Glob patterns for files to include in the deployment.      |\n| `excludeFiles` | No       | Glob patterns for files to exclude from the deployment.    |\n\nDo not add unknown fields — they will cause the build to fail.\n\n## Supported runtimes and frameworks\n\nServices is in beta. **Python** and **Go** are tested and production-ready. Other runtimes may work but are not yet validated.\n\n### Python\n\nWorks with FastAPI, Flask, Django, or any ASGI/WSGI application. Framework is auto-detected. Set `entrypoint` to the application file (e.g. `\"backend/main.py\"`). Dependencies go in `pyproject.toml` in the service directory.\n\n### Go\n\nSet `entrypoint` to the service **directory** (e.g. `\"backend\"`), not a file. **Must** set `\"framework\": \"go\"` explicitly in `vercel.json` — auto-detection does not work for Go services. Dependencies in `go.mod` in the service directory.\n\n### Other runtimes (untested)\n\nVercel supports Node.js, Bun, Rust, Ruby, Wasm, and Edge runtimes for functions. These can theoretically be used as services but are not yet validated.\n\n## Routing\n\nVercel evaluates route prefixes from longest to shortest (most specific first), with the primary service (`/`) as the catch-all. Vercel automatically mounts services at their `routePrefix`, so service handlers should **not** include the prefix in their routes.\n\nFor frontend frameworks mounted on a subpath (not `/`), configure the framework's own base path (e.g. `basePath` in `next.config.js`) to match `routePrefix`.\n\n## Environment variables\n\nVercel auto-generates URL variables so services can find each other:\n\n| Variable                        | Example value                            | Availability | Use case                              |\n|---------------------------------|------------------------------------------|--------------|---------------------------------------|\n| `{SERVICENAME}_URL`             | `https://your-deploy.vercel.app/svc/api` | Server-side  | Server-to-server requests             |\n| `NEXT_PUBLIC_{SERVICENAME}_URL` | `/svc/api`                               | Client-side  | Browser requests (relative, no CORS)  |\n\n`SERVICENAME` is the key name from `experimentalServices`, uppercased. If you define an env var with the same name in project settings, your value takes precedence.\n\n## Usage\n\n1. Read `references/fastapi-vite/` for the canonical project layout.\n2. Adapt the structure to the user's chosen runtimes — services can use any supported runtime, not just the ones in the reference.\n3. Define service routes **without** the route prefix — Vercel strips the prefix before forwarding.\n4. Validate that each service in `vercel.json` has `entrypoint` and `routePrefix`. Only set `framework` when auto-detection fails (required for Go).\n\n## Output\n\nAfter scaffolding, present the created file structure to the user. After deployment, present the deployment URL (refer to the **deployments-cicd** skill for details).\n\n## Troubleshooting\n\n### 404 on routes after deployment\n\nThe project needs the Services framework preset:\n\n1. Go to Project Settings → Build & Deployment → Framework Preset\n2. Select **Services** from the dropdown\n3. Redeploy\n\n### Routes return unexpected results\n\n1. Ensure all services are picked up by `vercel dev` — check logs. If a service is missing, verify `vercel.json`. Try setting `framework` explicitly.\n2. Validate route prefix behavior: handlers declare routes without `routePrefix` (e.g. `/health`), but requests from other services use the full prefix (e.g. `/api/health`).\n3. For frontend services on a subpath, confirm the framework's base path config matches `routePrefix`.\n","after":"---\nname: vercel-services\ndescription: 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`.\nsummary: Compose multiple frontends and backends in one Vercel project (Beta)\nmetadata:\n  priority: 7\n  docs:\n    - \"https://vercel.com/docs/services\"\n    - \"https://vercel.com/docs/services/routing\"\n    - \"https://vercel.com/docs/services/bindings\"\n    - \"https://vercel.com/docs/services/config-reference\"\n    - \"https://vercel.com/docs/services/experimental\"\n    - \"https://vercel.com/docs/services/pricing\"\n  sitemap: \"https://vercel.com/sitemap.xml\"\n  pathPatterns:\n    - 'vercel.json'\n    - 'apps/*/vercel.json'\n  bashPatterns:\n    - '\\b(?:vercel|vc)\\s+dev\\b[^\\n]*(?:--local|-L)(?:\\s|$)'\n  importPatterns: []\n  promptSignals:\n    phrases:\n      - \"vercel services\"\n      - \"vercel service binding\"\n      - \"vercel service bindings\"\n      - \"multi-service vercel\"\n      - \"multiple services on vercel\"\n      - \"frontend and backend on vercel\"\n    allOf:\n      - [backend, vercel]\n      - [polyglot, vercel]\n      - [multiple, services, vercel]\n      - [services, vercel.json]\n      - [vercel, service, binding]\n    anyOf:\n      - \"backend\"\n      - \"monorepo\"\n      - \"polyglot\"\n      - \"service\"\n      - \"binding\"\n      - \"vercel\"\n    noneOf: []\n    minScore: 6\nretrieval:\n  aliases:\n    - Vercel Services\n    - multi-service project\n    - polyglot project\n    - service binding\n    - service rewrite\n  intents:\n    - deploy frontend and backend together in one project\n    - configure the services key in vercel.json\n    - configure service rewrites\n    - call the backend privately with a service binding\n    - keep a service private with no public route\n    - serve a service on a subdomain\n    - strip a route prefix before it reaches the backend service\n    - run all services locally\n  entities:\n    - services\n    - bindings\n    - destination.service\n    - root\n    - experimentalServices\n  examples:\n    - put a Next.js frontend and a FastAPI backend in one project\n    - deploy a Vite SPA with an Express API behind /api\n    - add a Go service to an existing Next.js project\n    - my frontend cannot reach the backend service\n    - the backend returns 404 for every /api route\n    - point api.example.com at the backend\n---\n\n# Vercel Services\n\nUse 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.\n\nServices is [in Beta on all plans](https://vercel.com/docs/services). Say so when you recommend it.\n\nServices 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.\n\n## Choose the right structure\n\n| Need | Use |\n| --- | --- |\n| Multiple tightly coupled components, such as a frontend and a backend, that should ship as one app | Vercel Services |\n| One framework can own the whole app, such as Next.js with Route Handlers | One normal Vercel project without Services |\n| Teams own their services and deploy and roll back on their own cadence | Separate Vercel projects in a monorepo |\n| Independently deployed frontends must render as one site | Vercel Microfrontends |\n\nThe 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.\n\nDo 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.\n\n## Define services and public ingress\n\nIf `vercel.json` already has an `experimentalServices` key, the project is on the earlier configuration model: read [references/experimental-services.md](references/experimental-services.md) before changing it.\n\nEach 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.\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"frontend\": {\n      \"root\": \"apps/web\",\n      \"bindings\": [\n        {\n          \"type\": \"service\",\n          \"service\": \"backend\",\n          \"format\": \"url\",\n          \"env\": \"BACKEND_INTERNAL_URL\"\n        }\n      ]\n    },\n    \"backend\": {\n      \"root\": \"apps/backend\",\n      \"entrypoint\": \"main:app\"\n    }\n  },\n  \"rewrites\": [\n    { \"source\": \"/api/(.*)\", \"destination\": { \"service\": \"backend\" } },\n    { \"source\": \"/(.*)\", \"destination\": { \"service\": \"frontend\" } }\n  ]\n}\n```\n\nThe 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.\n\nKeep configuration ownership clear:\n\n- Keep public `rewrites`, `redirects`, `headers`, and other URL behavior at the top level.\n- Put `functions`, `installCommand`, `buildCommand`, `devCommand`, `ignoreCommand`, `outputDirectory`, and framework settings on the service that owns them.\n- Put service-local `headers`, `redirects`, `rewrites`, or `routes` inside a service only when they should run after public ingress selects that service.\n- 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.\n\n## Route requests correctly\n\nTop-level rewrites are evaluated in order. Put specific rules before the catch-all.\n\nRouting into a service is final. If the selected service returns a 404 or 405, Vercel does not try the next top-level rewrite.\n\nSplit the URL namespace by what the frontend needs:\n\n- Frontends without their own server routes, such as Vite or Create React App builds, let the backend own all of `/api`.\n- 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.\n\nThe 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:\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"backend\": {\n      \"root\": \"apps/backend\",\n      \"entrypoint\": \"main:app\",\n      \"rewrites\": [\n        { \"source\": \"/api/:path(.*)?\", \"destination\": \"/:path\" }\n      ]\n    }\n  }\n}\n```\n\nAn SPA service that serves a static `index.html`, such as a Vite build, needs a service-scoped catch-all so deep links resolve:\n\n```json filename=\"vercel.json\"\n{\n  \"services\": {\n    \"frontend\": {\n      \"root\": \"apps/web\",\n      \"rewrites\": [\n        { \"source\": \"/(.*)\", \"destination\": \"/index.html\" }\n      ]\n    }\n  }\n}\n```\n\nA service destination's `path` selects which route runs inside the service without changing the path the service code sees. A query string in it adds state the service's own rules can match, such as `\"path\": \"/:path*?org=:orgSlug\"` ([routing docs](https://vercel.com/docs/services/routing)). To change the path the code sees, use a service-scoped rewrite or a `request.path` transform in the service's own `routes`.\n\n## Serve a service on a subdomain\n\nHost-matched top-level rewrites can put a service on its own subdomain, such as `api.example.com`, while the catch-all serves the frontend:\n\n```json filename=\"vercel.json\"\n{\n  \"rewrites\": [\n    {\n      \"source\": \"/(.*)\",\n      \"has\": [{ \"type\": \"host\", \"value\": \"api.example.com\" }],\n      \"destination\": { \"service\": \"backend\" }\n    },\n    { \"source\": \"/api/(.*)\", \"destination\": { \"service\": \"backend\" } },\n    { \"source\": \"/(.*)\", \"destination\": { \"service\": \"frontend\" } }\n  ]\n}\n```\n\nSubdomains 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.\n\n## Call services privately with bindings\n\nDeclare 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.\n\n```ts\nconst url = new URL('/api/users', process.env.BACKEND_INTERNAL_URL);\nconst response = await fetch(url);\n```\n\nBindings 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.\n\nEach call over a binding is billed as one [Service Request](https://vercel.com/docs/services/pricing), with no Edge Request or Fast Data Transfer charge. The bytes a service returns are still billed as Fast Origin Transfer.\n\nPublic 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.\n\nA binding grants network reachability, not application authentication. Add service-level authorization when the target must verify the caller.\n\nNative 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.\n\n## Develop and deploy\n\nRun every service and inject local binding variables:\n\n```bash\nvercel dev\n```\n\nUse local-only mode when cloud authentication is unnecessary:\n\n```bash\nvercel dev -L\n```\n\nDeploy the project normally with `vercel` or Git integration. All services participate in the same preview and production deployment.\n\n## Troubleshoot\n\n- **No public traffic reaches a service:** add a top-level rewrite targeting it.\n- **The wrong service receives a request:** reorder rewrites so the most specific rule comes first and the catch-all is last.\n- **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.\n- **An SPA returns 404 on deep links:** add a service-scoped catch-all rewrite to `/index.html`.\n- **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.\n- **A binding variable is missing:** declare the binding on the caller and access it from runtime function code, not build code or middleware.\n- **Build settings are ignored or rejected:** move top-level build and runtime fields into the owning service.\n- **Framework detection is wrong:** set that service's `framework` or `entrypoint` explicitly instead of changing the whole project.\n- **Validation rejects `services` together with `experimentalServices`:** `vercel.json` can declare only one; finish the migration in [references/experimental-services.md](references/experimental-services.md).\n\n## Related skills\n\n- Deployment commands and CI: `⤳ skill: deployments-cicd`\n- Function runtime behavior and limits: `⤳ skill: vercel-functions`\n- Independent frontend deployments: `⤳ skill: microfrontends`\n"}],"summary":"Fields changed: 3. /description, /included_files, /skill_md_contents.","summary_kind":"deterministic","summary_metadata":{}}