Vercel Project Connections let teams share feature flags across projects without SDK keys

What Vercel announced

Vercel has launched Project Connections, a feature for Vercel Flags that lets an application evaluate feature flags defined in another project in the same team without exchanging SDK keys. According to the Vercel blog, the feature is available on all plans.

The problem it addresses is familiar to teams running multiple services. Until now, if one project needed another project's flags, someone had to copy the source project's server SDK key into an environment variable on the consuming side and keep that secret in sync manually. That meant a broader credential than necessary, a secret to rotate, and a standing risk if the key leaked.

How connections work

Connections are configured from a Connections page inside each project's Flags section, or through the vercel flags connections command in the Vercel CLI. The page shows both directions of the relationship: which projects are permitted to read the current project's flags, and which projects the current project reads from. Individual connections can be added or removed from there.

Authentication is handled by deployment identity rather than a shared secret. Connected projects prove who they are using their own deployment's identity, and for local development, running vercel env pull retrieves the project's OIDC token so the same flow works outside a live deployment.

The access model is deliberately narrow. Connections are read-only and span all environments, and the consumer deployment decides which environment's flags apply — a production deployment evaluates production flags. Revoking a connection does not require redeploying either application.

What developers need to do

On the consuming side, the developer creates a flags adapter that points at the source project's ID. The Vercel blog demonstrates this with createVercelAdapter from the @flags-sdk/vercel package: the adapter is initialized with the source project identifier, and each flag — for example a boolean keyed new-checkout — is then defined against that adapter with a key and a default value. Flags declared this way evaluate against the connected source project.

There are version requirements to be aware of. According to the announcement, the feature needs @flags-sdk/vercel 1.6.0 or later, or @vercel/flags-core 1.11.0 or later for teams using the core library directly. Managing connections from the command line requires Vercel CLI 63.0.0 or newer.

Why it matters

Cross-service feature flags are common in real architectures — a checkout service, a marketing site and an internal dashboard often need to react to the same toggles. The old copy-the-key workflow forced a trade-off between duplicating flag definitions and spreading secrets around, and every copied SDK key was a credential that outlived the change that created it.

By binding authorization to deployment identity, Vercel removes the shared secret entirely: there is nothing to leak, rotate or audit across environment variables. The read-only scope limits what a connected consumer can do, and the ability to cut off access without a redeploy gives teams a fast response path when a connection should no longer exist.

For teams already running several Vercel projects with Flags, this turns a manual, error-prone chore into a declarative setting. And because it ships on every plan rather than an enterprise tier, small teams get the same cross-project capability as large ones.