Você entra na Cloudflare para configurar o DNS (Domain Name System) e encontra serviços capazes de publicar o site, executar código e guardar arquivos. A barra lateral coloca todas as opções próximas. A arquitetura só precisa daquelas que participam de uma jornada identificada na aplicação.

Eu uso o Cloudflare Pages para publicar o site da Promovaweb em Astro. Essa experiência confirma que a plataforma atende à nossa publicação. Nos outros componentes, prefiro adotar uma função de cada vez e registrar o que precisarei alterar para substituí-la.

Direto ao ponto

Os serviços da Cloudflare fazem sentido na stack quando atendem a uma necessidade e você sabe como substituí-los. DNS, CDN (Content Delivery Network) e WAF (Web Application Firewall) alteram o caminho do tráfego. Publicação e código podem ser reconstruídos a partir do repositório, enquanto arquivos, tabelas, mensagens e vetores exigem transporte ou recriação.

Trocar uma camada de entrada exige reproduzir a resolução do domínio e o certificado usado na conexão. Você também precisa conferir os filtros de requisição e o comportamento do cache. Num serviço que guarda arquivos ou cadastros, a troca inclui transportar o conteúdo e testar o código no destino.

Comece pelo percurso que já existe

Num site institucional gerado com Astro, o repositório preserva o código e a configuração do build, enquanto o Pages publica o resultado. Se a hospedagem mudar, esses arquivos continuam disponíveis, mas domínio e configurações específicas do provedor precisam ser recriados.

Quando você acrescenta um formulário com anexo, o navegador envia campos para uma função, o arquivo segue para um bucket e o cadastro recebe um identificador. A aplicação ganha conteúdo que não existe no Git e precisa permanecer após uma nova publicação. Durante a troca de armazenamento, você também precisa manter a associação entre o cliente e o arquivo autorizado. O percurso está desenvolvido em Pages, Workers, R2 e Hyperdrive na mesma aplicação.

Esse percurso permite comparar as opções do painel com as funções usadas pela aplicação. Um site sem upload pode precisar de um bucket para publicar arquivos existentes, mas um frontend estático sem anexos ou lógica dinâmica pode funcionar apenas com a publicação do build. A necessidade de armazenamento deve aparecer no conteúdo que você pretende servir.

Separe configuração, código e conteúdo persistente

Um binding fornece um serviço ao Worker por uma variável do ambiente. O código pode chamar env.BUCKET sem enviar uma credencial do R2 ao navegador. A integração reduz configuração manual, mas também liga aquela função à interface oferecida pelo runtime.

Antes de adotar o binding, localize os trechos que o chamam. Concentre o acesso ao armazenamento numa função da aplicação para reduzir o alcance de uma futura adaptação. Chamadas diretas em cada rota espalham a substituição por mais arquivos e testes.

Para o conteúdo persistente, verifique se existe uma forma de exportá-lo e reconstruir suas relações. O R2 oferece uma API compatível com S3, com diferenças documentadas entre operações. Copiar objetos não preserva sozinho as permissões, os endereços públicos nem os identificadores gravados no banco.

O mesmo raciocínio vale para D1. O SQL baseado em SQLite facilita a leitura do schema e dos registros, enquanto chamadas feitas pelo binding continuam específicas do ambiente. Uma exportação bem-sucedida comprova que o conteúdo saiu. A aplicação só está pronta depois que consulta, gravação e autorização funcionam no destino.

Faça a troca em miniatura antes de depender do serviço

Um teste de saída não precisa migrar o sistema inteiro. Reproduza o formulário com anexo num ambiente separado: envie o arquivo e o cadastro, transporte o objeto ao destino e tente abrir o documento primeiro com a sessão autorizada e depois com outro cliente.

Durante o ensaio, uma biblioteca pode gravar o objeto no R2 e não oferecer suporte a outra operação necessária na API S3. O endereço assinado também pode mudar de formato, enquanto o cache continua servindo a versão anterior depois da troca do DNS. Cada diferença aponta a adaptação necessária no código ou na configuração.

Para uma camada de entrada, observe o comportamento depois da resolução do domínio. Copie os registros e prepare o certificado, depois envie requisições que exercitem redirecionamentos e filtros do WAF. Confira se os cabeçalhos esperados chegam e se o cache devolve o conteúdo atualizado.

Mantenha o banco acessível por outro caminho

O Hyperdrive mantém conexões reutilizáveis com um PostgreSQL ou MySQL externo e reduz o custo de abri-las pela rede. Ao retirar o serviço, o banco continua na hospedagem escolhida, mas o backend precisa substituir esse caminho de conexão. A alternativa pode usar outro pool compatível com o ambiente de execução.

Essa mudança altera as credenciais, a quantidade de conexões e o tempo das consultas. Confira se a origem aceita a carga esperada. Região, suporte e recuperação também entram na escolha do servidor, como detalho em como escolher um provedor de VPS.

Quando autenticação, arquivos e banco vêm de uma plataforma integrada, cada parte merece uma conferência própria. A comparação entre Supabase Cloud e self-hosted mostra por que transportar PostgreSQL não transporta automaticamente login e objetos do Storage.

Use a Cloudflare sem transformar o painel em arquitetura

Eu continuo recomendando a Cloudflare para funções que atendem uma necessidade real. No site da Promovaweb, o Pages resolve a publicação do resultado gerado pelo Astro e mantém o deploy relacionado ao repositório. Essa escolha tem uma função delimitada e uma forma conhecida de reconstrução.

Ao avaliar outro serviço, registre qual jornada usa o componente e que conteúdo permanece nele. Defina também o comportamento que precisa sobreviver a uma substituição e teste uma versão pequena da troca. No caso de IA, o artigo sobre AI Gateway, Vectorize e Agents acompanha a pergunta até os registros mantidos em cada componente. Você precisa reconstruir esse percurso para conferir a resposta depois de uma migração.

A Formação DevOps da Promovaweb desenvolve a base para publicar, observar e recuperar aplicações. Se a stack existente já mistura bindings, armazenamento e configurações próprias do provedor, o Diagnóstico de Produto e Arquitetura da Dev Side Studio relaciona cada integração à jornada principal e documenta o que precisa permanecer durante uma alteração.

Antes de ativar o próximo serviço, reproduza numa cópia da aplicação a ação que ele vai atender. Envie o documento, consulte o cadastro ou abra a resposta esperada. O comportamento que você precisa preservar durante uma substituição aparece nessa jornada e orienta a configuração do componente.