Referência de secrets e variáveis
Catálogo das org secrets do GitHub usadas no deploy, das variáveis/secrets do Worker na Cloudflare, e de onde cada coisa é consumida.
Esta página lista nomes, nunca valores. Se você precisa do valor de uma secret, pegue no cofre/dashboard — não em documentação.
Org secrets (GitHub — org cactus-agents)
Ao criar um novo fork/repo, adicione-o ao Repository access de cada secret relevante.
GitHub
| Secret | Escopo do PAT | Consumido por | Uso |
|---|---|---|---|
GH_PACKAGES_TOKEN | read:packages | job quality do caller; lighthouse-base.yml | Instalar @cactus-agents/* no CI |
FRONT_GH_ACTIONS_TOKEN | repo, read:packages, read:org | reusable de deploy; bump-cache-generation.yml; sync-purge-options.yml; purge-all.yml; purge-monitor.yml; lighthouse-base.yml; ci-release.yml do core | Checkout do front-ops (privado), install de pacotes, resolução do HEAD SHA via API, authorization gate de team, e os pushes que precisam bypassar branch protection |
:::info read:org
O FRONT_GH_ACTIONS_TOKEN precisa de read:org para o gate de
deploy_protection.required_team conseguir consultar a membership do ator no
team (GET /orgs/cactus-agents/teams/<team>/memberships/<actor>).
:::
Cloudflare (por conta — prefixo {XX} = CT / BT / TS)
| Secret | Obrigatório | Consumido por (step / workflow) | Uso |
|---|---|---|---|
FRONT_{XX}_CF_ACCOUNT_ID | ✅ | Resolve CF credentials; deploy-docs; deploy-affiliates; manual-cache-purge; purge-all | Account ID da conta CF |
FRONT_{XX}_CF_API_TOKEN | ✅ | idem acima + deploy e purges | Token de API — permissions em Adicionar conta CF |
FRONT_{XX}_CF_WORKER_KEY | recomendado | Resolve API_BASE_URL and CF_WORKER_KEY, Resolve cache purge secrets; cache-status; manual-cache-purge; purge-all; purge-monitor (fallback) | CF_WORKER_KEY injetado no build + header cf-worker-key (WAF bypass) nos purges |
FRONT_{XX}_CACHE_PURGE_SECRET | recomendado | Resolve cache purge secrets; cache-status; manual-cache-purge; purge-all | Header X-Cache-Secret no purge de platform cache. Sem ele o purge de platform cache é pulado (warning) |
FRONT_{XX}_CF_WORKER_KEY_PROXY | condicional | purge-monitor.yml | Header cf-worker-key-proxy nas chamadas diretas ao BFF. Cai em FRONT_{XX}_CF_WORKER_KEY como fallback; o workflow erra se nenhum dos dois existir |
FRONT_{XX}_R2_ASSETS_ACCESS_KEY | opcional | Resolve R2 S3 API credentials | Access key da R2 S3 API para sync de assets |
FRONT_{XX}_R2_ASSETS_SECRET | opcional | Resolve R2 S3 API credentials | Secret da R2 S3 API. Sem o par, o sync de assets para R2 é pulado (warning) |
Outras
| Secret | Obrigatório | Consumido por | Uso |
|---|---|---|---|
AWS_WARMUP_ROLE_ARN | só quando run_warm_cutover: true | deploy.yml, step Configure AWS credentials (warm collector) | Role assumida via OIDC em eu-central-1. Precisa de ssm:SendCommand e ssm:ListCommandInvocations nas instâncias com a tag front-web-warmup=<tenant>. Único credential não-Cloudflare e não-GitHub do caminho de deploy |
LHCI_GITHUB_APP_TOKEN | opcional | lighthouse-base.yml | Token do Lighthouse CI GitHub App |
:::caution Secrets pouco visíveis
FRONT_{XX}_CF_WORKER_KEY, FRONT_{XX}_CACHE_PURGE_SECRET e
FRONT_{XX}_R2_ASSETS_* não causam falha fatal quando ausentes — o pipeline
emite apenas ::warning:: e pula a etapa correspondente. Resultado: deploys
"verdes" mas com cache potencialmente stale ou sem fallback de chunks.
:::
Para adicionar uma conta CF nova (e as linhas de env correspondentes nos workflows), ver Adicionar conta CF.
Variáveis e secrets do Worker (Cloudflare)
Lidas pelo pipeline dos bindings do Worker
| Variável | Tipo | Uso |
|---|---|---|
API_BASE_URL | Plain | A única var que o pipeline lê dos bindings (GET /accounts/{id}/workers/scripts/{name}/bindings) e injeta no build. Sem ela: ::warning::API_BASE_URL not found in Cloudflare bindings e o build sai sem a URL |
:::danger CF_WORKER_KEY NÃO é lido do binding
Apesar do nome do step ser Resolve API_BASE_URL and CF_WORKER_KEY, ele extrai
dos bindings apenas API_BASE_URL. CF_WORKER_KEY vem exclusivamente da org
secret FRONT_{XX}_CF_WORKER_KEY, por indireção
(WORKER_VAR="SECRET_${CF_ACCOUNT}_WORKER_KEY"). Não há fallback para o
binding.
Consequência operacional: se você configurar CF_WORKER_KEY só como secret do
Worker e não como org secret, o build sai com a chave vazia e sem erro nenhum.
A chave também precisa existir como secret do Worker — mas por outro motivo: o uso em runtime (Worker → BFF). São duas configurações independentes. :::
Injetadas no build (não são vars do Worker)
Estas vão para o .env e/ou para o env: do step Build. Elas são compiladas no
bundle — não aparecem como binding no Worker.
| Variável | Onde | Origem |
|---|---|---|
BRAND_LANGUAGE | .env + Build | deploy.yml::language |
ORIGIN_DOMAIN | .env + Build | deploy.yml::origin_domain |
API_BASE_URL | .env + Build | binding do Worker |
CF_WORKER_KEY | .env + Build | org secret FRONT_{XX}_CF_WORKER_KEY |
GITHUB_SHA | só Build | deploy_ref (HEAD do default_branch) |
Injetadas no wrangler.toml como [vars] (NÃO configurar à mão)
O step Patch wrangler.toml with runtime vars anexa um bloco [vars] único com
16 chaves, e depois o binding [[kv_namespaces]].
| Variável / binding | Origem | Default emitido |
|---|---|---|
BUILD_ID | primeiros 12 chars do deploy_ref | — (falha se não resolver) |
BUILD_TS | date +%s no momento do patch | — |
WORKER_NAME | deploy.yml::worker_name | — |
CACHE_GENERATION | config/cache/generation.yml::current + -<BUILD_ID> | só emitido se não-vazio |
CACHE_WARMER_ENABLED | deploy.yml::cache_warmer.enabled | false |
CACHE_WARMER_PATHS | deploy.yml::cache_warmer.paths | só se não-vazio |
CACHE_WARMER_ORIGIN | deploy.yml::cache_warmer.origin | só se não-vazio |
SHARED_PUBLIC_DOC_FOR_AUTH | deploy.yml::shared_public_doc_for_auth | false |
SSR_SWR_ENABLED | deploy.yml::ssr_swr_enabled | false |
SSR_CACHE_HTML_TTL | deploy.yml::ssr_cache.html_ttl | 60 |
SSR_CACHE_DATA_TTL | deploy.yml::ssr_cache.data_ttl | 60 |
SSR_CACHE_KV_TTL | deploy.yml::ssr_cache.kv_ttl | 180 |
SSR_CACHE_DATA_BROWSER_TTL | deploy.yml::ssr_cache.data_browser_ttl | 0 |
PUBLIC_DOMAIN | deploy.yml::public_domain | sempre emitido (pode ser vazio) |
PLATFORM_CACHE_POLICY_JSON | merge de config/cache/* | só se a policy resolveu |
CACHE_NAMESPACE | = worker_name | junto com a policy |
PLATFORM_CACHE_KV (binding) | KV provisionado no deploy | só se algum recurso usa snapshot KV |
ASSETS, ASSETS_ARCHIVE, API_SERVICE (bindings) | wrangler.toml do base | — |
:::info Por que o pipeline emite false / 0 em vez de omitir a chave
O deploy roda wrangler deploy --keep-vars. Com --keep-vars, uma chave que o
pipeline não escreve mantém o valor antigo pinado no Worker — uma flag
desligada no front-ops continuaria ligada em produção. Por isso os booleanos e
TTLs são sempre emitidos com default explícito. Só as chaves puramente
aditivas (CACHE_WARMER_PATHS, CACHE_WARMER_ORIGIN, CACHE_GENERATION,
PLATFORM_CACHE_POLICY_JSON) são condicionais.
:::
:::info BUILD_TS é load-bearing
BUILD_TS alimenta o build-currency gate do worker — o mecanismo que permite a
uma versão órfã detectar que está stale e desligar o próprio cache SSR
(X-Cache: BYPASS-STALE-BUILD). Foi o que fechou o postmortem stage-7k de
2026-07-14, e é por isso que os deploys do mesmo worker são serializados por
concurrency (dois runs fora de ordem invertem o BUILD_TS).
:::
Quando deploy_entry_worker: true, o worker <worker_name>-entry recebe um
subconjunto em lockstep: BUILD_ID, BUILD_TS, CACHE_NAMESPACE,
CACHE_GENERATION e os quatro SSR_CACHE_*_TTL. Sem KV e sem policy.
Configuradas por brand (runtime — você define no Worker)
| Variável | Tipo | Quando |
|---|---|---|
BRAND_COUNTRY | Plain | sempre (BRA, CHL, MEX, PER, NGA, …) |
BRAND_CURRENCY | Plain | sempre (BRL, CLP, MXN, PEN, NGN, …) |
BRAND_TIMEZONE | Plain | recomendado (server-only) |
BRAND_CACHE_TTL | Plain | opcional |
CASSINO_MODE | Plain | opcional (legacy/api_new) |
FORCE_SPORTBOOK | Plain | opcional (first/altenar/betby/rogue) |
STICKER_API_URL | Plain | se usa sticker-album |
TURNSTILE_SITE_KEY / RECAPTCHA_SITE_KEY | Plain | se usa captcha |
API_BASE_URL | Plain | sempre — lida pelo pipeline |
CF_WORKER_KEY | Secret | runtime Worker → BFF (o pipeline pega da org secret, não daqui) |
SMARTICO_SALT_KEY | Secret | se usa gamification Smartico |
SPORTS_ROGUE_API_KEY | Secret | se FORCE_SPORTBOOK=rogue |
CACHE_PURGE_SECRET | Secret | endpoint de purge via webhook (runtime) |
CACHE_GENERATION_SECRET | Secret | escrito pelo cutover run_warm_cutover para flipar a generation sem rebuild |
:::info Referência canônica das vars do app
A lista detalhada de variáveis do template, com a interface ClientEnv e
prioridades de resolução, está em
Template → Environment Variables.
:::
Mapa rápido: "o que configurar onde"
GitHub org secrets → credenciais de plataforma (CF account/token,
(Settings → Actions) GH tokens, purge/worker-key/R2 por conta,
AWS_WARMUP_ROLE_ARN)
front-ops/.../deploy.yml → identidade do deploy + flags de rollout
(config-as-code) (worker_name, domínios, branch, conta CF,
cf_zone, proteção, ssr_cache, cache_warmer,
entry worker, cutover)
front-ops/config/cache/ → política de cache, generation token,
rotas do monitor, política do service-api
Worker (CF dashboard) → config da brand em runtime (API_BASE_URL,
Variables and Secrets BRAND_*, secrets Smartico/Rogue, CF_WORKER_KEY)