Vercel Marketplace integrations can now connect resources to custom environments

Vercel has widened the reach of its native Marketplace integrations: resource connections can now be pointed at custom environments rather than only the three defaults. According to a post on the Vercel blog, connections were previously confined to production, preview, and development, which left teams running extra environments — a staging tier, for instance — without a built-in way to attach a Marketplace resource to them.

How connections are scoped

The new option is exposed in three places, per the Vercel changelog: the dashboard, the Vercel CLI, and the REST API. When you connect a resource, you pick which custom environments it applies to, and the environment variables generated by that connection are confined to the environments you selected.

From the CLI this works through an --environment flag. The example Vercel gives attaches a Neon resource to a staging environment:

vercel integration add neon --environment staging

On the API side, the changelog points to an envVarEnvironments field, while dashboard users choose environments during the connection flow itself.

What stays the same

The change is not retroactive. According to Vercel, deployments that already exist are untouched when a resource is connected or its environment scope is altered — a fresh deployment is required before the new variables take effect. Anyone wiring this into automation should budget for an explicit redeploy step after connecting or rescoping a resource.

Plan requirements

Custom environments require a Pro or Enterprise plan, per the announcement, so the new scoping option remains out of reach for teams on other tiers regardless of which integrations they rely on.

Why it matters

Marketplace integrations are one of the main ways teams wire external services — databases such as Neon, for example — into Vercel projects, and environment variables are how those services surface inside an application. Before this change, a team with a staging environment had no clean way to give that stage its own connection or to keep staging credentials out of preview and production builds. Scoping the generated variables to the chosen environments keeps secrets aligned with the actual deployment topology instead of letting them bleed across stages of the pipeline.

The rollout also matters for how it lands. Rather than treating custom environments as a dashboard-only convenience, Vercel has carried the capability through the CLI flag and the REST API field, which means environment-scoped resources can be provisioned and managed as code. For teams that create and tear down environments programmatically, that consistency is the difference between a genuinely usable feature and a button in the UI.

The one operational wrinkle — the requirement for a new deployment — is minor, but pipelines that connect a resource and expect it to be available on the very next request will need to trigger a rebuild themselves.