Secure internal communication between services

Service Bindings make it easy for one Vercel service to securely call another within the same deployment.

When a service declares a binding for another service, Vercel automatically injects the configured environment variable. That means user code can fetch that URL normally, while Vercel handles the internal rewrite, routing, authentication, and TLS behind the scenes.

This enables multi-service applications on Vercel, like a Next.js frontend calling a FastAPI backend, while preserving service isolation and keeping routing configuration simple:

1
{
2
  "services": {
3
    "my_frontend": {
4
      "root": "frontend/",
5
      "framework": "nextjs",
6
      "bindings": [
7
        { 
8
          "type": "service", 
9
          "service": "my_backend", 
10
          "format": "url", 
11
          "env": "BACKEND_INTERNAL_URL" 
12
        }
13
      ]      
14
    },
15
    "my_backend": {
16
      "root": "backend/",
17
      "entrypoint": "main:app"
18
    }
19
  }
20
}

In the example above, my_frontend will be able to reach the my_backend service by making a fetch() request to BACKEND_INTERNAL_URL.

1
export async function GET() {
2
  const url = new URL("/users", process.env.BACKEND_INTERNAL_URL);
3
  const res = await fetch(url);
4
  const users = await res.json();
5
  return Response.json(users);
6
}

On the FastAPI side, my_backend exposes a normal route:

1
from fastapi import FastAPI
2

3
app = FastAPI()
4

5
@app.get("/users")
6
def get_users():
7
    return [ ... ]

Link to headingUnder the hood

That URL points inside Vercel, not at a public address. When your code fetches it, the request travels over Vercel's internal network to the same routing layer that handles every other request to your deployment, which sends it to the target service. It never hits the public route table, and Vercel sets up the TLS trust for you, so a plain HTTPS fetch works with no certificate config.

A service is only reachable if you expose it, either publicly with a rewrite route or privately with a binding.

Link to headingObservability

Service-to-service calls also appear in observability, so you can see which bound service was called and how long the request took:

Link to headingPricing

Service-to-service calls are billed as Service Requests and Fast Origin Transfer. They are not billed as CDN Requests or Fast Data Transfer. See services pricing and limits for current rates.

Link to headingLearn more

Read the bindings documentation to declare bindings and see the full reference.