Free — no signup required

Custom Providers: Extending IaC to Any API

2 min read

When the Tool Doesn't Support It

Terraform and Pulumi rely on Providers — plugins that know how to talk to a specific cloud or service API. AWS has a provider, Azure has a provider, Kubernetes has a provider. But what about your company's internal deployment platform? Or a niche SaaS tool that doesn't have an official provider yet?

This is where Custom Providers come in. A custom provider is a plugin you write yourself that teaches Terraform or Pulumi how to manage a new type of resource.

How a Terraform Custom Provider Works

A Terraform provider is a binary that Terraform downloads and executes as a subprocess. It communicates with Terraform over a gRPC protocol. Writing one involves:

  1. Define the Schema: Declare what properties your resource has. For example, a resource representing a record in your internal service registry might have a service_name (string, required), owner_team (string, required), and slo_target (float, optional).

  2. Implement CRUD Operations: Write Go functions for Create, Read, Update, and Delete that make HTTP API calls to your target system. Terraform calls these functions when it needs to reconcile state.

  3. Handle Drift: The Read function is called during terraform plan to check whether the real-world resource still matches the state file. If your internal API returns different values than what's in state, Terraform will show a diff.

  4. Compile and Distribute: Build the Go binary and distribute it via the Terraform Registry or an internal registry. Teams reference it in their required_providers block just like any official provider, and once that's in place, a resource block for the custom type (an internal service registry entry, say) works exactly like any built-in AWS or Azure resource.

Pulumi Component Resources

Pulumi has an analogous concept called Component Resources and Multi-Language Components (MLCs). A component resource is a logical grouping of resources (similar to a CDK construct) that can be shared across language SDKs. You write the component once in Go or TypeScript, and Pulumi generates SDKs for Python, TypeScript, Go, and .NET automatically.

This is particularly powerful for platform teams: write your StandardKubernetesDeployment component once, and every team — regardless of whether they use Python or TypeScript for their Pulumi code — can consume it.

Key Point: Custom providers and component resources are how mature platform engineering teams extend IaC tools to manage any API-driven system — internal platforms, legacy systems, SaaS tools — using the same workflow and state management as their cloud infrastructure. This is the foundation of "everything as code."

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free