What happened
Vercel has introduced Project Connections for Vercel Flags. The feature lets an application evaluate flags defined in a different Vercel project within the same team. Its stated purpose is to avoid managing SDK keys when flags must be shared across projects.
Previously, a team wanting one project to read another project's flags had to copy a server SDK key into an environment variable and maintain that key manually. Under Project Connections, the consuming project is connected to the source project and its deployment authenticates using that deployment's own identity. This changes the sharing mechanism from distributing a source project's server credential to creating a managed relationship between projects.
Connections are managed from the Connections page within a project's Flags section. Vercel says that page shows both the projects that can read a project's flags and the projects from which a project reads flags. Teams can add or remove connections there. They can also manage them with the vercel flags connections command in the Vercel CLI.
A connection grants read-only access across all environments. The consumer deployment selects the flag environment: a production deployment evaluates production flags, according to Vercel. In the consuming application, a developer creates an adapter with the source project's ID, then associates that adapter with a flag definition. Vercel's example imports createVercelAdapter from @flags-sdk/vercel, supplies a project ID such as prj_source, and uses the resulting adapter for a boolean flag named new-checkout.
For local development, vercel env pull retrieves the project's OIDC token. Vercel also says access can be revoked without redeploying the consuming application, so a team can remove a connection at the control plane rather than changing application configuration and shipping a new deployment.
Project Connections are available on all Vercel plans. They require @flags-sdk/vercel 1.6.0 or later, or @vercel/flags-core 1.11.0 or later for direct use of the core library. Managing connections in the CLI requires Vercel CLI 63.0.0 or later. The changelog does not list a separate price for the feature.
What the archive adds
This is a new fact in Vercel's broader movement toward explicit, scoped connections rather than proliferating credentials. An earlier Telegram post described Vercel Connect as a way to provide applications and agents with scoped connectors; this release applies a comparable access-control approach to cross-project flag reads. The available Field Note on Vercel's Eve framework concerns a Firecrawl connection, not Vercel Flags, so it is not direct prior coverage: Vercel’s open-source Eve agent framework now provides a Firecrawl connection.
Trend signal
This supports agent-ready software exposes capabilities. A project exposes a bounded capability—reading its flags—to a named connected project, while the connection can be inspected, removed, and limited to read-only access. The source describes application-to-application access rather than agent execution, so it is a modest supporting example, not proof that Vercel Flags itself is becoming an agent product.
Why it matters
Feature flags are often shared when several services, front ends, or deployments need to make consistent rollout decisions. Before this change, teams could solve that by placing a server SDK key from one project into another project's environment. That works, but it turns access into credential distribution and makes the relationship less visible than a managed connection.
Project Connections offer a narrower operational model: identify the source project, give a consumer read-only access, and revoke that relationship when it is no longer needed. Using deployment identity also removes one manually handled server key from the integration path. The distinction matters most for teams with multiple Vercel projects, where changes in ownership, deployment environments, or service boundaries otherwise create recurring secret-management work.
The environment rule deserves testing in a real release process. Vercel says the consumer deployment determines which flag environment is evaluated, so production-to-production behavior is clear, but teams should confirm that preview and other environments map to their intended rollout policy. This is a capability for cross-project reads, not a reason to make every internal flag broadly available.
Limits and uncertainty
The changelog does not explain the lifetime, validation, or detailed security properties of the OIDC token used for local development. It provides no threat model and does not compare Project Connections with Vercel's other authorization mechanisms. Although connections are read-only across all environments, the source does not describe permissions scoped to individual flags or individual environments.
Vercel also does not provide adoption data, performance characteristics, migration guidance for existing copied keys, or a separate pricing figure. The release establishes that a managed access path is available on all plans; it does not establish how it behaves under every organization structure or whether it is preferable to every existing configuration design.
Skill to build now
Inventory any Vercel applications that receive another project's server SDK key through environment variables. For each one, document the source project, the consuming project, the environments involved, and who should be able to revoke access. Then test a Project Connection in a non-production deployment with the required SDK version, confirming that the consumer evaluates the expected flag environment before replacing the manually copied key.
Reader takeaway
For Vercel teams sharing feature flags between projects, Project Connections replace copied server SDK keys with an explicit, read-only relationship authenticated by deployment identity. Check library and CLI versions, validate environment behavior in your rollout flow, and use the connection only for projects that genuinely need to read the shared flags.