Providers

A Pulumi provider is a type of Pulumi package that allows the Pulumi engine to manage resources — typically scoped to a given cloud platform, SaaS product, or other API.

What’s in a provider

A provider package is made up of a schema plus the code that implements it. In practice, that typically means:

• Custom resources. The primary contents of a provider are custom resources with CRUD operations (create, read, update, delete) for a specific cloud, SaaS, or API. This is what most providers exist to offer.
• Functions. A provider may also expose functions — data-source-style reads that return values without managing a resource lifecycle.

In addition, a provider may be bridged from an upstream Terraform or OpenTofu provider, which lets Pulumi reuse the upstream provider’s schema and CRUD code rather than reimplementing them. When a provider is not bridged, the schema and CRUD implementations can be generated from an API specification — for some or all resources — or written by hand.

Providers are usually distributed as an executable plugin with pre-generated SDKs for each Pulumi-supported language. This is convention, not a technical requirement: source-based plugins are also supported (in Go). Providers intended for public consumption can be published in the Pulumi Registry.

When to build a provider

Providers require a deeper level of Pulumi expertise and maintenance overhead compared to packaging components. Before building a new provider, check whether you can avoid the work:

• Is there already a Pulumi provider? Search the Pulumi Registry. If a well-maintained provider exists, use it.
• Is there a well-maintained Terraform or OpenTofu provider? If so, reach for Any Terraform Provider, which lets a Pulumi program consume any provider from the OpenTofu registry without writing a Pulumi provider at all.
• Do you actually need a provider? If your goal is to group resources into a reusable abstraction, a component is usually the right answer. For one-off programmatic resources, a dynamic provider may be simpler than a full provider package.

Build a standalone provider when none of the above apply.

Picking your approach

Two high-level factors shape how you’ll build the provider:

• Writing in Go? Use the Pulumi Go Provider SDK (pulumi-go-provider). It infers your schema from Go structs and tags, supplies default implementations for most provider protocol methods, and generates SDKs for every Pulumi-supported language. Go providers also compile to a standalone binary with no runtime dependencies for your users.
• Writing in another language? You’ll need to implement the provider protocol directly and hand-maintain the schema JSON, which is substantially more work. See Direct Provider Implementation for Python and TypeScript guides.

For guidance on choosing between the available options, see Provider Architecture.

Guides in this section

• Provider Architecture — the three-layer model of the provider stack and how to choose your layer.
• Build a Provider — step-by-step guide to using the Pulumi Go Provider SDK.
• Provider Configuration — declaring configuration keys, secrets, and environment variable defaults in your provider schema.
• Direct Provider Implementation — implementing providers in Python or TypeScript against the gRPC protocol directly.