Manage with Terraform

Terraform doesn’t deploy the Busbar binary (use Binary, Docker, or Helm for that) — it manages a running gateway declaratively through the admin API. Put your virtual keys, hooks, and config in version control and terraform apply them like any other infrastructure.

The provider is published at registry.terraform.io/getbusbar/busbar and generated from the same openapi.json as the SDKs.

Configure the provider

terraform {
  required_providers {
    busbar = {
      source  = "getbusbar/busbar"
      version = "~> 0.1"
    }
  }
}

provider "busbar" {
  endpoint = "http://localhost:8081"   # the admin listener (or BUSBAR_ENDPOINT)
  token    = var.busbar_admin_token     # sent as x-admin-token   (or BUSBAR_ADMIN_TOKEN)

  # For a network-exposed admin plane behind mTLS:
  # ca_cert_pem     = file("admin-ca.crt")   # trust a private admin server cert
  # client_cert_pem = file("client.crt")
  # client_key_pem  = file("client.key")
  # insecure        = false                  # skip TLS verify (dev only)
}

endpoint and token fall back to the BUSBAR_ENDPOINT and BUSBAR_ADMIN_TOKEN environment variables, so provider "busbar" {} is valid when those are set. The admin plane is loopback by default — point Terraform at it over your management network, or expose it only behind mTLS (see the Admin API).

Virtual keys

Mint and govern a per-tenant key. The plaintext secret is returned once, at creation, and stored as a sensitive value:

resource "busbar_virtual_key" "ci_runner" {
  name          = "ci-runner"
  budget_cents  = 5000        # optional spend cap
  rpm           = 60          # optional requests/min
  allowed_pools = ["cheap"]   # restrict to specific pools
}

output "ci_runner_secret" {
  value     = busbar_virtual_key.ci_runner.secret
  sensitive = true
}

Routing hooks

Register a ranking/routing hook:

resource "busbar_hook" "rank" {
  name = "prefer-cheap"
  # ...hook configuration...
}

Effective config (GitOps singleton)

busbar_config applies the whole running config document and tracks the monotonic config_version — the GitOps primitive for a gateway you drive entirely from Terraform:

resource "busbar_config" "this" {
  document = file("${path.module}/busbar.config.json")
}

The busbar_info data source

Read the live gateway’s version and topology (all typed):

data "busbar_info" "this" {}

output "gateway_version" { value = data.busbar_info.this.version }
output "model_count"     { value = data.busbar_info.this.models }

Import existing objects

Every resource supports terraform import, so you can bring an already-running gateway under management without recreating anything:

terraform import busbar_virtual_key.ci_runner vk_1a2b3c...
terraform import busbar_hook.rank prefer-cheap
terraform import busbar_config.this config

Full per-resource docs are on the Terraform Registry. The provider source and acceptance tests live at github.com/GetBusbar/terraform-provider-busbar.

Also: Pulumi and Crossplane

The same three resources are available on two more control planes, bridged from the Terraform provider so they track it automatically:

• Pulumi — a bridged provider (github.com/GetBusbar/pulumi-busbar) with generated Python, TypeScript, and Go SDKs. Manage virtual keys, hooks, and config in real code alongside the rest of your Pulumi stack.
• Crossplane — an Upjet-generated provider (github.com/GetBusbar/provider-busbar) exposing VirtualKey, Hook, and Config as Kubernetes custom resources, for GitOps management from within a cluster.

Both generate from the Terraform provider’s schema, so adding a resource upstream carries into all three with no hand-written code.