pulumi-vercel

The Pulumiverse Vercel provider brings Vercel’s projects, domains, deployments, and edge infrastructure into Pulumi’s infrastructure-as-code model. It is a Terraform-bridge provider — built by wrapping the official vercel/terraform-provider-vercel with pulumi-terraform-bridge — so every resource and data source the Terraform provider exposes is regenerated into fully typed SDKs for Node.js/TypeScript, Python, Go, .NET, and Java.

For teams already provisioning cloud infrastructure with Pulumi, it means Vercel projects, DNS records, edge config stores, feature flags, and deployment protection rules can live in the same program (and state) as the rest of their stack, instead of being managed by hand through the Vercel dashboard or a separate Terraform workflow.

What You Get

• Typed resource classes for Vercel projects, domains, deployments, and deployment protection settings
• Edge Config resources (stores, items, schemas, tokens) and Blob storage resources managed as code
• Feature flag resources (definitions, segments, SDK keys) alongside the infrastructure that serves them
• Team-level resources — access groups, team members, OAuth apps, audit log drains, and trace drains
• Data sources (get* functions) for reading existing Vercel projects, domains, and configuration into a Pulumi program
• Consistent SDKs across Node.js, Python, Go, .NET, and Java generated from the same provider schema

Common Use Cases

• Provisioning a new Vercel project (framework, git integration, environment variables) alongside the rest of an application’s cloud stack
• Managing custom domains and DNS records for Vercel-hosted projects as part of a broader Pulumi-managed DNS setup
• Rolling out feature flags and Edge Config values through the same pipeline that deploys the infrastructure consuming them
• Enforcing deployment protection, trusted sources, and access-group membership consistently across many Vercel projects
• Migrating Vercel configuration currently managed by hand (or by Terraform) into a Pulumi program with typed, reviewable diffs

Under The Hood

Architecture The provider follows the standard Pulumi Terraform-bridge pattern: provider/resources.go wraps the upstream vercel/terraform-provider-vercel (a Terraform Plugin Framework provider) with pfbridge.ShimProvider, then a tfbridge.ProviderInfo struct maps Terraform resource/data-source schemas onto Pulumi tokens via tokens.SingleModule and MustApplyAutoAliases for backwards-compatible renames. The per-language SDKs (found under sdk/nodejs, sdk/python, sdk/go, sdk/dotnet, sdk/java) are entirely generated from this bridge metadata — the only hand-authored logic in the repo is the small mapping layer in resources.go plus a handful of field-level overrides (e.g. vercel_alias’s C# rename, custom ComputeID functions for vercel_edge_config_schema and vercel_team_config). This means the actual resource CRUD behavior — and any bugs in it — lives upstream in terraform-provider-vercel, not in this repo.

Tech Stack The provider binary is Go (module github.com/pulumiverse/pulumi-vercel/provider/v5, Go 1.26), built on github.com/pulumi/pulumi-terraform-bridge/v3 and github.com/pulumi/pulumi/sdk/v3, and pins github.com/vercel/terraform-provider-vercel/v5 as its upstream dependency. The generated Node.js SDK (@pulumiverse/vercel) depends only on @pulumi/pulumi and compiles with plain tsc. The repo’s dev environment is managed with devbox/mise, and an extensive set of GitHub Actions workflows (build_provider, build_sdk, upgrade-provider, upgrade-bridge, run-acceptance-tests, publish) automates rebuilding and republishing all five language SDKs whenever the upstream Terraform provider or the bridge itself is updated.

Code Quality There are no unit tests for the generated SDK code itself, which is expected since that code is templated output rather than hand-written logic; the actual resource behavior is exercised by terraform-provider-vercel’s own test suite upstream. This repo’s own tests live in examples/examples_test.go, examples_nodejs_test.go, and examples_py_test.go, which use Pulumi’s integration.ProgramTestOptions harness to run acceptance-style tests against real (or recorded) Vercel infrastructure. Go code is linted via golangci-lint (.golangci.yml) and a dedicated lint.yml / license.yml workflow enforces style and license-header consistency on every PR.

API Design Because every resource file is generated with full JSDoc (or equivalent per-language doc comments) copied straight from the Terraform provider’s schema descriptions, each class ships with runnable usage examples in its own doc comment — visible directly in editor tooltips, not just in external docs. Naming maps predictably from Terraform’s vercel_project to Pulumi’s vercel.Project, and data sources follow a consistent get* convention, so anyone familiar with either the Terraform provider or other Pulumi cloud providers has very little new API surface to learn. The tradeoff is that the SDK’s shape is dictated entirely by the upstream Terraform schema, so its ergonomics rise and fall with that provider’s own API design.