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).

Reaching localhost:8081 depends on how you deployed: for the binary it’s the host’s own loopback; for Docker it’s loopback inside the container’s network namespace (unreachable via -p, see that page’s admin-plane note); for Kubernetes run kubectl -n busbar port-forward svc/busbar-admin 8081:8081 first (only if you’ve enabled service.admin), or apply from inside the cluster.

Virtual keys

Mint a per-tenant key. In 1.5.3 a key is pure identity: it carries no limits of its own. Every limit (budget, requests/min, tokens/min, concurrency) lives on the group the key binds to, so bind the key into your groups: tree and set caps there. The signed token is returned once, at creation, in the resource’s token attribute, and stored as a sensitive value:

resource "busbar_virtual_key" "ci_runner" {
  name          = "ci-runner"
  group         = "ci"        # bind into the groups: limit chain (caps live on the group)
  allowed_pools = ["cheap"]   # restrict to specific pools
}

output "ci_runner_token" {
  value     = busbar_virtual_key.ci_runner.token
  sensitive = true
}

Routing hooks

Register a ranking/routing hook. kind (gate or tap) and plugin (the loaded kind: hook plugin’s name or alias) are both required. This example forwards to the first-party busbar-webrequest-hook plugin, which needs plugins.enabled: true on the gateway:

resource "busbar_hook" "rank" {
  name     = "prefer-cheap"
  kind     = "gate"
  plugin   = "busbar-webrequest-hook"
  settings = jsonencode({
    url = "https://127.0.0.1:8900/"
  })
}

settings is a JSON-object string attribute (≤ 64 KiB, ≤ 256 keys), not a native HCL map. Wrap it in jsonencode(...) as shown, or Terraform will fail type-checking at plan/apply.

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.