Fly.io em produção: dashboard instável e erros de deploy

Rodei minhas aplicações no Fly.io e a conclusão é direta: a plataforma não é estável. Os erros de deploy se acumulam, o dashboard administrativo devolve erro 500 de forma aleatória e os atrasos na publicação aparecem sem qualquer explicação. Já movi meu primeiro app para o Vercel e estou a caminho de migrar o segundo. Quando o assunto é produção, a instabilidade do Fly.io pesa muito mais do que qualquer facilidade oferecida.

Erros 500 no dashboard de administração do Fly.io

O que mais me incomodou não foi o deploy em si, mas o painel de administração do Fly.io. Em momentos aleatórios, sem nenhuma ação incomum da minha parte, o dashboard simplesmente devolvia erro 500. Não era uma tela que eu abria por curiosidade: era o painel de onde acompanho os apps, então cada falha interrompia a verificação de status e me obrigava a recarregar e esperar de novo.

O detalhe que mais pesa é a palavra aleatório. Se o erro aparecesse sempre no mesmo fluxo, eu conseguiria contornar com um caminho alternativo. Como ele surge do nada, nunca sei se o problema está na minha configuração ou na própria plataforma, e essa dúvida consome tempo que eu não tenho. Em ambiente de produção, painel instável significa menos visibilidade justamente quando você mais precisa dele.

Também é difícil justificar para quem depende do meu trabalho que o painel administrativo do provedor falha sozinho. A confiança na plataforma cai antes mesmo do primeiro deploy do dia, e isso contamina toda a relação com a ferramenta.

Atrasos sem explicação a cada publicação

Além do painel, os deploys do Fly.io me deram muitos erros e, quando não davam erro, davam espera. Publicar uma alteração deveria ser o momento mais previsível de todo o fluxo, mas virava uma roleta: às vezes concluía, às vezes travava sem mensagem clara, às vezes demorava bem mais do que o razoável, sem nenhuma explicação do motivo.

Eu não me importo com espera quando sei a causa. O problema é a ausência de causa. Sem retorno claro, o único caminho é tentar de novo, e repetir deploy em cima de um estado incerto é exatamente o tipo de coisa que ninguém quer fazer perto de produção. Cada tentativa extra vira tempo perdido e risco desnecessário, e o acúmulo disso ao longo da semana destrói qualquer planejamento.

Some a quantidade de erros de deploy com os atrasos aleatórios e o resultado é uma rotina imprevisível. A plataforma não entrega o básico: saber se a publicação vai concluir e por qual motivo falhou quando não conclui.

Migração para o Vercel e o veredito sobre produção

Depois de acumular esse tipo de problema, decidi mover o primeiro app para o Vercel, e a diferença apareceu na previsibilidade. A troca não foi por preferência de marca nem por comparação de recursos, foi por necessidade de parar de gastar tempo com falhas que eu não consigo diagnosticar sozinho.

Estou no processo de mover o segundo app também. A decisão não é impulsiva: é o resultado de um padrão que se repetiu nos deploys, no dashboard e na falta de explicação para os atrasos. Quando o mesmo tipo de instabilidade volta várias vezes, deixa de ser incidente isolado e passa a ser característica da plataforma.

Por isso, minha posição é clara: o Fly.io não é estável e não está pronto para produção no meu caso de uso. Para projetos em que uma publicação travada não custa nada, talvez a experiência seja tolerável. Para mim, com aplicações rodando em produção, a conta não fecha.

Continuo acompanhando o que a plataforma oferece, mas a experiência concreta pesou mais do que a proposta. Erro 500 no dashboard, erros de deploy e atrasos sem explicação formam um conjunto que corrói a confiança. Se você depende de publicações previsíveis e de um painel que responda, vale considerar alternativas antes de colocar seus apps em produção aqui.