Vercel Flags Cross-Project Sharing: No SDK Keys Required

Vercel recently introduced Project Connections for its Flags feature, allowing different projects within the same team to directly read feature flags defined in other projects without manually copying and passing SDK keys. This change addresses a long-standing pain point: previously, sharing flags across projects required writing the server SDK key into environment variables and maintaining it by hand—both tedious and carrying the risk of key proliferation.

From Key Sharing to Identity Authentication

In the traditional approach, if Project B wanted to use a flag defined in Project A, developers had to obtain the SDK key from Project A and configure it in Project B's environment variables. As teams grow and the number of projects increases, key management costs rise rapidly, and a leaked key could potentially affect other projects.

Project Connections changes the authentication method to be based on deployment identity. Connected projects authenticate using their deployment's identity, and during local development, the project's OIDC token is pulled via vercel env pull. According to Vercel's official documentation, this means manual key management is no longer needed, and access can be revoked without redeploying.

OIDC and Deployment Identity

OIDC (OpenID Connect) is an identity authentication protocol built on top of OAuth 2.0, whose core purpose is to let one party verify the authenticity of an identity token (ID Token) issued by another party. Vercel's Project Connections leverages exactly this mechanism: each deployment receives a platform-issued identity carrying workload attributes, and the consuming project presents this identity—rather than a static key—when requesting flags from the source project. Compared to traditional API keys, OIDC tokens typically have shorter validity periods and are automatically rotated by the platform, so even if leaked, the attack window is limited; meanwhile, the claims embedded in the token—such as project, team, and environment—allow the source project to precisely determine the origin of the request. Local development environments have no deployment identity, so the project-associated OIDC token must be synced to the local .env file via vercel env pull, reproducing the same authentication path locally as in production and preventing developers from bypassing the permission model with long-lived keys.

Configuration: Available via Console and CLI

Teams can view connection relationships on the Connections page in the project's Flags section: which projects have permission to read this project's flags, and which projects this project reads flags from. The page provides controls for adding and removing connections.

Connections can also be managed from the command line via vercel flags connections. Note the version requirements: using Project Connections requires @flags-sdk/vercel 1.6.0 or higher, or @vercel/flags-core 1.11.0 or higher if using the core library directly; managing connections via CLI requires Vercel CLI 63.0.0 or higher.

How to Call from the Consuming Project

Once a connection is established, the consuming project needs to create an adapter carrying the source project ID, then use it to evaluate flags. In the official example, you first pass the source project's projectId to createVercelAdapter, then specify that adapter in the flag definition. Flags defined this way are used in the consuming project just like local flags.

One design detail worth noting: a connection grants read-only access across all environments, and which environment's flag is evaluated depends on the consuming project's deployment environment—a production deployment evaluates the production environment's flag. This design reduces configuration items, but it also means consumers need to understand the correspondence between their own deployment environment and the source project's environments.

Separation of Adapter and Flag Evaluation

In the Flags SDK abstraction, a flag's "definition" (name, type, default value, evaluation logic) is decoupled from its "data source," and the adapter is the bridge connecting the two. createVercelAdapter encapsulates the details of communicating with the Vercel Flags service—including which source project ID to carry, how to attach deployment identity credentials, and which environment's configuration to request. Once the adapter is injected into the flag definition, business code calling the flag doesn't need to know whether it comes from a local or remote project. The benefit of this pattern is that the same flag definition can be swapped for an in-memory adapter in tests, a static adapter locally, and a cross-project adapter in production, without changing the caller's code. Understanding this makes it clear why the consuming side must still explicitly create an adapter after a connection is established: the connection is only authorization at the permission level, while the adapter is the component that actually issues evaluation requests at runtime—both are indispensable.

Permission Model and Limitations

The permission boundaries of Connections are fairly clear: read-only, covering all environments. Access can be revoked, and revocation takes effect without redeploying the consuming project—a practical feature for security incident response.

In terms of scope, Project Connections is available on all plans, not just Enterprise. This lowers the barrier for small and mid-sized teams to use cross-project flag sharing.

Read-Only Permissions and the Principle of Least Privilege

Read-only is the core constraint of the Project Connections permission model, reflecting the principle of least privilege in security design: the consuming side only needs the ability to "read the current value of a flag" and is strictly limited to that scope—it cannot modify the source project's flag definitions, turn flags on or off, adjust rules, or delete flags through any API. There are two considerations behind this. First, blast radius control—if a consuming project is compromised or has a bug, an attacker cannot use it to tamper with upstream flags and thereby affect the source project and all its other consumers. Second, clear responsibility boundaries—ownership of a flag always remains with the team that defined it, avoiding conflicting write operations on the same flag from multiple projects. When a flag needs to be changed, you must still return to the source project's console or call the write API using the source project's credentials, which naturally creates a single entry point for change auditing.

Significance for Multi-Project Architectures

For teams using monorepo splits or multi-service architectures, feature flags often need to be controlled uniformly across multiple applications. Previously, this meant either redefining flags in each project or maintaining a custom sharing mechanism. Project Connections brings this into the platform layer, and combined with deployment identity authentication, offers a compromise between convenience and security.

However, it has clear boundaries: connections are limited to within the same team, and cross-team flag sharing is not covered; the consuming side gets read-only access and cannot write back to the source project's flag definitions. For scenarios requiring bidirectional sync or cross-organization collaboration, additional solutions may still be needed.

One-line Summary

Vercel Flags introduces Project Connections, replacing SDK keys with deployment identity for read-only cross-project flag sharing.

Paragraph Summary

Vercel has added Project Connections to its Flags feature, letting projects within the same team directly read feature flags defined in other projects. Previously, cross-project sharing required manually copying server SDK keys into environment variables—as projects multiplied, key management costs skyrocketed and proliferation risk grew. The new approach uses deployment identity-based authentication: connected projects authenticate via deployment identity, and local development pulls OIDC tokens through vercel env pull. Configuration can be done on the Connections page in the console or managed via the vercel flags connections CLI, with version requirements. Consumers must create an adapter carrying the source project ID to evaluate flags; connections grant read-only access across all environments, and which environment's flags are evaluated depends on the consumer's deployment environment. Permissions can be revoked without redeployment and are available on all plans. The boundaries: limited to within the same team, no write-back, and no cross-organization collaboration.