Terraform
Manage your workspace as code: reviewable, versioned, repeatable — and a natural surface for AI agents to write. The provider drives the same public API as the dashboard and the raw HTTP reference.
Write-only arguments (password_wo, value_wo) need Terraform 1.11+ or OpenTofu 1.11+. Official SDKs — Go first, generated from the same OpenAPI spec — follow next.
Install the provider
The provider is published on the Terraform Registry — declare it and terraform init does the rest (download, signature verification, lockfile). OpenTofu works too: use the fully-qualified source registry.terraform.io/qalby-tech/livellm.
terraform {
required_providers {
livellm = { source = "qalby-tech/livellm" }
}
}
$ terraform init
# => Installed qalby-tech/livellm (signed)Configure it with your workspace key
Mint a key on your workspace's API keys page. Each key manages the workspace it was minted in. Prefer the LIVELLM_API_KEY environment variable over hardcoding.
provider "livellm" {
# reads LIVELLM_API_KEY when api_key is unset
# endpoint defaults to https://api.live-llm.com
}First plan: read your workspace
The livellm_workspace data source reads your workspace's facts — its name (handy for building hostnames in outputs) and plan — and fails fast at plan time with a clear message if the key is wrong. Optional: resources never need it.
# main.tf (continued)
data "livellm_workspace" "this" {}
output "workspace" {
value = data.livellm_workspace.this.name
}
$ export LIVELLM_API_KEY="llc_..."
$ terraform plan
# => workspace = "acme"Declare your workspace
VMs, managed databases, container apps, browsers, write-only secrets, AI provider connections and the workspace orchestrator each have a resource. Creates wait until the thing is actually serving, plan-pool exhaustion surfaces as a clear "raise your plan" diagnostic, and secret values use Terraform's write-only arguments so plaintext never lands in your state — mirroring the platform's write-only secret store.
# A Linux VM — with an AI daemon so agents can drive it
resource "livellm_vm" "dev" {
name = "dev-box"
desktop = true # GUI Linux Desktop; omit for a terminal VM
cpus = 4
memory_gi = 8
disk_gi = 40
username = "dev"
password_wo = var.vm_password # write-only: never in your state
password_wo_version = 1 # bump to rotate
ai_daemon {
provider = "zai-coding-plan" # a provider connected on /integrations
model = "glm-5.2"
}
}
# A managed Postgres
resource "livellm_storage" "db" {
name = "app-db"
engine = "postgres"
version = "16"
disk_gi = 20
username = "app"
password_wo = var.db_password
password_wo_version = 1
backup_schedule = "0 3 * * *"
backup_keep = 7
}
# A write-only workspace secret (never lands in your tfstate)
resource "livellm_secret" "tg_token" {
path = "/prod/tg-bot-token"
value_wo = var.tg_token
value_wo_version = 1 # bump to rotate
}
# A container app wired to both
resource "livellm_container_app" "bot" {
name = "tg-bot"
image = "nginx:1.27"
env = { DB_HOST = livellm_storage.db.endpoints[0].addr }
secret_env {
name = "TELEGRAM_BOT_TOKEN"
path = livellm_secret.tg_token.path
}
port {
name = "http"
port = 8080
}
}
# An agent-driven browser
resource "livellm_browser" "scraper" {
name = "scraper"
ai_agent {
provider = "zai-coding-plan"
model = "glm-5.2"
}
}The insides come back too
Terraform declares a machine's shape. What is inside it — packages, services, config — is kept as code in its machine state repo, which outlives the machine on purpose. So destroy then apply returns the same machine, not an empty one with the same name.
output "blueprint" {
value = livellm_vm.dev.state_repo_url
}
$ terraform destroy -target=livellm_vm.dev
$ terraform apply
# the machine is rebuilt, then its blueprint is replayed onto itEverything Terraform does is plain API calls underneath — the reference documents every endpoint, and AI agents can drive the same surface via SKILL.md.