vercel-services

Define both as services in vercel.json with a root for each, then add top-level rewrites that route public paths like /api to the backend and everything else to the frontend. Both services build independently but ship as one deployment.

Declare a binding on the caller service naming the target service and an environment variable, then read that variable at runtime to get the internal URL. Bindings are deployment-aware, skip the public Firewall and CDN, and are unavailable during builds or in middleware.

Vercel preserves the original request path, so /api/users reaches the backend as /api/users. Either make the backend handle the prefix, such as FastAPI root_path, or strip it with a service-scoped rewrite inside that service's configuration.

Yes, a service without a matching top-level rewrite is unreachable from the public internet and only accessible through bindings. Note that bindings grant network reachability only, so add application-level authorization when the target must verify callers.

Use Services when tightly coupled components like a frontend and backend should deploy and roll back together atomically. Choose separate Vercel projects when teams own services independently and need to deploy or roll back each on its own cadence.

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 point the frontend at a relative path like /api.