- Mesmo com resultados fortes, a identidade do negócio estava abalada, e a Fly.io levantou mais capital, colocou o ex-CEO do Docker Scott Johnston no comando e passou a fazer dos Sprites o negócio principal
- Com a IA permitindo que qualquer pessoa crie software sob medida, ficou mais difícil se diferenciar apenas com uma nuvem pública implantada perto do usuário e uma experiência pensada para desenvolvedores humanos
- Sprites são computadores para agentes que podem ser criados aos centenas ou milhares quando necessário e mantidos por longos períodos, cada um com disco persistente de 100GB e cobrança por uso que para quando ficam ociosos
- Os novos Sprites adicionam o Sprite Block Device, mais rápido e confiável, além de fork de disco e Connectors para chamar sistemas externos sem expor credenciais
- A Fly.io decidiu não perseguir ao mesmo tempo uma plataforma de aplicações de funções fixas projetadas por humanos e um futuro centrado em agentes, focando no segundo caminho, mas mantendo Fly Machines e os recursos PaaS existentes
Crise de identidade exposta em meio a resultados fortes
- Theo Browne avaliou o melhor lugar para hospedar novas aplicações em 2026 e falou de forma positiva sobre a Fly.io, mas disse que era o provedor entre os que acompanha sobre o qual tinha menos confiança de que continuaria existindo até o fim do ano
- Na época, a Fly.io vinha registrando fortes resultados trimestrais, incluindo o melhor desempenho financeiro de sua história, mas a questão de identidade sobre o que construir e para onde ir seguia sem solução
- A Fly.io levantou uma quantia significativa de capital adicional, lançou uma nova versão do Sprites para concentrar as capacidades da empresa e nomeou Scott Johnston como CEO
As premissas do product-market fit anterior mudaram
- A Fly.io partiu de dois princípios
- Aplicações de internet ficam mais rápidas quanto mais perto dos usuários são implantadas
- Em vez de infraestrutura complexa de nuvem, os desenvolvedores deveriam ter a flexibilidade da AWS junto com a usabilidade do Heroku
- Os dois princípios continuam importantes, mas deixaram de ser tão decisivos quanto antes à medida que a IA transforma o desenvolvimento de software
- Tratar agentes de código apenas como compiladores mais inteligentes integrados ao processo de desenvolvimento existente não captura bem a dimensão da mudança
- Antes do surgimento das planilhas, até tarefas equivalentes aos documentos do Excel de hoje precisavam ser programas feitos por programadores, mas as fórmulas de planilha transformaram inúmeros profissionais de negócios em programadores
- A IA provoca uma mudança ainda maior, caminhando para um cenário em que quase qualquer pessoa poderá criar quase qualquer tipo de programa
- A nuvem pública tradicional foi projetada para implantar aplicações de função fixa, submetidas a padrões rígidos e processos de CI/CD, para milhões de pessoas
- Ainda existirão programas para milhões de usuários, mas eles talvez não sejam a forma dominante, assim como não faz sentido imaginar planilhas vistas por milhões de leitores como o padrão comum
- Continuar apostando no desenho de nuvem pública de 2020 é como apostar contra a disseminação de software personalizado e adaptável
- A Fly.io escolhe um mundo em que amigos e familiares possam usar computadores para fazer diretamente o que desejam, sem esperar por desenvolvedores
As necessidades dos agentes acima da experiência de desenvolvedores humanos
- O problema de que infraestrutura de nuvem é difícil para desenvolvedores continua existindo, mas, à medida que agentes assumem o trabalho, a importância de uma experiência cuidadosamente desenhada para humanos diminui
- Para agentes que funcionam melhor em ambientes explícitos, padrões opinativos e uma experiência de desenvolvimento selecionada a dedo podem até ser uma desvantagem
- Em vez de ler documentação e aprender uma nova CLI por tentativa e erro, as pessoas começam a delegar isso aos agentes
- Um agente pode atender de uma vez o pedido para implantar na Fly.io um site feito localmente, mas também pode fazer um deploy na AWS de uma vez, então ficou mais difícil se diferenciar apenas por usabilidade
- Depois de observar que seus clientes de crescimento mais rápido eram robôs, a Fly.io passou a buscar o ambiente que os agentes realmente querem, em vez de reinterpretar seus produtos existentes para agentes
O computador que os agentes querem
- Agentes de código são, em essência, feitos para rodar em workstations de desenvolvedores
- Mesmo num sandbox confiável, se ele roda num notebook físico, o trabalho para no instante em que a tampa é fechada, então os usuários acabam migrando esses sandboxes de agentes para a nuvem
- Servidores tradicionais de nuvem pública exigem compromissos grandes demais para o trabalho de agentes
- Eles precisam ser mais efêmeros do que os servidores tradicionais do tipo pet ou cattle
- Devem poder ser criados no momento desejado, mantidos só pelo tempo necessário e operados a baixo custo
- Sprites são computadores semiefêmeros moldados para essas exigências
- Podem ser criados rapidamente aos centenas ou milhares
- Cada Sprite oferece um disco persistente de 100GB
- A cobrança é por uso, mas a medição para quando não há trabalho sendo feito, com ociosiade detectada pelo próprio sistema
- Podem hospedar aplicações e ser compartilhados com colegas pela internet
- A indústria está focada em sandboxes, mas o que os agentes precisam não é de sandbox, e sim de um computador com persistência e utilidade
- É possível criar Sprites imediatamente para usar diretamente
Tornando Sprites o centro da empresa
- Os primeiros Sprites eram um projeto criado por uma pequena equipe informal interna da Fly.io e nem sequer eram hospedados no site principal da empresa
- Daqui em diante, Computers for Agents passa a ser o foco central da empresa, e Sprites deixa de ser um projeto tocado por poucas pessoas
- Fly Machines e os recursos existentes da plataforma como serviço (PaaS) não serão descontinuados e continuarão disponíveis
- Os novos Sprites melhoram escala e orquestração e introduzem dois subsistemas importantes para completar a composição de funcionalidades pretendida
Sprite Block Device e fork de disco
- A pilha de storage anterior havia sido construída sobre JuiceFS, com Litestream acoplado
- O Sprite Block Device (SBD), reconstruído do zero por Ben Johnson e Tim Newsham, é mais rápido e confiável do que antes e mantém recursos imediatos de checkpoint e restore
- Com o fork de drive, uma extensão central do SBD, é possível criar um Sprite de template e então cloná-lo de forma eficiente milhões de vezes
Connectors para evitar exposição de credenciais
- Connectors se baseiam nos tokens tokenizados desenvolvidos para proteger a plataforma central da Fly.io
- Foram projetados para que um Sprite envie requisições autenticadas a outros sistemas sem entregar ao agente credenciais que poderiam vazar
- São mais convenientes do que o gerenciamento manual de contas e chaves de API
- A capacidade de clonagem do SBD e os Connectors eram os recursos mais pedidos pelos clientes e também a razão pela qual muitas empresas de agentes continuaram usando Fly Machines mesmo após o lançamento de um produto dedicado a agentes
- A Fly.io concluiu que, a menos que surja uma mudança tecnológica ainda mais estranha que os modelos Transformer, Sprites se encaixa tanto em clientes futuros quanto em boa parte dos clientes atuais, e por isso oferece uma nova beta
A saída do CEO fundador
- Durante os primeiros oito anos da fundação, a Fly.io operou como uma organização experimental em busca de product-market fit
- Tentou dezenas de coisas, incluindo Postgres não gerenciado, CDN global e WireGuard em modo de usuário
- Criou uma organização de engenharia bottom-up, evitou roadmaps de produto e montou uma equipe totalmente remota trabalhando em mais de 12 países
- Alguns experimentos deram resultado e outros serviram como oportunidade de aprendizado, mas a Fly.io neste estágio já não precisa mais desse tipo de projeto científico
- O fundador concluiu que já havia esgotado a maior parte do que podia oferecer como CEO e decidiu deixar o cargo
Scott Johnston assume como CEO
- Ao longo de vários meses, desde 2025, foi discutida a possibilidade de entregar a Scott Johnston a tomada de decisões da Fly.io
- Quando foi CEO do Docker, Scott liderou um período difícil iniciado por uma crise de identidade entre o mercado corporativo e o mercado de desenvolvedores, e depois expandiu fortemente o negócio
- O fundador, então CEO e acionista da Fly.io, entendeu que o estilo operacional de Scott era mais adequado ao estágio atual da empresa do que o seu próprio e, junto com o conselho, convenceu-o a assumir
- O fundador permanece como conselheiro e membro do conselho, participando das discussões de design de produto, enquanto Scott cuida da operação e execução do negócio
Capital adicional para a nova estratégia
- A Fly.io não anunciava nova captação havia anos, mas vinha operando próxima do ponto em que, pelos planos anteriores, não precisaria levantar mais recursos, graças a uma rodada grande feita antes
- Como a IA mudou esses planos, a empresa levantou capital adicional para executar a nova estratégia, sem divulgar valor ou condições específicas
- Scott Johnston pretende tratar separadamente dos detalhes de futuras captações
Escolher um entre dois futuros
- A Fly.io vê, para os próximos anos, agentes decidindo como quase todo software será construído e implantado
- O software ficará mais personalizado, terá públicos menores e assumirá formas mais flexíveis e fluidas
- Essa mudança gera expectativa, mas também desconforta quem trabalha no setor
- A empresa tinha duas opções
- Continuar expandindo e melhorando uma plataforma de aplicações full stack de funções fixas projetadas por humanos
- Refinar e completar um produto adequado ao futuro próximo centrado em agentes
- Como uma startup dificilmente consegue se concentrar o suficiente nas duas direções ao mesmo tempo, a Fly.io escolheu um produto centrado em agentes
- Após meses de prioridades adiadas, Sprites resolveu essa decisão, e Scott Johnston assume a missão de transformá-lo no negócio central da Fly.io
1 comentários
Comentários do Hacker News
A abstração do Sprites é bonita, mas em 30 anos de carreira em desenvolvimento nunca tinha visto um produto de infraestrutura com tantos bugs
Os dados sumiam com frequência e entravam em um estado zumbi impossível de conectar, e metade do sistema dizia que o Sprite estava normal enquanto a outra metade achava que estava morto, então nem sequer era possível carregar snapshots
O resultado do trabalho desaparecia entre o almoço e a volta, de um dia para o outro, e até durante o uso, então desisti depois de 2 semanas e tive que vasculhar o histórico do terminal para copiar e recuperar o trabalho de um Sprite morto
Parece que houve problemas em mais da metade dos Sprites que executei; a ideia é excelente, então espero que consigam garantir a estabilidade
Mas, nos últimos dois meses, parece ter ficado bem mais estável
Alguns anos atrás, o Fly.io também tinha tantos bugs que era difícil usar de forma prática, mas agora rodo algumas cargas de trabalho de produção com muita estabilidade, então achei que o Sprites seguiria o mesmo caminho, e de fato parece estar seguindo
Pelo tanto que o CEO administrou mal isso, talvez fosse até melhor ele renunciar
O motivo foram bugs graves de interface, perda de dados e suporte péssimo
Ainda assim, durante o teste eles não usaram o domínio real da empresa nem revelaram que era uma companhia da Fortune 200, então isso pode ter influenciado a qualidade do suporte
Como desenvolvedor Elixir, eu queria que o Fly.io desse certo, mas tive que sair duas vezes porque nunca encontrou equilíbrio entre engenharia brilhante e estabilidade operacional
Por um tempo, mesmo quando havia falhas globais, a página de status mostrava tudo como normal, e era preciso ler posts no fórum para descobrir o incidente; a empresa respondia que estava ocupada resolvendo o problema e não conseguiu atualizar o status
Depois começaram a atualizar a página de status, mas continuou acontecendo de, após um “incidente em uma região específica”, passarem horas sem qualquer notícia
Quando surgiu o suporte pago, assinei imediatamente, mas quase ninguém monitorava o endereço de e-mail que prometia resposta rápida, e mesmo ao reportar um incidente grande a resposta só vinha no dia seguinte ou dias depois com um “qual é o problema?”
Se isso fosse raro, seria apenas um problema de suporte ao cliente, mas durante um período houve incidentes sérios quase todo mês, parecia estabilizar por um tempo e depois voltava a desmoronar repetidamente
No fim, voltei tudo para self-hosting e, embora seja mais trabalhoso, o uptime melhorou muito e, quando há falha, eu mesmo consigo saber a causa, o que é bem menos doloroso
Se quiser continuar no negócio de hospedagem, precisa assumir responsabilidade e colocar orçamento em operações; caso contrário, é melhor parar com hospedagem e virar outro HashiCorp
Concentrar a empresa inteira em Sprites faz parecer que o Fly.io escolheu o suicídio
Sandboxes de IA já são um mercado altamente competitivo e praticamente comoditizado, e o novo CEO provavelmente vai focar em receita sacrificando uma visão criativa
Espero estar errado
Contêineres são descartáveis, é fácil reexecutar tarefas, então a preservação de dados importa menos, e também dá para fazer o agente subir o ambiente direto em bare metal
Como os agentes passam a maior parte do tempo esperando GPU, aplicar deduplicação de memória entre cargas semelhantes permitiria rodar centenas deles com pouco hardware
A AWS já é a nuvem dos agentes, e com agentes e infraestrutura como código (IaC) a complexidade da AWS também diminui bastante
Agora o valor não está em disputar orquestração ou alguns bps de margem de hardware na camada de serving de modelos, mas em criar ferramentas que ajudem os agentes a tomar decisões melhores
Com os avanços recentes dos LLMs, não só indivíduos, mas também empresas e organizações estão passando por uma crise de identidade, e este texto é um bom exemplo disso
Fica a dúvida se ainda vale a pena continuar construindo produtos ou empresas que a IA pode criar de uma vez só
Por outro lado, há também o efeito interessante de pressionar as pessoas a tentar coisas maiores e mais ambiciosas que antes eram impossíveis
Espero que mais gente entre em áreas como energia limpa, onde mesmo centenas de pessoas fazendo a mesma coisa ainda geram benefício líquido contínuo para a humanidade
Fico na dúvida se isso quer dizer que o Docker realmente fez o negócio explodir de crescimento, ou se quer dizer explodir no sentido de a porta sair voando, tipo Boeing
A avaliação relacionada de Bryan Cantrill também é interessante: https://news.ycombinator.com/item?id=28460504
O Sprites parece mais adequado para um negócio pequeno e estável tocado por alguns amigos do que para uma startup financiada por investidores
Para desenvolvedores, Docker ou Podman já resolvem muito bem
O enorme novo mercado em que até avôs e avós criam apps deve ficar com serviços como o Lovable, e é improvável que não desenvolvedores usem Sprites
No fim, só deve conquistar uma parte dos desenvolvedores existentes
Todo dia sai notícia de que OpenCode, Claude Code e afins são um desastre de segurança; se isolamento fosse tão fácil assim, fico me perguntando por que mais desenvolvedores não usam contêineres e por que esses incidentes continuam acontecendo
Evito coding com agentes porque não quero abrir o ambiente da minha casa para LLMs remotos de empresas só para escrever código mais rápido, mas claramente estou ficando para trás quando é preciso analisar vários arquivos-fonte ao mesmo tempo
Parece brusco sair logo depois de mudar a direção da empresa inteira para Sprites
No mínimo, deveria dar ao novo CEO a chance de definir a direção por conta própria e ter sua chance de provar isso
Fico na dúvida se vale apostar o futuro da empresa em Sprites, e a decisão final cabe ao novo CEO
No longo prazo, é bem possível que esse tipo de ambiente de execução isolado seja incorporado ao Claude Code ou ao Codex, ou oferecido diretamente por empresas de IA
O Git worktree resolve um problema parecido, mas com Sprites é possível subir instâncias rapidamente, executar serviços e depois entregar isso a um agente de código para melhorar funcionalidades
Dá para rodar vários agentes em paralelo e escolher um dos resultados, sem limitações de número de portas nem de CPU local
Considerando ainda que a falta de RAM deve continuar por um bom tempo, dá para rodar centenas de agentes em Sprites
O que o Fly.io precisa corrigir e priorizar é a confiabilidade
Eu gostava do jeito como o app já entrava em execução assim que o contêiner Docker subia, mas o serviço caiu várias vezes e o preço também era muito alto
Agora estou simplesmente usando um VPS