Como preparamos um site de hospedagem compartilhada para a manutenção com Cloudflare Workers
Resposta rápida
Um site PHP majoritariamente estático pode continuar útil durante uma indisponibilidade planejada sem migrar a conta ativa. O Worker diante do KeyboardTester.click passa cada resposta saudável sem alteração e, em falhas de rede ou erros selecionados, entrega um snapshot estático preparado. Quando a origem volta, a próxima resposta saudável reassume automaticamente. É continuidade prática, não zero downtime universal: formulários, e-mail, IA do servidor e ações salvas ainda dependem da hospedagem.
O aviso trouxe uma janela de seis horas, mas não o tempo exato de queda. Esperar um e-mail criaria uma lacuna manual; apontar o DNS para uma única página manteria o aviso, não os conteúdos e ferramentas procurados.
Este é o desenho que realmente implantamos: conversa com a HostArmada, decisão do Worker, snapshot, recursão na mesma zona, proteções do plano grátis, SEO, anúncios, analytics e limitações.
Nota de data: em 18 de julho de 2026, a manutenção programada ainda não ocorreu. Os resultados vêm de falha forçada da origem, staging privado, auditoria do snapshot e passagem saudável em produção, não da janela real.
O que o ticket da HostArmada esclareceu
A manutenção estava marcada para 22 de julho de 2026, das 10h às 16h CDT. Perguntamos se seriam seis horas contínuas, se a conta poderia ser migrada temporariamente, quais serviços cairiam, se haveria um endpoint externo 503 para cada URL, rollback e crédito.
Após a escalada, a administração explicou que seis horas eram a janela reservada, não uma duração confirmada. A queda deveria ser menor, mas sem estimativa exata por causa das trocas físicas, atualizações e validação. Mover e devolver a conta poderia adicionar riscos de DNS, sincronização, e-mail e banco.
A HostArmada ofereceu de forma razoável um vhost em servidor não afetado com página de manutenção e troca manual do registro A no início e fim. O DNS externo continuaria resolvendo, mas web, banco, e-mail e painel no servidor ficariam inacessíveis. Havia backups e recuperação; crédito seria avaliado após o impacto real. Era justo para um aviso, mas manual e sem continuidade funcional.
That offer was fair for a maintenance notice. It was still manual and did not provide functional-site continuity, so we used it as the baseline to improve rather than portraying it as a provider failure.
Linha do tempo verificável: do e-mail ao fallback testado
A sequência separa o anúncio, nossas perguntas, o que foi construído/testado e o evento real ainda futuro.
- Julho de 2026 — e-mail recebido
O aviso Start Dock reservou 22 de julho, 10h–16h CDT: CPU, RAM, SSD; segurança/software web; kernel; limpeza tmp/cache/log; otimização. Dizia que o procedimento não seria reversível após iniciar.
- 16 de julho — perguntas escaladas
Duração real, migração, endpoint 503 externo, web/DB/e-mail, backup, rollback e crédito.
- 17 de julho — resposta HostArmada
Seis horas eram a janela; queda provavelmente menor, migração recusada por sincronização, vhost e A-record manual oferecidos.
- Desenho escolhido em 17 de julho; retorno enviado em 18
Worker origin-first permanente, snapshot, staging privado, colisões, 503 e rollback definidos.
- 17–18 de julho — testes controlados
1.514 páginas, 1.234 assets, 2.748 caminhos auditados, falha/passagem testadas, recursão corrigida e apex/www fail-open ativos.
- 18 de julho — pronto, evento pendente
A camada está ativa e testada; a manutenção do dia 22 não ocorreu. Duração, tráfego e receita reais aguardam evidência.
Arquitetura: origem primeiro, snapshot apenas na falha
O Worker fica sempre nas rotas do domínio raiz e www. Ele consulta a origem com timeout limitado. Resposta saudável passa intacta, mantendo PHP, sessões, headers, anúncios e analytics normais.
Em falha de rede, timeout, 500, 502, 503, 504 ou 520–527, procura o mesmo caminho nos assets estáticos. GET e HEAD continuam; cada pedido seguinte testa a origem outra vez e recupera automaticamente.
O snapshot não é uma segunda pilha PHP, evitando dois bancos graváveis, conflito de sessão, e-mail duplicado e reconciliação posterior.
Fluxo da requisição
Página temporária ou continuidade com Worker?
Uma página atende bem à semântica de manutenção simples; o snapshot exige preparo, mas conserva a maior parte da leitura e das ferramentas no navegador.
| Questão | Vhost temporário | Worker permanente |
|---|---|---|
| Troca | DNS manual no início e fim | Automática por request |
| Visitante vê | Uma página de manutenção | Página, ferramenta ou asset correspondente |
| Escritas | Indisponíveis | Indisponíveis; 503 explícito |
| Recuperação | DNS restaurado manualmente | Automática com origem saudável |
| Consistência | Risco baixo sem segundo banco | Risco baixo sem segundo banco |
| Operação | Simples, mas exige ação no horário | Mais preparo, pouca ação no evento |
O que usuários e robôs recebem na falha
Páginas, ferramentas client-side, CSS, scripts, imagens e fontes vêm do snapshot com um aviso discreto. Canonical e dados estruturados permanecem nas URLs originais.
Ações de escrita não fingem sucesso: POST e ações indisponíveis retornam 503 Service Unavailable, Retry-After: 300 e Cache-Control: no-store, como previsto para manutenção temporária no RFC 9110.
This distinction matters: returning a pretty 200 OK “maintenance” page for a failed form can mislead users and crawlers. Returning a controlled 503 for the unavailable action is both more honest and easier for clients to retry.
Matriz real de fallback
| Resultado da origem | GET / HEAD | POST ou escrita |
|---|---|---|
| Saudável, redirect, 4xx ou fora da lista | Passar origem intacta | Passar origem intacta |
| Falha de rede ou timeout 4,5 s | Snapshot correspondente; 503 se faltar | 503 + Retry-After: 300 + no-store |
| 500/502/503/504 ou 520–527 | Snapshot e header diagnóstico | 503 + Retry-After: 300 + no-store |
| Path seguro desconhecido sem origem | 503 controlado; nenhuma página inventada | Não se aplica |
Como construímos e verificamos o snapshot
Rastreamos a produção renderizada, não a árvore PHP local com mudanças não publicadas. Capturamos 1.514 páginas e 1.234 assets próprios. O pacote final tinha 2.749 arquivos e cerca de 547,6 MB; todos abaixo do limite individual.
Mantivemos canonical e schema e corrigimos referências relativas antigas apenas na cópia. Trackers foram removidos na captura; só o Worker de produção adiciona GA4, AdSense e Clarity na home. O staging privado continua sem tracking e noindex.
A QA cobriu TypeScript, unidades, falha local forçada, staging autenticado, navegador, preview da origem e auditoria remota integral: todos os 2.748 caminhos públicos de página/asset passaram.
Como reproduzir com segurança: etapas e código sanitizado
1. Defina o contrato. Hosts, métodos seguros, status, timeout, path desconhecido e remoção de rotas. Nem todo non-200 é queda.
2. Rastreie produção renderizada. Comece no sitemap, descubra só recursos same-origin HTML/CSS, normalize, bloqueie traversal e falhe se exceder limites.
3. Preserve significado. Mantenha canonical, hreflang, schema, links e assets client-side; retire service worker/tracking. Injete ads/analytics só em produção.
4. Use ASSETS e run_worker_first. Teste a origem antes da cópia; exemplos são placeholders.
5. Evite recursão. Use nome DNS-only controlado na mesma zona para resolveOverride, mantenha URL/Host e teste TLS/vhost.
6. Staging privado. Segredo, noindex, robots bloqueado, sem ads/analytics e origin preview.
7. Anexe apex e depois www. Recuse colisões, valide redirect e use fail-open apenas para disponibilidade.
8. Separe rollback. Remova só rotas próprias, mantenha Worker/snapshot e revogue direitos temporários.
Configuração sanitizada do Worker/assets
{
"name": "example-host-outage-fallback",
"main": "src/index.ts",
"compatibility_date": "2026-07-17",
"assets": {
"directory": "./snapshot/dist",
"binding": "ASSETS",
"run_worker_first": true,
"html_handling": "none",
"not_found_handling": "none"
},
"vars": {
"MODE": "production",
"ORIGIN_BASE": "https://example.com",
"ORIGIN_RESOLVE_OVERRIDE": "origin-bypass.example.com",
"ORIGIN_TIMEOUT_MS": "4500"
}
}Decisão origin-first e status
const FALLBACK_STATUSES = new Set([
500, 502, 503, 504, 520, 521, 522, 523, 524, 525, 526, 527
]);
try {
const origin = await fetch(originRequest, {
signal: AbortSignal.timeout(4500),
redirect: "manual",
cf: { resolveOverride: "origin-bypass.example.com" }
});
if (!FALLBACK_STATUSES.has(origin.status)) return origin;
return serveSnapshot(request, origin.status);
} catch {
return serveSnapshot(request);
}503 honesto para escrita
if (!new Set(["GET", "HEAD"]).has(request.method)) {
return new Response("Temporarily unavailable", {
status: 503,
headers: {
"Retry-After": "300",
"Cache-Control": "no-store",
"Content-Type": "text/plain; charset=utf-8"
}
});
}Build, staging, ativação e rollback
# Build from rendered production and validate the package
python scripts/build_snapshot.py
npm run types
npm run check
npx wrangler deploy --env staging --dry-run
# Deploy and test the private preview (use your own secret securely)
npx wrangler deploy --env staging
python scripts/smoke_staging.py --base "https://<private-preview>" --password "<secret>"
# Inspect, activate, or remove only the owned routes
python scripts/manage_routes.py status
python scripts/manage_routes.py activate --confirm ACTIVATE-KBT-FALLBACK
python scripts/manage_routes.py deactivate --confirm REMOVE-KBT-FALLBACKPlano de testes: provar falha, passagem e recuperação
Teste home, ferramenta, CSS/JS, artigo, árabe RTL, locale longo, robots, path ausente, HEAD, POST, redirect www e temas mobile.
Snapshot: header, canonical, H1, JSON-LD, assets, aviso. Origin preview: sem loop. Produção saudável: sem header fallback e resposta intacta.
Nunca derrube a origem pública. Use preview/origem de teste e registre data do snapshot e hash do manifesto.
Rollback, monitoramento e recuperação
Rollback imediato remove só as rotas próprias, não DNS nem Worker. Verifique apex/www e purgue apenas HTML antigo.
Monitore headers, origem, logs, páginas e 503. A primeira resposta saudável volta automaticamente. Depois confirme estabilidade, revogue direitos, arquive métricas e atualize a cópia.
Duas armadilhas: recursão da zona e limite grátis
Um Worker em keyboardtester.click/* não deve buscar ingenuamente o mesmo host público. Usamos resolveOverride com um hostname DNS-only existente na mesma zona, direcionando a resolução à origem e preservando URL e Host canônicos. Endereço da origem e bypass devem ficar privados.
O Free permite atualmente 100.000 requests Worker/dia, 20.000 arquivos estáticos/versão e 25 MiB/arquivo. Nossos 2.749 cabem. As rotas são fail-open: ao esgotar a cota, Cloudflare ignora o Worker e vai à HostArmada em vez de Error 1027. Serve para disponibilidade, não para controle de segurança.
SEO, anúncios e analytics no fallback
Páginas existentes retornam 200 nas URLs originais com canonical, schema e links; escritas indisponíveis recebem 503. Não há domínio espelho público nem novas URLs para enviar.
Staging tem senha, robots bloqueado, noindex e sem medição. Só o HTML de fallback em produção recebe GA4 e AdSense adiados e Clarity na home. Respostas saudáveis não mudam. Medição e possível entrega de anúncios continuam, mas preenchimento e receita não são garantidos.
We did not submit fallback URLs to search engines because there are no new public URLs. The continuity layer sits behind the same addresses Google already knows.
A injeção de produção segue o live: GA4 após interação ou 2 segundos de load, AdSense após interação ou 15 segundos e Clarity só na home após interação ou 12 segundos. HTMLRewriter em streaming altera apenas HTML GET de fallback, nunca HEAD, CSS, JS ou imagens.
Limites e quando usar outra solução
Formulários, IA do servidor, e-mail, gravações no banco, sessões e envios salvos ficam offline sem a origem. Uma ferramenta de navegador funciona apenas se todos os arquivos necessários estiverem copiados.
O snapshot envelhece; atualize depois de mudanças importantes e teste a recuperação. Um produto transacional ou de muita escrita precisa de aplicação e banco replicados.
Para um site de conteúdo em hospedagem compartilhada com muitas ferramentas client-side, funcionou bem: sem divisão de dados, corte manual ou domínio duplicado e com degradação clara. Reduz a queda visível, não elimina toda dependência.
Fontes primárias e evidência direta
Os números vêm de manifestos e verificações de deploy/rotas de 17–18 de julho de 2026. O comportamento e os limites seguem a documentação primária vinculada.
- Cloudflare Workers: Static Assets
- Cloudflare Workers: Platform Limits
- Cloudflare Workers Request API
- Cloudflare Workers Routes API
- RFC 9110: HTTP Semantics
- HostArmada support correspondence, July 16–17, 2026
Perguntas frequentes
- Isso torna a hospedagem realmente sem downtime?
Não. A cópia de leitura fica disponível, mas formulários, escrita, e-mail, IA e sessões precisam da origem.
- Preciso mudar o DNS na queda?
Não neste padrão permanente. O Worker testa cada pedido e retorna automaticamente.
- O Google vê uma página de manutenção em toda URL?
Não. Páginas copiadas seguem 200 com canonical/schema; ações indisponíveis recebem 503 temporário.
- Por que não migrar toda a conta temporariamente?
Mover e devolver pode acrescentar riscos de sincronização de DNS, arquivos, e-mail e banco.
- Por que usar resolveOverride?
Para o Worker não chamar a própria rota. A resolução usa outro host da mesma zona e mantém URL/Host canônicos.
- O que ocorre no limite grátis?
Fail-open ignora o Worker e vai à origem. O fallback some se a origem cair, mas não aparece outro erro de cota.
- Quando atualizar o snapshot?
Após mudanças relevantes e antes de manutenção, testando falha e recuperação.
A lição não é pôr tudo atrás de um Worker: escolha a menor camada adequada, teste em privado, seja claro sobre os limites e automatize a recuperação.
