Hi Gabriel,

I think keeping @vercel/related-projects server-side is probably the safer default. The package reads VERCEL_RELATED_PROJECTS, and exposing that automatically to the browser would turn deployment/project mapping metadata into public client-side data.

For your use case, I'd put a very small server wrapper in front of it instead of trying to call the package directly from the browser. For example, in a Next.js Route Handler:

1
import { NextResponse } from "next/server"
2
import { withRelatedProject } from "@vercel/related-projects"
3

4
export async function GET() {
5
  const apiHost = withRelatedProject({
6
    projectName: "your-api-project",
7
    defaultHost: process.env.API_HOST,
8
  })
9

10
  return NextResponse.json({
11
    apiUrl: `https://${apiHost}`,
12
  })
13
}
14

Then the browser calls your own route:

1
const { apiUrl } = await fetch("/api/related-projects").then((res) => res.json())
2

That lets you expose only the specific URL the client needs, without exposing the full related-projects payload or other deployment metadata.

If you need the browser to call the other project's API directly, I'd also make sure that API has its own auth/CORS rules and does not rely on the host being "hidden." Anything returned to the browser should be treated as public.