How do I generate a Terraform provider with Speakeasy from an OpenAPI 3.0 spec?

Most teams don’t struggle to write an OpenAPI 3.0 spec. They struggle to keep everything around it—SDKs, CLIs, and especially Terraform providers—caught up as the API changes. Writing a Terraform provider in Go by hand is one thing; updating it on every breaking change is what burns cycles.

Quick Answer: Use the Speakeasy CLI with your OpenAPI 3.0 spec: run speakeasy quickstart, choose terraform as the target, then regenerate on demand with speakeasy run and wire it into CI so your Terraform provider stays in sync with your API.

Frequently Asked Questions

How do I generate a Terraform provider from an OpenAPI 3.0 spec using Speakeasy?

Short Answer: Install the Speakeasy CLI, run speakeasy quickstart against your OpenAPI 3.0 spec, select terraform as the target, then use speakeasy run to regenerate the provider whenever your spec changes.

Expanded Explanation:
Speakeasy treats your OpenAPI 3.0 spec as the source of truth and automatically maps your endpoints into Terraform resources and data sources. You don’t need to write Go or wire up the Terraform SDK by hand—Speakeasy handles provider scaffolding, codegen, and updates.

The basic workflow is: point Speakeasy at your OpenAPI 3.0 document, follow an interactive quickstart to generate an initial Terraform provider, commit it to version control, and then integrate speakeasy run into your CI so the provider is rebuilt whenever the spec changes. That gives you a Terraform provider that evolves at the same pace as your API.

Key Takeaways:

• Speakeasy reads your OpenAPI 3.0 spec and generates a Terraform provider automatically.
• You manage updates via speakeasy run and CI/CD instead of hand-maintaining Go-based providers.

---

What’s the step‑by‑step process to generate and update a Terraform provider with Speakeasy?

Short Answer: Install Speakeasy, run speakeasy quickstart with your OpenAPI 3.0 spec and select terraform, then use speakeasy run locally and in CI to keep the provider updated.

Expanded Explanation:
You work through a short guided setup once, then treat provider generation as part of your release workflow. The CLI prompts you for your spec path and basic project details, generates the provider code, and sets up config so future runs are non-interactive. After the first pass, you regenerate the provider with a single command whenever your OpenAPI 3.0 spec changes, or let CI run it on every commit.

Because this is plugged into your existing Git-based workflow, updates show up as pull requests instead of one-off, manual edits spread across Go, docs, and Terraform schemas.

Steps:

1. Meet prerequisites
   • Install the Speakeasy CLI.
   • Ensure your API spec is in a supported format (OpenAPI 3.0 is fully supported).
2. Run the quickstart
   • From your repo root, run:

     speakeasy quickstart
     

   • When prompted, provide:
     • Path to your OpenAPI 3.0 spec (e.g. openapi.yaml).
     • Output repo / directory for the Terraform provider.
     • terraform as the target language.
3. Regenerate with every API change
   • After quickstart, regenerate anytime with:

     speakeasy run
     

   • Add speakeasy run to your CI so updated providers are generated and surfaced as PRs whenever the spec changes.

---

How is a Speakeasy‑generated Terraform provider different from a hand‑written provider?

Short Answer: A hand‑written Terraform provider is bespoke Go code you maintain manually; a Speakeasy‑generated provider is derived from your OpenAPI 3.0 spec and kept in sync automatically via codegen and CI.

Expanded Explanation:
Traditional Terraform providers are implemented directly against the Terraform Plugin SDK, usually in Go. They’re powerful, but they require Go expertise, careful schema wiring, and constant maintenance to keep up with a fast‑moving API. Drift is the default: the API ships new fields while Terraform still reflects last quarter’s shape.

Speakeasy starts from your OpenAPI 3.0 spec and generates the provider for you. Resource schemas, request/response models, and documentation are inferred from the spec instead of hand-coded. When the spec changes, you rerun speakeasy run and get an updated provider, which can be reviewed and merged like any other change. You still keep full control in Git, but the heavy lifting of mapping endpoints to Terraform resources is automated.

Comparison Snapshot:

• Option A: Hand‑written provider
  • Custom Go code, manual mapping to Terraform schemas.
  • High effort to add endpoints or fields; easy to fall behind the API.
• Option B: Speakeasy‑generated provider
  • Generated from your OpenAPI 3.0 spec.
  • No Go expertise required; updates come from regenerating when the spec changes.
• Best for: Teams that want Terraform coverage for their API without building and maintaining a Terraform provider practice in-house.

---

What do I need in place to implement Terraform provider generation with Speakeasy?

Short Answer: You need the Speakeasy CLI, a valid OpenAPI 3.0 spec for your API, and a Git repo to host the generated Terraform provider and wire it into CI.

Expanded Explanation:
Speakeasy is OpenAPI‑native: your spec is the contract it reads. If you already maintain an OpenAPI 3.0 doc for your API, you’re most of the way there. From there, the only hard requirement is the Speakeasy CLI and a repo to store the generated Terraform provider source so you can version, review, and publish it like any other codebase.

Once these basics are in place, you can layer on CI/CD: run speakeasy run in your pipelines to regenerate the provider and optionally publish a new Terraform registry version as part of your release process.

What You Need:

• Speakeasy CLI installed
  So you can run speakeasy quickstart and speakeasy run locally and in CI.
• A supported API spec (OpenAPI 3.0) and a Git repo
  Your OpenAPI 3.0 document as the source of truth, and a repository to host and ship the generated Terraform provider.

---

How does generating Terraform providers from OpenAPI 3.0 with Speakeasy help strategically?

Short Answer: It turns Terraform support into an API‑driven artifact instead of a one‑off Go project, so your infra-as-code experience stays in lockstep with your API without slowing down releases.

Expanded Explanation:
Terraform is often how your largest customers and internal teams integrate your platform into real cloud environments. When the provider lags behind the API, you get support tickets, custom scripts, and fragmented patterns across products. When it’s kept in lockstep with the API, Terraform becomes a reliable interface: teams can provision your resources using the same contract your SDKs and CLIs use.

By generating Terraform providers from OpenAPI 3.0, Speakeasy pushes Terraform into the same “ship with every commit” loop as the rest of your integration surface. Product teams move fast, infra teams get a stable IaC interface, and you don’t pay a maintenance tax in bespoke Go code across multiple services. For teams already using Speakeasy for SDKs, CLIs, or MCP, Terraform providers become just another output from the same spec‑driven workflow.

Why It Matters:

• No drift between API and Terraform
  The provider is generated from the same OpenAPI 3.0 spec you use for other artifacts, so changes propagate consistently.
• Faster, safer infra integrations
  Customers and internal platform teams can adopt new endpoints and resources via Terraform without waiting on hand-maintained provider updates.

---

Quick Recap

Using Speakeasy with an OpenAPI 3.0 spec, you can automatically generate Terraform providers that map your API endpoints to Terraform resources, without writing Go or hand‑wiring the Terraform SDK. You run speakeasy quickstart once to set things up, regenerate with speakeasy run whenever the spec changes, and plug this into CI/CD so your Terraform provider ships at the same pace as your API. The result is less drift, less maintenance, and a more consistent integration experience for teams working through Terraform.

Next Step

Get Started