vercel-services

Define both as entries under the services key in vercel.json, each with its own root directory. Then add top-level rewrites that route public paths like /api/(.*) to the backend service and the catch-all to the frontend.

Declare a binding on the caller service naming the target service and an environment variable that receives a generated internal URL. Bindings are deployment-aware, skip the public firewall and CDN, and are available to functions at runtime, not during builds.

Use Services when tightly coupled components like a frontend and backend should ship as one atomic deployment. Choose separate projects in a monorepo when teams need to deploy and roll back each service independently.

Vercel preserves the original request path, so /api/users reaches the backend as /api/users. Either configure the backend to handle the prefix, such as FastAPI root_path, or strip it with a service-scoped rewrite.

Preview deployments get a single generated URL, so host-based rewrite rules never match there. Keep a subpath rewrite to the same service and use a relative URL like /api in the frontend so previews call their own deployment.

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.