vercel-services

Define both as services in vercel.json using the services key, with each service pointing to its own root directory. Add top-level rewrites to route public traffic, such as sending /api/(.*) to the backend and everything else to the frontend.

Declare a binding on the caller service naming the target service and the environment variable that receives the generated URL. Bindings are available at runtime to functions, skip the public Firewall and CDN, and do not create public routes.

Use Services when tightly coupled components like a frontend and backend should ship as one atomic deployment. Use separate Vercel projects when teams need to deploy and roll back each service independently on their own cadence.

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.

Yes. A service without a matching top-level rewrite is unreachable from the public internet and only accessible through bindings from other services. Note that bindings grant network reachability, not application-level authentication.

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