Terraform Provider

The Kupe Terraform provider exposes clusters, secrets, tenant membership, and API keys as kupe_* resources, so the platform layer lives in the same HCL as everything else you provision. It works with both Terraform and OpenTofu.

What the provider is for

The provider is a good fit when you want to:

provision clusters from HCL
create databases and bind them into cluster namespaces
manage secret sync targets declaratively
manage tenant membership as part of environment setup
create automation credentials for CI and platform workflows

Resource model

Resources

Resource	What it manages
`kupe_cluster`	Managed clusters
`kupe_secret`	Platform secrets and cluster sync targets
`kupe_database`	PostgreSQL databases
`kupe_database_binding`	A database role bound into cluster namespaces
`kupe_tenant_member`	Tenant membership and role assignment
`kupe_api_key`	Machine-to-machine credentials
`kupe_alertmanager_receiver`	Notification receivers
`kupe_alertmanager_routes`	Notification routing rules
`kupe_alertmanager_global`	Notification defaults

Data sources

Data source	What it reads
`kupe_tenant`	Tenant metadata and plan settings
`kupe_cluster`	Existing cluster details
`kupe_database`	Existing database details

Typical workflow

Configure the provider with host, tenant, and credentials.
Define the resources you want in HCL.
Run terraform plan.
Review the change.
Run terraform apply.

Reach for this workflow when the platform layer itself needs to live under source control and change review, alongside the rest of your infrastructure.

Quick start

terraform {
  required_providers {
    kupe = {
      source = "kupecloud/kupe"
    }
  }
}

provider "kupe" {
  host   = "https://api.kupe.cloud"
  tenant = "my-tenant"
}

resource "kupe_cluster" "prod" {
  name    = "prod"
  version = "1.31"

  resources = {
    cpu     = "4"
    memory  = "16Gi"
    storage = "100Gi"
  }
}

export KUPE_API_KEY="kupe_abc123_your-key-here"
terraform init
terraform plan
terraform apply

When to use Terraform vs API

Use Terraform when you want:

declarative state
plan/apply review
a consistent infrastructure-as-code workflow

Use the API when you want:

custom scripting
direct integration logic
request/response style automation