Fly.io: migração sem atrito real na rotina técnica

Depois de rodar cargas conteinerizadas em nuvens tradicionais por anos, a pergunta que ficou foi simples: Fly.io entrega resultado em arquitetura e integrações para quem precisa de infraestrutura de verdade e não de mais uma camada em cima da AWS? Na nossa experiência, sim. Migramos sem atrito, os contêineres KVM sobem rápido o bastante para atender requisições HTTP nativas e a malha privada em WireGuard resolveu a autenticação interna sem uma linha de Terraform. Por que a migração dos nossos contêineres para o Fly.io foi sem atrito A nossa carga era formada por serviços em contêineres que conversavam entre si o tempo todo: uma API interna, workers de fila e um serviço de autenticação. Em provedores tradicionais, boa parte do trabalho é traduzir essa arquitetura para YAML, e qualquer mudança de rota vira um ciclo de apply e espera. No Fly.io, o deploy é orientado por CLI e o resultado aparece em segundos, com build e rollout no mesmo comando. A sensação de atrito zero veio justamente daí: não houve reescrita de manifesto, não houve adaptação de imagem e nenhum serviço ficou pendurado em estado inconsistente depois do primeiro push.

O ponto que mais nos surpreendeu foi a velocidade de inicialização. Como a base é containerização com virtualização de hardware em KVM, a instância sobe rápida o suficiente para receber tráfego HTTP imediatamente, sem aquele aquecimento demorado que costuma exigir um balanceador intermediário. Para nós isso simplificou o desenho, porque o próprio app absorve as requisições que chegam. Também pesou a nosso favor saber que por baixo não existe apenas um wrapper de API sobre a AWS, e sim uma operação com hardware próprio, o que deixa o comportamento previsível quando a demanda sobe de forma abrupta e ninguém quer descobrir limite escondido no meio de um pico. Rede privada em WireGuard sem precisar de Terraform A malha privada foi o recurso que mais economizou tempo da equipe. Os túneis em WireGuard funcionam desde a primeira configuração, sem etapa extra de provisionamento, e a comunicação entre os serviços internos passa a ser autenticada pela própria rede. Isso eliminou boa parte das configurações de Terraform que a gente mantinha só para garantir que um serviço confiasse no outro, aquele bloco gigante de variáveis que ninguém queria revisar durante a revisão de código.

Na prática, o efeito foi reduzir superfície de erro. Quando um serviço novo entra, ele já nasce dentro da malha e conversa com os vizinhos pelo endereço interno, sem chave compartilhada escrita à mão e sem abrir porta pública apenas para testar integração. Perdemos menos tempo depurando problema de permissão entre contêineres e mais tempo olhando métrica de aplicação. Para quem já sofreu com configuração de cluster quebrada depois de um upgrade, essa parte do Fly.io é a que dá mais tranquilidade operacional e a que a gente cita primeiro quando alguém pergunta como é a rotina de manutenção. O que a documentação enxuta e os Sprites mudam no dia a dia A crítica que fazemos é honesta: a documentação oficial é minimalista. Ela cobre o caminho feliz com competência, mas quando o assunto é roteamento de borda com regra específica, a resposta costuma estar em tópico de fórum da comunidade, escrito por outro usuário, e não no guia principal. Já perdemos algumas horas caçando um detalhe de encaminhamento que deveria estar em uma nota de rodapé. Isso não chega a ser bloqueio, só exige disposição para garimpar e para testar por conta própria antes de subir qualquer alteração mais sensível.

Do outro lado, a parte nova compensa. O recurso Sprites, de sandboxing, executa checkpoint de ambiente em menos de um segundo. Para nós, isso abriu espaço para rodar teste de integração em ambiente isolado e retomar estado quase instantaneamente, sem esperar provisionamento nem manter máquina ligada só para validar uma hipótese. Somado a um CLI que se mostrou firme em todos os deploys do período, o que inclui rollback tranquilo e log legível na saída do terminal, o saldo é de uma plataforma em que a gente confia para produção, desde que aceite ler fórum quando o caso sair do comum.

Ficamos com quatro estrelas de cinco, e não é meia nota por acaso. Quando alguém pergunta se O Fly.io se destaca em arquitetura e integrações, respondemos que sim: entrega infraestrutura sólida, deploy rápido, rede privada que funciona e um CLI que não nos deixou na mão. O que pesa contra é a documentação econômica demais em casos de borda. Se o seu time tem mão técnica para investigar sozinho, a migração tende a ser tão sem atrito quanto foi para nós.