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

Most teams hit the same wall: shipping an API is fast, but turning that API into a Terraform provider in Go—and keeping it in sync with every change—is where things slow down. Speakeasy flips that workflow. If you already have an OpenAPI 3.0 spec, you can generate a Terraform provider, keep it updated, and wire it into CI/CD without becoming a Go expert or hand-writing every resource.

Quick Answer: Use the Speakeasy CLI with your OpenAPI 3.0 document, select terraform during speakeasy quickstart, and then run speakeasy run whenever your spec changes to regenerate and keep your Terraform provider in sync.

Frequently Asked Questions

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

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

Expanded Explanation:
Speakeasy is OpenAPI-native, so the only real prerequisite is a valid OpenAPI 3.0 (or 3.1) document that accurately describes your API. The CLI reads that spec and automatically creates a Terraform provider that maps your endpoints to Terraform resources and data sources. You don’t have to write Go or maintain a custom plugin—Speakeasy handles provider scaffolding, request/response modeling, and keeps behavior aligned with how Terraform actually plans and applies.

The generator is designed to become part of your normal release flow: once you’ve done the initial quickstart, you commit the generated provider into a repo, wire speakeasy run into CI, and let it regenerate each time the spec changes. That’s how you avoid drift between “what Terraform says” and “what the API really does.”

Key Takeaways:

• You generate the provider via the Speakeasy CLI from your OpenAPI 3.0 spec.
• After the first run, speakeasy run keeps the provider updated with every API change.

---

What is the step-by-step process to create a Terraform provider with Speakeasy?

Short Answer: Install the CLI, validate your spec, run speakeasy quickstart and choose terraform, then commit the generated provider and automate regeneration in CI with speakeasy run.

Expanded Explanation:
The process mirrors how you’d operationalize any codegen in a modern stack: start locally with an interactive setup, refine config, then automate. Speakeasy’s quickstart walks you through the minimal inputs—spec path, language target, and a few naming choices—then generates a Terraform provider wired directly to your API. From there, you treat the generated code like any other repo: version it, add tests or overlays if needed, and publish through your usual Terraform distribution path.

Because the generator is deterministic and spec-driven, you get a repeatable workflow. Whenever your OpenAPI 3.0 spec evolves (new endpoints, parameters, models), you rerun the generator and get a consistent, updated provider without chasing down every resource by hand.

Steps:

1. Install the Speakeasy CLI

   • Follow the install instructions from Speakeasy (e.g., brew install speakeasy-api/homebrew-tap/speakeasy on macOS, or the appropriate binary for your environment).

2. Run the interactive quickstart

   speakeasy quickstart
   

   • When prompted:
     • Provide the path to your OpenAPI 3.0 spec (JSON or YAML).
     • Select terraform as the language/target.
     • Confirm naming and output directory preferences.

3. Regenerate and keep in sync

   • After quickstart has created the config, regenerate any time with:

     speakeasy run
     

   • Add this command to your CI/CD pipeline so the Terraform provider is rebuilt on every spec change and surfaced as a pull request or build artifact.

---

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

Short Answer: Hand-written providers require Go expertise and manual updates; Speakeasy-generated providers are derived from your OpenAPI 3.0 spec, stay in sync automatically, and standardize behavior across services.

Expanded Explanation:
Traditional Terraform providers are Go codebases that you have to design, implement, test, and maintain. Every time your API changes—new fields, new resources, new auth—you repeat the cycle. That’s how you end up with inconsistent quality between teams, resources that don’t match actual behavior, and docs that drift.

Speakeasy swaps that model for spec-first generation. It reads your OpenAPI 3.0 spec and emits a Terraform provider that maps endpoints to resources using a consistent implementation approach. Updates are a regeneration problem, not a rewrite problem: change the spec, rerun the generator, and Speakeasy handles the plumbing. You still have room to customize behavior via config, but you’re not reinventing the provider every time.

Comparison Snapshot:

• Option A: Hand-written provider
  • Requires Go and Terraform SDK expertise.
  • Manual mapping of endpoints to resources and data sources.
  • High risk of drift as the API evolves; updates are slow and error-prone.
• Option B: Speakeasy-generated provider
  • Generated directly from your OpenAPI 3.0/3.1 spec.
  • Consistent naming, docs, and behavior across services.
  • Regenerated via CLI/CI whenever your spec changes—no Go required.
• Best for: Teams that want Terraform coverage for their APIs without spinning up a Go-heavy team, and who care about staying in lockstep with a fast-changing API surface.

---

How do I integrate Terraform provider generation into my CI/CD pipeline?

Short Answer: Check in your Speakeasy config, add a CI job that runs speakeasy run on spec changes, and publish or validate the generated Terraform provider as part of your release workflow.

Expanded Explanation:
Speakeasy is built to act like another member of your team in CI. Once speakeasy quickstart has produced config files for your Terraform provider, you commit those along with your OpenAPI 3.0 spec. In CI, you run the CLI in non-interactive mode (speakeasy run) whenever the spec or config changes. The output can be used to open automated pull requests, publish a new provider version, or run validation tests before merging.

This pattern—spec change → CI run → generated provider artifact—turns Terraform support into a predictable part of your release process. You no longer rely on a separate “Terraform sprint” to catch up with the API; the provider evolves with the spec.

What You Need:

• Speakeasy CLI and config in your repo

  • The config created during speakeasy quickstart (and your OpenAPI 3.0 spec) should live alongside your API code or infrastructure repo.

• A CI job that runs speakeasy run

  • Example (GitHub Actions-style pseudocode):

    jobs:
      terraform-provider-gen:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - uses: actions/setup-go@v5
          - name: Install Speakeasy
            run: |
              curl -fsSL https://raw.githubusercontent.com/speakeasy-api/speakeasy/main/install.sh | sh
          - name: Generate Terraform provider
            run: speakeasy run
          - name: Run provider tests
            run: go test ./... || true  # adjust for your testing strategy
    

---

Why should I use Speakeasy for Terraform instead of building and maintaining providers in-house?

Short Answer: Speakeasy turns your OpenAPI 3.0 spec into Terraform providers that stay in sync with your API, freeing your team from Go-heavy maintenance and giving you consistent, higher-quality integrations.

Expanded Explanation:
In-house providers start well and age badly. Early on, you can keep Go and Terraform SDK expertise concentrated in one team. But as your API surface grows and teams ship changes quickly, provider coverage lags behind. You end up with inconsistent resources, out-of-date docs, and frustrated users who can’t reliably manage your product via infrastructure-as-code.

Speakeasy moves the center of gravity back to your source of truth: the OpenAPI spec. Instead of pouring energy into hand-maintaining providers, your team invests in accurate, well-structured OpenAPI 3.0 documents. Speakeasy turns those specs into Terraform providers, and you automate regeneration as part of your pipeline. The outcome: faster releases, less drift, and a Terraform experience that matches what customers see in your API and SDKs.

Why It Matters:

• Reduced maintenance tax:

  • No need to staff a dedicated Go/Terraform team just to keep up with API changes. Regeneration with speakeasy run handles the churn.

• Consistent, scalable DX:

  • Terraform providers, SDKs, and CLIs can all be generated from the same OpenAPI 3.0 spec with Speakeasy. That means consistent naming, behavior, and docs across interfaces—and a path to infrastructure, code, and agents all backed by the same API contract.

---

Quick Recap

Generating a Terraform provider from an OpenAPI 3.0 spec with Speakeasy is a spec-first workflow: install the CLI, run speakeasy quickstart with terraform as the target, then use speakeasy run locally and in CI/CD to keep the provider aligned with your API. Compared to hand-written Go providers, this eliminates a significant maintenance burden, reduces drift, and gives your users a more reliable, up-to-date Terraform experience that tracks the evolution of your API.

Next Step

Get Started