Secure internal communication between services (beta)
By Steven Van ·
In beta, services declare bindings to call each other via injected internal URLs, with routing and TLS handled by Vercel.
Vercel now offers service bindings in beta, letting one service in a multi-service deployment call another over its internal network instead of the public internet.
A binding is declared on the caller service in vercel.json, naming the target service and an environment variable. Vercel injects that variable with a generated internal URL, so a Next.js frontend can reach a FastAPI backend with a normal fetch() call, while Vercel handles the routing, authentication, and TLS. The target service stays unreachable from outside unless it also has its own public rewrite.
- Internal calls skip the public request pipeline: Firewall, Deployment Protection, top-level middleware, and CDN request accounting don't apply.
- A binding grants reachability only. It does not authenticate or authorize the call, so that has to be handled in application code.
- Bindings resolve only in a service's functions at runtime, not during builds or in middleware.
- They aren't yet available for services on the Go or Rust runtime, unless built as a container image.
Full detail is in the service bindings documentation.