使用 Terraform 或 OpenTofu
官方的 Caputchin 提供方让你把账户作为基础设施即代码来管理:在 .tf 文件里声明团队、站点密钥、安全策略、成员和令牌,并像任何其他资源那样应用它们。它就是 自动化 下其余一切所用的同一个管理 API,表达为 Terraform 资源。
它发布一次,并从同一份源 同时在 Terraform 和 OpenTofu 上工作;HCL 完全相同,只有 CLI 二进制(terraform 或 tofu)和 registry 不同。下面所有地方,用你所跑的那一个。
铸造一个访问令牌
提供方从 CAPUTCHIN_MANAGEMENT_TOKEN 环境变量读它的令牌(推荐,好让它待在源码之外)。两种令牌都能用(见 API 认证):一个 个人访问令牌 用于全账户的基础设施,或一个限定到你配置所管理的那些团队上的 团队访问令牌。
export CAPUTCHIN_MANAGEMENT_TOKEN=cpt_pat_...有一个先有鸡还是先有蛋的情况:提供方也能 铸造 令牌(caputchin_account_token 和 caputchin_troop_pat 资源),但它首先就需要一个令牌来做身份验证。在仪表盘里手动铸造第一个,然后让 Terraform 管理其余的。
配置提供方
terraform {
required_providers {
caputchin = {
source = "caputchin/caputchin"
version = "~> 0.1"
}
}
}
# Token from CAPUTCHIN_MANAGEMENT_TOKEN; endpoint defaults to https://caputchin.com/api.
provider "caputchin" {}同一个 source = "caputchin/caputchin" 从 Terraform Registry 和 OpenTofu Registry 都能解析,所以在任一工具下这一段都一样。
一个完整示例:一个带设了关卡的站点密钥的团队
这会创建一个团队、一个在它里面的站点密钥,并给那个密钥打开游戏关卡:
resource "caputchin_troop" "shop" {
name = "shop-team"
}
resource "caputchin_site_key" "shop_frontend" {
name = "shop-frontend"
troop_id = caputchin_troop.shop.id
}
resource "caputchin_site_security_settings" "shop_frontend" {
site_id = caputchin_site_key.shop_frontend.id
require_game = true
}
# The public key is an attribute; the secret is sensitive, in state only.
output "shop_site_key" {
value = caputchin_site_key.shop_frontend.key
}然后,用任一工具:
terraform init && terraform apply
# or
tofu init && tofu apply这个站点密钥的 secret 是一个敏感的计算属性;从 state 里读它(terraform output)来配置你的 后端验证。在 Apex 上,每次 apply 都归到你的令牌名下、记在 审计日志 里,于是一次通过 Terraform 的更改和一次仪表盘编辑一样可追溯。
你能管理什么
资源覆盖和仪表盘同样的面:团队及其成员和令牌、站点密钥、安全设置、托管验证、游戏与白标自定义,以及账户令牌。数据源让你把现有的团队、站点、账户信息和统计读进一份配置里。
完整参考
每个资源和数据源,带它所有的参数和属性以及导入语法,都在提供方的 registry 页上。它是从提供方源生成的,所以它精确地跟踪已发布的版本:
- Terraform Registry:
registry.terraform.io/providers/caputchin/caputchin - OpenTofu Registry:
search.opentofu.org/provider/caputchin/caputchin
每个资源所执行的底层操作,见 交互式 API 参考。
另见
- 从 API 管理 Caputchin:提供方所坐落的那个 HTTP API。
- 使用 MCP 服务器:那个 AI 代理的面。
- 团队 和 站点密钥:你正在管理的那些资源。