Fly.io: desempenho bom, falhas de deploy e erros inúteis

A latência de resposta HTTP do Fly.io é, de fato, muito boa, e o free tier voltou a existir depois que o Heroku encerrou o dele. Só que isso não segurou minha operação: no primeiro dia meus servidores não subiram por problemas de plataforma, e em três dias tive falhas de deploy duas vezes, com mensagens de erro que não ajudam em nada na hora de diagnosticar. Fiquei no limite da paciência antes de decidir parar.

Deploy travado e mensagens de erro que não diagnosticam nada

Meus servidores simplesmente não subiram no primeiro dia de uso. Ao abrir o site de suporte, encontrei vários outros usuários com o mesmo sintoma, e a origem era a própria plataforma, não o meu código. Isso já muda o cálculo: quando o problema está no fornecedor, não adianta revisar configuração nem variáveis de ambiente, você apenas espera e torce.

Hoje passei pela mesma situação outra vez. Em três dias, duas falhas de deploy, o que na prática significa que boa parte da minha janela de trabalho virou tentativa e erro sem retorno. Fui para o fórum e encontrei gente tentando diagnosticar exatamente o mesmo comportamento sem sucesso. As mensagens de erro não entregam nada de útil, então não existe por onde começar a investigar.

Diagnóstico ruim custa tempo dobrado, porque você testa hipóteses que não têm relação nenhuma com a causa real. Sem uma mensagem que aponte o mínimo de direção, cada tentativa vira chute, e é justamente aí que a confiança no serviço começa a quebrar para quem depende dele para colocar aplicação no ar.

Da mudança de IP dedicado para compartilhado nos deploys

Enquanto eu lidava com os deploys travados, li no fórum relatos de outros clientes sobre a troca de padrão nos endereços IP, que passaram de dedicados para compartilhados. Segundo esses relatos, a mudança quebrou deployments que já estavam rodando e chegou a custar negócios a quem dependia daquela configuração para atender clientes.

Esse é o tipo de detalhe que pesa mais do que a latência. Um endereço compartilhado muda o comportamento de tudo que aponta para o serviço, e quem não foi avisado com clareza descobre o problema só quando algo para de responder. Para quem usa o Fly.io como ambiente de produção, revisar o padrão de IP antes de publicar deixa de ser um cuidado opcional e vira etapa obrigatória.

O ponto incômodo é que essa decisão não parte de quem está operando. Ela vem de cima, como mudança de configuração padrão, e o usuário fica responsável por descobrir o impacto sozinho. A latência de resposta HTTP continua boa, admito, mas latência baixa não resolve nada quando o serviço que deveria responder está fora do ar por causa de um padrão alterado sem alarde suficiente.

Builder deletado por engano e organização travada

Um dos relatos do fórum deixou claro o tamanho da fragilidade. Um usuário contou que, tentando consertar o deploy, acabou deletando um builder e com isso travou a própria organização inteira. Ou seja, a busca por uma solução simples virou um problema estrutural, e sem mensagens de erro decentes é fácil tomar esse tipo de decisão no escuro.

Esse caso ilustra bem o que acontece quando o diagnóstico é fraco. A pessoa começa tentando resolver um deploy que não sobe, mexe em componentes que parecem descartáveis e descobre tarde demais que eles sustentavam a configuração toda. Se o erro tivesse apontado a causa desde o começo, ninguém precisaria desmontar nada para tentar enxergar o que estava acontecendo.

Para mim, foi o sinal de que eu não queria estar ali quando o meu próprio ambiente passasse por isso. Serviço barato é ótimo até o momento em que você precisa confiar que a plataforma não vai te deixar no meio do caminho sem explicação. O free tier e a latência continuam atraentes, mas a estabilidade operacional não acompanha esse conjunto.

Depois de duas falhas de deploy em três dias, desisti. Não cheguei a investir tanto a ponto de a mudança ser um transtorno, então optei por não continuar e seguir com o que já estava funcionando. Espero sinceramente que o Fly.io melhore e que isso seja só um momento turbulento de crescimento, porque a proposta é boa e o free tier que voltou a existir tem valor real. Mas antes de colocar qualquer coisa em produção, vale ler as postagens recentes do fórum de suporte e confirmar com os próprios olhos se as coisas mudaram.