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 a utilidade da plataforma para o nosso site, não uma recomendação para ativar cada produto disponível. Minha preferência é adotar uma função de cada vez e registrar o que teria de mudar caso ela fosse substituída.

Direto ao ponto

Serviços da Cloudflare merecem entrar na stack quando resolvem uma necessidade identificada e o trabalho de saída continua compreensível. 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 registros, certificados, filtros e cache. Num componente que guarda arquivos ou cadastros, você também exporta o conteúdo, adapta o código e testa a aplicação no destino. O painel ativa os dois com poucos cliques, mas a segunda troca precisa transportar o que permaneceu no serviço.

Comece pelo percurso que já existe

Considere um site institucional gerado com Astro. O repositório preserva páginas, componentes e configuração do build. O Pages recebe o resultado e o publica. Se a hospedagem mudar, o código continua disponível, embora domínio, variáveis, redirecionamentos e configurações próprias do provedor precisem ser recriados.

Agora acrescente 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 ganhou conteúdo que não existe no Git. Uma nova publicação não pode apagar o documento, e uma troca de armazenamento precisa manter a associação entre o cliente e o arquivo autorizado.

Esse percurso revela o que cada produto acrescenta. Ele também impede que a arquitetura nasça da lista do painel. Se o site não recebe arquivos, não há motivo para incluir um bucket no desenho. Se uma página não executa lógica dinâmica, o frontend estático pode ser suficiente.

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. Escolha uma jornada curta e reproduza-a num ambiente separado. No formulário com anexo, envie um arquivo, transporte o objeto, importe o cadastro e abra o documento com a sessão autorizada. Depois tente acessá-lo com outro cliente.

Durante o ensaio, a biblioteca grava o objeto no R2 e falha numa segunda operação sem suporte equivalente 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 falha aponta a adaptação necessária no código ou na configuração.

Para uma camada de entrada, o ensaio precisa observar o comportamento depois da resolução do domínio. Reproduza os registros, prepare o certificado e confira redirecionamentos, cabeçalhos, filtros do WAF e conteúdo armazenado em cache. Uma página abrir no navegador é a primeira parte dessa verificação.

Mantenha o banco acessível por outro caminho

O Hyperdrive mantém conexões reutilizáveis com um PostgreSQL ou MySQL externo. O banco continua na hospedagem escolhida, enquanto o Worker usa o pool da Cloudflare para reduzir o custo de abrir conexões pela rede. Retirar o Hyperdrive preserva o banco, mas muda credenciais, quantidade de conexões e tempo das consultas.

Essa composição oferece uma saída diferente de um banco integrado ao mesmo runtime. Acesso externo não significa migração pronta. Você precisa saber como o backend acessa o banco sem o pool e se a origem aceita essa carga. Região, suporte e recuperação 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, 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, escreva três informações no registro técnico: qual jornada usa o componente, qual conteúdo permanece nele e qual comportamento deve sobreviver a uma substituição. Em seguida, execute uma versão pequena da troca. Esse material vale mais que uma promessa genérica de portabilidade.

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, escreva a jornada atendida, o conteúdo que ficará nele e o teste de saída. Se essas três linhas não podem ser preenchidas, a barra lateral ainda apresentou uma possibilidade, não uma necessidade da aplicação.