Adicionar uma nova conta Cloudflare

Cada environment aponta para uma conta Cloudflare via o campo cf_account no deploy.yml. O valor é um prefixo de 2-4 letras maiúsculas que mapeia para um conjunto de org secrets.

Contas atuais:

Nome	Prefixo	Secrets base
Cactus	CT	FRONT_CT_CF_ACCOUNT_ID, FRONT_CT_CF_API_TOKEN
Bluetec	BT	FRONT_BT_CF_ACCOUNT_ID, FRONT_BT_CF_API_TOKEN
Teste	TS	FRONT_TS_CF_ACCOUNT_ID, FRONT_TS_CF_API_TOKEN

Passo a passo

1 — Criar o API Token na Cloudflare

No Cloudflare Dashboard da conta nova → My Profile → API Tokens → Create Token (Custom token). O token precisa de todas estas permissions:

Permission	Step que consome
Account > Workers Scripts > Edit	wrangler deploy (worker principal e, se aplicável, o -entry)
Account > Workers KV Storage > Edit	Provision KV namespace (quando a policy usa snapshot KV)
Account > Workers R2 Storage > Edit	Ensure R2 bucket exists (idempotent) — o deploy roda wrangler r2 bucket create front-assets-archive
Zone > Zone > Read	resolução do Zone ID para o purge
Zone > Cache Purge > Purge	purge SSR pós-deploy

• Account Resources: Include → a conta nova.
• Zone Resources: Include → Specific zone → cada zona apex que será deployada nessa conta. (Pode adicionar mais zonas depois conforme novas brands chegam.)

:::caution Faltou permission = falha silenciosa Falta de Zone:Read ou Cache Purge:Purge resulta em HTTP 401/403 no purge pós-deploy (warning, não erro fatal). Falta de Workers Scripts:Edit quebra o wrangler deploy. Falta de Workers R2 Storage:Edit quebra o r2 bucket create — que roda com || true, então o sintoma aparece só depois, no sync de assets. :::

2 — Criar as org secrets no GitHub

GitHub → cactus-agents → Settings → Secrets and variables → Actions. Crie, no mínimo:

• FRONT_{PREFIX}_CF_ACCOUNT_ID — o Account ID da conta CF
• FRONT_{PREFIX}_CF_API_TOKEN — o token criado no passo 1

E, conforme os recursos usados pela conta (ver Referência de secrets):

• FRONT_{PREFIX}_CACHE_PURGE_SECRET — habilita o purge de platform cache
• FRONT_{PREFIX}_CF_WORKER_KEY — chave injetada no build + header cf-worker-key (WAF bypass) nos purges
• FRONT_{PREFIX}_CF_WORKER_KEY_PROXY — header cf-worker-key-proxy do purge-monitor (cai no _CF_WORKER_KEY como fallback)
• FRONT_{PREFIX}_R2_ASSETS_ACCESS_KEY / FRONT_{PREFIX}_R2_ASSETS_SECRET — sync de assets para R2 (fallback de chunks)

Em Repository access de cada secret, adicione todos os repos que farão deploy nessa conta.

3 — Registrar o prefixo em TODOS os workflows que têm registro de secrets

:::info Por que precisa editar YAML GitHub Actions não permite indexar secrets.* dinamicamente por nome. Cada workflow expõe as secrets como env vars nomeadas e resolve por indireção (${!VAR_NAME}). Um prefixo novo que não esteja no registro de um workflow falha silenciosamente naquele workflow — o resto continua funcionando, o que torna o bug difícil de achar. :::

Sete arquivos em front-ops/.github/workflows/ carregam registros. Percorra todos:

Workflow	Step	Chaves a adicionar
deploy.yml	Resolve CF credentials	SECRET_XX_ID, SECRET_XX_TOKEN
deploy.yml	Resolve API_BASE_URL and CF_WORKER_KEY	SECRET_XX_WORKER_KEY
deploy.yml	Resolve R2 S3 API credentials	SECRET_XX_R2_KEY, SECRET_XX_R2_SECRET
deploy.yml	Resolve cache purge secrets	SECRET_XX_PURGE, SECRET_XX_WORKER_KEY
deploy.yml	Purge service-api cache BEFORE deploy (opt-in)	SECRET_XX_PURGE, SECRET_XX_WORKER_KEY
deploy.yml	Purge all — multi-camada (após o bump)	SECRET_XX_PURGE, SECRET_XX_WORKER_KEY
purge-all.yml	Resolve CF creds for the brand's account	SECRET_XX_ID, SECRET_XX_TOKEN
purge-all.yml	Resolve purge + worker key secrets	SECRET_XX_PURGE, SECRET_XX_WORKER_KEY
purge-monitor.yml	Resolve CF worker key proxy	SECRET_XX_PROXY, SECRET_XX_FALLBACK
manual-cache-purge.yml	Resolve cache purge secret	SECRET_XX, WORKER_KEY_XX, CF_API_TOKEN_XX, CF_ACCOUNT_ID_XX
cache-status.yml	Resolve secret	SECRET_XX, KEY_XX
deploy-docs.yml	Resolve CF credentials	SECRET_XX_ID, SECRET_XX_TOKEN
deploy-affiliates.yml	Resolve CF credentials	SECRET_XX_ID, SECRET_XX_TOKEN

:::caution A convenção de nome das env vars muda de workflow para workflow deploy.yml / purge-all.yml usam SECRET_{XX}_<COISA>; manual-cache-purge.yml e cache-status.yml usam SECRET_{XX} para o purge secret e sufixam a conta no fim (WORKER_KEY_{XX}, CF_API_TOKEN_{XX}). Copie o padrão do arquivo que você está editando, não deste doc. :::

Exemplo, no Resolve CF credentials do deploy.yml:

env:
  CF_ACCOUNT: ${{ needs.check.outputs.cf_account }}
  SECRET_CT_ID: ${{ secrets.FRONT_CT_CF_ACCOUNT_ID }}
  SECRET_CT_TOKEN: ${{ secrets.FRONT_CT_CF_API_TOKEN }}
  # ... BT, TS ...
  SECRET_XX_ID: ${{ secrets.FRONT_XX_CF_ACCOUNT_ID }}      # ← novo
  SECRET_XX_TOKEN: ${{ secrets.FRONT_XX_CF_API_TOKEN }}    # ← novo

:::info Lacuna conhecida: R2 só tem CT e BT O step Resolve R2 S3 API credentials do deploy.yml registra apenas SECRET_CT_R2_* e SECRET_BT_R2_* — não há entrada para TS. Um env em TS simplesmente não faz sync de assets para R2 (warning, deploy segue). Se você precisa de R2 numa conta nova, adicione o par lá. :::

4 — Usar nos environments

# environments/<env>/deploy.yml
cf_account: XX

ou como default da brand em brand.yml:

defaults:
  cf_account: XX

Debug rápido de 401 no purge

TOKEN="<FRONT_{XX}_CF_API_TOKEN>"

# 1. Token válido?
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/user/tokens/verify" | jq

# 2. O token enxerga a zona?
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=minha-marca.com" | jq

• verify retorna 401 → token revogado/expirado → regenerar.
• verify OK mas zones?name=… retorna "result": [] → zona ausente do Zone Resources.
• Ambos OK mas POST /purge_cache ainda 401 → token tem Zone:Read mas não Cache Purge:Purge.

Cloudflare Access e service tokens

Os envs stage-* ficam atrás do Cloudflare Access, o que torna o endpoint de purge e o verify HTTP de assets inalcançáveis do runner do GitHub. Hoje a mitigação é declarativa (skip_post_deploy_purge / skip_asset_verify no deploy.yml da env). A solução definitiva é cablear um Access service token no workflow de deploy.

O gerenciamento desses service tokens (e dos tokens de developer) é feito pelo fecadm — ver Infraestrutura → fecadm.