* fix(terraform): add soft_budget, tags, and soft_budget_alerting_emails to litellm_team The team resource rejected soft_budget and tags at plan time and had no way to express the list-valued metadata.soft_budget_alerting_emails the proxy reads for soft-budget alerts, even though /team/new and /team/update accept all three. Add the attributes, forward them in buildTeamData (alert emails merged under metadata, where the proxy stores them), and send the full metadata map whenever either half changes because /team/update replaces metadata wholesale. Read was decoding /team/info as if the team fields were top-level, but the proxy nests them under team_info, so every attribute silently fell back to prior state. Decode the envelope and split the proxy's metadata back into tags / soft_budget_alerting_emails / string metadata, dropping the server-managed team_member_budget_id. Verified with OpenTofu plan/apply against a live proxy: the attributes are accepted, land on the proxy, refresh into state, re-plan clean, propagate on update, and clear when removed from HCL. * fix(terraform): clear litellm_team.soft_budget in state when the proxy returns null Read only wrote soft_budget when the proxy returned a value, so a soft budget cleared outside Terraform stayed in state and never surfaced as drift. Set it from the response unconditionally so a null clears it. |
||
|---|---|---|
| .. | ||
| docs | ||
| examples | ||
| litellm | ||
| tools | ||
| .gitignore | ||
| .goreleaser.yml | ||
| CHANGELOG.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| Makefile | ||
| README.md | ||
| RELEASING.md | ||
| terraform-registry-manifest.json | ||
LiteLLM Terraform Provider
This Terraform provider allows you to manage LiteLLM resources through Infrastructure as Code. It provides support for managing models, teams, team members, and API keys via the LiteLLM REST API.
Source of truth
This directory (terraform/provider/ in BerriAI/litellm) is the source of truth for the provider. BerriAI/terraform-provider-litellm is a thin release mirror that the public Terraform Registry ingests from; do not open PRs there. Changes land here, where CI builds the provider, runs its tests, and statically audits every endpoint the provider calls against the proxy's generated OpenAPI schema (tools/endpointaudit/), so the provider cannot drift from the LiteLLM API silently. Releases are published by mirroring this directory into the split repo and tagging it, which triggers the goreleaser workflow there (see RELEASING.md)
Versioning
The provider version is the LiteLLM version. Every LiteLLM release (dev, rc and stable) publishes the provider at the same version as the proxy, built from the same commit, so 1.99.0 of the provider is the one that shipped with 1.99.0 of the proxy and was audited against that proxy's API. Pin the provider to the line your proxy runs:
version = "~> 1.99.0"
Pre-release versions (1.99.0-rc.1, 1.99.0-dev.1) are published too; Terraform only selects one when it is pinned exactly.
Versions 0.1.0 through 0.4.0 predate this scheme and sit on their own line. They stay in the registry, but a ~> 0.4 constraint will never pick up another release: re-pin to the LiteLLM version to keep receiving updates.
Features
- Manage LiteLLM model configurations
- Associate models with specific teams
- Create and manage teams
- Configure team members and their permissions
- Set usage limits and budgets
- Control access to specific models
- Specify model modes (e.g., completion, embedding, image generation)
- Manage API keys with fine-grained controls
- Support for reasoning effort configuration in the model resource
Requirements
Using the Provider
To use the LiteLLM provider in your Terraform configuration, you need to declare it in the terraform block:
terraform {
required_providers {
litellm = {
source = "BerriAI/litellm"
version = "~> 1.99.0" # the LiteLLM version your proxy runs
}
}
}
provider "litellm" {
api_base = var.litellm_api_base
api_key = var.litellm_api_key
}
Then, you can use the provider to manage LiteLLM resources. Here's an example of creating a model configuration:
resource "litellm_model" "gpt4" {
model_name = "gpt-4-proxy"
custom_llm_provider = "openai"
model_api_key = var.openai_api_key
model_api_base = "https://api.openai.com/v1"
base_model = "gpt-4"
tier = "paid"
mode = "chat"
reasoning_effort = "medium" # Optional: "low", "medium", or "high"
input_cost_per_million_tokens = 30.0
output_cost_per_million_tokens = 60.0
}
For full details on the litellm_model resource, see the model resource documentation.
Here's an example of creating an API key with various options:
resource "litellm_key" "example_key" {
models = ["gpt-4", "claude-3.5-sonnet"]
max_budget = 100.0
user_id = "user123"
team_id = "team456"
max_parallel_requests = 5
tpm_limit = 1000
rpm_limit = 60
budget_duration = "monthly"
key_alias = "prod-key-1"
duration = "30d"
metadata = {
environment = "production"
}
allowed_cache_controls = ["no-cache", "max-age=3600"]
soft_budget = 80.0
aliases = {
"gpt-4" = "gpt4"
}
config = {
default_model = "gpt-4"
}
permissions = {
can_create_keys = "true"
}
model_max_budget = {
"gpt-4" = 50.0
}
model_rpm_limit = {
"claude-3.5-sonnet" = 30
}
model_tpm_limit = {
"gpt-4" = 500
}
guardrails = ["content_filter", "token_limit"]
blocked = false
tags = ["production", "api"]
}
The litellm_key resource supports the following options:
models: List of allowed models for this keymax_budget: Maximum budget for the keyuser_idandteam_id: Associate the key with a user and teammax_parallel_requests: Limit concurrent requeststpm_limitandrpm_limit: Set tokens and requests per minute limitsbudget_duration: Specify budget duration (e.g., "monthly", "weekly")key_alias: Set a friendly name for the keyduration: Set the key's validity periodmetadata: Add custom metadata to the keyallowed_cache_controls: Specify allowed cache control directivessoft_budget: Set a soft budget limitaliases: Define model aliasesconfig: Set configuration optionspermissions: Specify key permissionsmodel_max_budget,model_rpm_limit,model_tpm_limit: Set per-model limitsguardrails: Apply specific guardrails to the keyblocked: Flag to block/unblock the keytags: Add tags for organization and filtering
For full details on the litellm_key resource, see the key resource documentation.
Available Resources
litellm_model: Manage model configurations. Documentationlitellm_team: Manage teams. Documentationlitellm_team_member: Manage team members. Documentationlitellm_team_member_add: Add multiple members to teams. Documentationlitellm_key: Manage API keys. Documentationlitellm_mcp_server: Manage MCP (Model Context Protocol) servers. Documentationlitellm_credential: Manage credentials for secure authentication. Documentationlitellm_vector_store: Manage vector stores for embeddings and RAG. Documentation
Available Data Sources
litellm_credential: Retrieve information about existing credentials. Documentationlitellm_vector_store: Retrieve information about existing vector stores. Documentation
Development
Project Structure
The project is organized as follows:
terraform-provider-litellm/
├── litellm/
│ ├── provider.go
│ ├── resource_model.go
│ ├── resource_model_crud.go
│ ├── resource_team.go
│ ├── resource_team_member.go
│ ├── resource_key.go
│ ├── resource_key_utils.go
│ ├── types.go
│ └── utils.go
├── main.go
├── go.mod
├── go.sum
├── Makefile
└── ...
Building the Provider
- Clone the repository:
git clone https://github.com/your-username/terraform-provider-litellm.git
- Enter the repository directory:
cd terraform-provider-litellm
- Build and install the provider:
make install
Development Commands
The Makefile provides several useful commands for development:
make build: Builds the providermake install: Builds and installs the providermake test: Runs the test suitemake fmt: Formats the codemake vet: Runs go vetmake lint: Runs golangci-lintmake clean: Removes build artifacts and installed provider
Testing
To run the tests:
make test
Contributing
Contributions are welcome! Please read our contributing guidelines first.
License
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
Notes
- Always use environment variables or secure secret management solutions to handle sensitive information like API keys and AWS credentials.
- Refer to the comprehensive documentation in the
docs/directory for detailed usage examples and configuration options. - Keep the provider version in step with the LiteLLM version your proxy runs; see Versioning.
- The provider now supports AWS cross-account access with
aws_session_nameandaws_role_nameparameters in the model resource. - All example configurations have been consolidated into the documentation for better organization and maintenance.