Ambiente de deploy

Arquitetura

Seu site roda em Cloudflare Workers com SSR (renderização no servidor). As peças, na ordem em que uma request as atravessa:

• Worker — recebe toda request, resolve geo/sessão e renderiza o HTML no servidor
• Workers Assets — serve os arquivos estáticos (JS, CSS, imagens) do build. É o binding ASSETS, declarado no wrangler.toml do seu fork apontando para ./build/client
• Bucket R2 de arquivo — binding ASSETS_ARCHIVE. Não é o armazenamento principal dos assets: é uma rede de segurança para a janela de deploy. Quando um usuário está com a versão antiga aberta e pede um chunk que o build novo já não tem, o Worker cai nesse bucket em vez de devolver 404
• KV — guarda um snapshot do HTML/.data renderizado, usado como fallback do cache de SSR. O binding é adicionado ao worker em tempo de deploy
• Binding de serviço API_SERVICE — as chamadas ao backend passam por um worker proxy posicionado perto da origem da API, evitando o salto de rede da borda até o backend
• CDN — a rede global da Cloudflare entrega o conteúdo cacheado

O wrangler.toml também declara um Cron Trigger de 2 em 2 minutos, usado por um aquecedor de cache. Ele sobe inerte: só faz algo se as variáveis CACHE_WARMER_ENABLED e CACHE_WARMER_PATHS estiverem configuradas no ambiente.

Variáveis de ambiente

Em produção, as variáveis vivem no worker do Cloudflare e são configuradas pelo time Cactus junto com você. A lista viva e autoritativa é a interface Env em worker-configuration.d.ts, na raiz do seu fork — cada variável está documentada ali, com o default quando existe. As tabelas abaixo cobrem o que é relevante para você.

Variáveis que você define

Variável	Descrição
API_BASE_URL	URL base da API
BRAND_COUNTRY	Código ISO do país (ex: BRA)
BRAND_CURRENCY	Código da moeda (ex: BRL)
BRAND_TIMEZONE	Fuso horário (ex: America/Sao_Paulo)
CASSINO_MODE	Origem das listagens do cassino: legacy | api_new | mixed. Default legacy — valor ausente ou inválido cai nele
TURNSTILE_SITE_KEY	Site key do Cloudflare Turnstile (captcha)
RECAPTCHA_SITE_KEY	Site key do reCAPTCHA (alternativa ao Turnstile)
RUT_VALIDATION	Liga o fluxo de identidade do Chile. "true" ativa; qualquer outro valor ou ausência mantém o cadastro anterior. Só surte efeito quando o país é CHL
FORCE_SPORTBOOK	Força o provider do sportsbook neste ambiente, ignorando o main da config da marca: first | altenar | betby | rogue. Vazio ou inválido = usa a config estática
FAV_GAMES_API_URL	URL da API de jogos favoritos
SSR_CACHE_HTML_TTL	TTL de borda do documento HTML, em segundos. Default 60
SSR_CACHE_DATA_TTL	TTL de borda das respostas .data de navegação SPA, em segundos. Default 30
SSR_CACHE_KV_TTL	TTL do snapshot em KV, em segundos. Default 180
AUTH_SSR_CACHE_HTML_TTL	Equivalente ao SSR_CACHE_HTML_TTL para páginas de usuário logado. Default 60
AUTH_SSR_CACHE_DATA_TTL	Equivalente ao SSR_CACHE_DATA_TTL para usuário logado. Default 30

worker-configuration.d.ts traz ainda outros controles de cache e alguns kill-switches de rollout — SSR_SWR_ENABLED, SHARED_PUBLIC_DOC_FOR_AUTH e CACHE_WARMER_ENABLED, todos desligados por padrão (só "true" liga; qualquer outro valor ou ausência mantém desligado), mais a configuração que o aquecedor de cache exige quando ligado (CACHE_WARMER_PATHS, CACHE_WARMER_ORIGIN). Ligue-os junto com o time Cactus, não por conta.

Secrets

Mesma coisa que as de cima, com uma diferença de manuseio: use wrangler secret put <NOME> ou o painel do Cloudflare. Nunca no repositório, nunca em [vars] do wrangler.toml.

Secret	Descrição
CF_WORKER_KEY	Chave de autenticação do worker junto ao backend
CACHE_PURGE_SECRET	Autoriza a invalidação manual de cache
SMARTICO_SALT_KEY	Salt do hash de usuário da gamificação, gerado no servidor
SPORTS_ROGUE_API_KEY	Chave server-to-server do sportsbook rogue. Só necessária quando FORCE_SPORTBOOK=rogue
FAV_GAMES_API_KEY	Chave da API de jogos favoritos
APPSFLYER_API_KEY	Chave do proxy AppsFlyer. Só necessária para marcas com AppsFlyer configurado

Variáveis injetadas pelo pipeline

Estas são resolvidas em tempo de deploy pela automação do time Cactus. Não configure manualmente — qualquer valor definido no painel é sobrescrito no próximo deploy.

Variável	O que carrega
ORIGIN_DOMAIN	Domínio da sua marca, vindo da configuração do ambiente
PUBLIC_DOMAIN	Domínio público canônico, quando difere do ORIGIN_DOMAIN. Consumido só pelas superfícies de SEO (robots.txt, canonical, og:url, JSON-LD). Vazio = SEO usa o ORIGIN_DOMAIN
BRAND_LANGUAGE	Idioma padrão do ambiente
BUILD_ID	SHA do commit publicado. Entra em toda chave de cache e no payload de /api/version
BUILD_TS	Timestamp do deploy. É o critério de desempate que permite ao worker detectar que virou uma versão órfã e parar de escrever no cache
CACHE_NAMESPACE	Prefixo de cache exclusivo do deploy, derivado do nome do worker. Isola entradas entre ambientes que compartilham ORIGIN_DOMAIN
CACHE_GENERATION	Token global de geração de cache. É girado sob demanda para forçar um cache limpo em toda a frota
PLATFORM_CACHE_POLICY_JSON	Política de cache (TTLs por recurso) do seu ambiente

:::note TTLs de cache de dados Os TTLs por recurso (catálogo de jogos, detalhe de jogo, rows da home…) vêm dentro do PLATFORM_CACHE_POLICY_JSON e são definidos por ambiente pelo time da plataforma — não estão no código do seu fork e mudam com frequência. Não vale fixar um número em documentação nem em código; leia o valor efetivo do ambiente.

Cada deploy gira o BUILD_ID, e isso por si só invalida os caches de renderização. Para forçar atualização de dados sem fazer deploy — tipicamente depois de uma mudança no backoffice — existe o endpoint POST /api/cache/purge do próprio worker, autenticado com o CACHE_PURGE_SECRET. Ele é uma saída de emergência, não parte do fluxo normal.

Para testar cache localmente, o .env.example traz uma política de exemplo comentada com valores curtos, adequados a desenvolvimento. :::

Build

pnpm build

Gera o build de produção em build/.

Processo de deploy

O deploy roda por GitHub Actions. O workflow no seu fork é .github/workflows/ci-deploy.yml, e aparece na aba Actions com o nome CI/CD — não como "Deploy".

Ele faz duas coisas: roda o gate de qualidade (lint, typecheck, testes) e, quando aplicável, chama o workflow de deploy centralizado mantido pelo time Cactus. Você não configura tokens da Cloudflare nem nomes de worker: isso fica do lado da plataforma.

Qual branch é publicada

Cada ambiente tem uma branch fixa, declarada na configuração de deploy que o time Cactus mantém. O workflow resolve o HEAD dessa branch e publica esse commit.

:::caution Não existe override manual de ref Não há input de ref, branch ou sha. O workflow_dispatch aceita um input: o environment de destino.

E atenção ao seletor nativo do GitHub, o "Use workflow from": ele escolhe qual versão do arquivo YAML do workflow executa — não tem nenhum efeito sobre o código da aplicação que vai ser buildado e publicado. Esse é sempre a branch fixada para o ambiente.

Se você precisa publicar outra branch em um ambiente, o pedido é de mudança de configuração: fale com o time Cactus. :::

Não presuma que a branch do seu ambiente é a main. Ambientes diferentes de uma mesma marca frequentemente apontam para branches diferentes.

Deploy automático no push

Deploy automático em push é opt-in por ambiente e vem desligado por padrão. Se ele não estiver habilitado para o seu ambiente, nenhum push publica nada — o único caminho é o deploy manual. Confirme com o time Cactus como o seu ambiente está configurado antes de assumir que "commitar publica".

Quando está habilitado: push na branch do ambiente → gate de qualidade → build → deploy.

Deploy manual

Vá em Actions → CI/CD → Run workflow e escolha o environment de destino.

:::caution Quem pode disparar um deploy manual Um ambiente pode exigir que quem dispara pertença a um time de deployers específico. Quando essa proteção está ativa, o disparo manual de quem está fora do time falha em um passo de autorização, com uma mensagem de gate — não é um bug do workflow nem falta de permissão no seu fork.

A proteção vale só para o disparo manual. Deploy automático em push nunca passa por ela.

Se você precisa poder publicar manualmente, peça ao time Cactus para incluir você no time de deployers do ambiente. :::

O que acontece nos bastidores

1. O ci-deploy.yml do seu fork roda lint, typecheck e testes
2. Ele chama o workflow de deploy centralizado, passando o ambiente de destino
3. A automação resolve a configuração do ambiente: nome do worker, conta Cloudflare, domínio, idioma e branch
4. Se houver proteção de deploy e o disparo for manual, o gate de autorização é avaliado
5. O projeto é buildado com as variáveis de build-time do ambiente injetadas
6. O deploy vai para o worker correto, com as variáveis de runtime injetadas
7. O BUILD_ID novo faz os namespaces de cache virarem sozinhos — dependendo do ambiente, o pipeline ainda dispara uma invalidação explícita por cima

Ambientes

Cada marca pode ter vários ambientes — produção, stage e ambientes dedicados, por exemplo. Cada ambiente é um worker separado, com domínio, variáveis e branch próprios.

O time Cactus define quais ambientes existem para a sua marca e informa quais são os seus. Não trate o dropdown environment do disparo manual como essa lista: ele é compartilhado e não reflete o que você tem permissão para publicar. Fale com o time para solicitar um ambiente novo.