Vercel Flags Cross Projects, but the Trust Boundary Gets Wider

Vercel projects can now evaluate one another's feature flags without copying SDK keys between them. That cleans up secret handling, but it does not create narrow access: a connected project receives access to the source project's entire flag configuration across every environment.

Quick Take

• Fact: Vercel announced Project Connections on 2 November 2026. The feature lets one project evaluate flags owned by another project on the same Vercel team.
• Why it matters: The practical win is simpler credential management. A platform team can let several first-party Vercel projects use one shared flag system without planting the same source-project secret in every consumer. Revocation also becomes cleaner. Removing the connection cuts access without editing environment variables or redeploying the consumer.
• Who cares: Project Connections are mainly for teams already running several Vercel projects that share release controls, including microfrontends, related web apps, and services inside one organizational boundary.
• Judgment: Fairly hyped as a cleaner way for trusted, same-team Vercel projects to share feature flags; overhyped if presented as fine-grained access control or a universal replacement for SDK keys. Fact: the consumer authenticates with its own OIDC identity, but the connection grants read and evaluate access to all source-project flags across all environments.

What happened

Vercel announced Project Connections on 2 November 2026. The feature lets one project evaluate flags owned by another project on the same Vercel team.

Previously, teams sharing flags across projects had to place a source project's server SDK key in each consumer project's environment variables and manage that credential manually. With a Project Connection, the consumer authenticates using its own deployment identity and OpenID Connect token.

The source project still owns the flags. In the consumer application, developers create an adapter that points to the source project ID:

“`ts const sharedFlagsAdapter = createVercelAdapter({ projectId: 'prj_source', }); “`

Connections can be created under Flags > Connections or managed through `vercel flags connections` with Vercel CLI 63.0.0 or later. The feature is available on all plans and requires `@flags-sdk/vercel` 1.6.0 or later. Teams using the core library directly need `@vercel/flags-core` 1.11.0 or later.

Local development follows a similar identity-based setup. From the consumer project, developers run `vercel link` and then `vercel env pull`. The resulting `.env.local` includes the consumer project's OIDC token. Vercel says to pull the environment again after that token expires.

Removing a connection revokes access without requiring a new deployment. Vercel also recommends defining a `defaultValue` for each flag so the consumer has predictable behavior when evaluation fails.

The security improvement has a catch

Project Connections remove the need to distribute one project's SDK key across several applications. That reduces the number of copied secrets a team must store, rotate, and revoke.

It does not reduce the amount of flag data available to the consumer.

Vercel's documentation says a connection grants read and evaluate access to every flag in the source project across all environments. Teams cannot restrict a connection to one flag, one group of flags, or one environment.

That matters because a flag configuration can contain more than a Boolean release switch. Targeting rules may include identifying data such as email addresses. A connected project should therefore be treated as part of the source project's trust boundary, not as a narrowly authorized caller.

There is an important environment detail too. The consumer deployment determines which source configuration is evaluated:

• Production maps to production.
• Preview maps to preview.
• Development maps to development.
• A custom environment maps to preview.

That last rule deserves attention from teams with a custom staging environment. A connection does not provide a separate staging-to-staging mapping. Test the actual behavior before using connected flags as a release gate.

Why it matters

The practical win is simpler credential management. A platform team can let several first-party Vercel projects use one shared flag system without planting the same source-project secret in every consumer.

Revocation also becomes cleaner. Removing the connection cuts access without editing environment variables or redeploying the consumer.

The tradeoff is authorization scope. An SDK key is a secret, but each key belongs to one environment. A Project Connection removes that shared secret while granting the connected project access to the source project's complete flag configuration across environments.

That can be reasonable for a storefront, checkout app, and account portal already operated by the same team under the same security boundary. It is a poor fit for a contractor sandbox, an experimental service, or any consumer that should see only one release switch.

Connections also stop at the Vercel team boundary. Transferring or deleting either project removes the connection. If a transfer will separate the projects into different teams, Vercel says to configure SDK keys in the consumers and redeploy before the move. Connections are not automatically converted into SDK keys.

Watch the usage meter

Connected reads count against the source project's usage. Reads from different source projects count separately, and reads of cached flag configuration still count.

Vercel's current pricing documentation lists Pro usage at $0.03 per 1,000 flag requests. Hobby includes up to 10,000 requests per billing cycle, while Enterprise pricing is custom.

The unit is not simply one evaluation of one flag. When an application reuses the same Flags client, evaluating several flags from one source during one application request counts as one flag request. Separate source projects count separately.

Teams sharing flags widely should monitor the source project rather than expecting costs to appear on each consumer.

Who should care

Project Connections are mainly for teams already running several Vercel projects that share release controls, including microfrontends, related web apps, and services inside one organizational boundary.

Platform and security owners should review each connection as an access grant. The right question is not only, "Does this project need one of our flags?" It is, "Do we trust this project with the complete flag configuration?"

Skip Project Connections when the consumer runs outside Vercel, belongs to another Vercel team, or requires per-flag or per-environment isolation. Vercel continues to direct applications needing manual authentication, including applications outside Vercel, toward SDK keys.

What to do this week

1. Upgrade the Vercel adapter or core package to the documented minimum version. 2. Confirm the consumer is trusted with the source project's complete flag configuration. 3. Create the connection before building if the application uses embedded definitions for fallback behavior. 4. Pass the source project ID to `createVercelAdapter`. 5.

Add a `defaultValue` to every connected flag. 6. Test production, preview, development, and any custom environment in use. 7. Verify OIDC authentication before removing the old `FLAGS` secret. 8. Monitor requests on the source project, where connected usage is counted.

Bottom line

Project Connections are a useful cleanup for trusted projects on the same Vercel team. They replace copied SDK keys with deployment identity and make revocation easier.

They are not fine-grained authorization. Use them when the consumer can be trusted with the whole flag pack, not merely one switch.

Bandwagon Check

Fairly hyped as a cleaner way for trusted, same-team Vercel projects to share feature flags; overhyped if presented as fine-grained access control or a universal replacement for SDK keys. Fact: the consumer authenticates with its own OIDC identity, but the connection grants read and evaluate access to all source-project flags across all environments. Company claim: Project Connections let applications evaluate another project's flags without managing shared SDK keys.

Sources

• Evaluate Vercel Flags from another project without sharing SDK keys.
• Evaluate Vercel Flags from another project without sharing SDK keys
• Connecting Projects to Share Flags
• SDK Keys
• Limits and Pricing for Vercel Flags

By Willa Ravenwire · AI Bandwagon