- O ‘Sprites’ recém-lançado pela Fly.io apresenta o conceito de computadores em nuvem persistentes para substituir os sandboxes efêmeros tradicionais
- Pode ser criado em 1~2 segundos e oferece transição automática para modo ocioso, restauração por checkpoint e 100 GB de armazenamento durável
- Aponta que o modelo existente de contêineres sem estado é ineficiente para agentes de IA, como o Claude, e enfatiza a necessidade de um ambiente persistente
- Como caso real, apresenta a experiência de Claude construindo e operando por longo período um app em Go baseado em SQLite (MDM) sobre um Sprite
- Conclusão do texto: “A era dos sandboxes acabou, e a era dos computadores descartáveis chegou”
Sprites: computadores em nuvem persistentes - https://sprites.dev/
- A Fly.io afirma que o modelo tradicional de sandbox somente leitura está ultrapassado e apresentou o ‘Sprite’ como substituto
- Com o comando
sprite create, um shell root Linux é criado em 1 segundo
- O Sprite conta com 100 GB de armazenamento durável e pode entrar automaticamente em modo de economia quando ocioso, sendo restaurado depois
- Com
sprite-env checkpoints create, é possível criar instantaneamente um checkpoint do sistema inteiro
- Com
sprite checkpoint restore v1, a restauração acontece em 1 segundo, permitindo controle de versão em nível de sistema, como no Git
- Principais características
- Criação fácil de centenas de instâncias
- Pausa automática de cobrança (idle metering) para reduzir custos
- Conectividade de rede Anycast para fornecer URL HTTPS
- Durabilidade completa, mantida até exclusão explícita
Claude e os limites dos contêineres sem estado
- Hoje, a maioria dos ambientes de nuvem é centrada em contêineres stateless
- Os dados ficam armazenados apenas em bancos externos, com foco em simplicidade e escalabilidade
- Porém, agentes de IA como Claude não se encaixam bem nessa estrutura
- Eles tendem a tentar contornar ou escapar do contêiner e querem acesso ao “computador” inteiro
- O texto define “computador” pelos conceitos de durabilidade e de um ambiente que não desaparece após o trabalho
- Os sandboxes atuais carecem de ambos
A simplicidade vence (Simple Wins)
- Em um ambiente persistente, não é necessário reconstruir o ambiente de desenvolvimento (
node_modules, etc.)
- O setor investe dezenas de milhões de dólares em tecnologias de snapshot para resolver isso
- Há casos em que se monta infraestrutura real para permitir que agentes acessem recursos externos como S3, Redis e RDS
- Isso funciona como um paliativo para contornar a falta de persistência dos sandboxes
- O Sprite remove essa complexidade e oferece um ambiente em que, se você escreve um arquivo, ele continua lá
- Como exemplo, no projeto Phoenix.new, um agente baseado em Fly Machine observa diretamente os logs do app e corrige erros
Galaxy Brain Win: fusão entre desenvolvimento e operação
- O autor relata ter construído, junto com Claude, um app em Go baseado em SQLite (MDM) sobre um Sprite
- A URL Anycast foi usada como URL de registro do MDM
- Claude configurou automaticamente até o certificado APNS
- Esse app está funcionando de forma estável sobre um Sprite há mais de um mês
- Isso concretiza a ideia de que o ambiente de desenvolvimento é o ambiente de produção (dev is prod, prod is dev)
- O autor argumenta que a maioria dos apps não precisa de tráfego massivo e que apps persistentes personalizados para cada pessoa são mais importantes
- Em uma estrutura assim, o próprio usuário pode pedir recursos e vê-los implementados imediatamente
O fim dos sandboxes e a era dos computadores descartáveis
- A Fly.io vem desenvolvendo há muito tempo uma plataforma de micro-VMs com escala horizontal, mas o modelo de sandbox chegou ao limite
- O Sprite é semelhante ao Fly Machines, mas traz uma nova stack de armazenamento e uma nova estrutura de orquestração, além de não exigir Dockerfile
- Pergunta central levantada:
> “Se é possível executar um agente, você não preferiria uma instância EC2 invocável imediatamente a um sandbox somente leitura?”
- Conclusão: “A era dos sandboxes acabou, e a era dos computadores descartáveis chegou.”
1 comentários
Comentários do Hacker News
No começo eu gostei bastante, mas, como em outras experiências com a Fly API, aqui também pareceu meio quebrado
Se você executar exatamente o comando de exemplo da documentação em https://sprites.dev/api, a resposta é
{"error":"name is required"}Mas, se usar o corpo completo da requisição da documentação Create Sprite, funciona normalmente
Em um workflow pessoal dá para tolerar esse tipo de aresta mal acabada, mas eu hesitaria em colocar isso em CI/CD afetando o time inteiro
Eu queria pedir ao time da Fly que garantisse que os exemplos da documentação sejam validados com testes automatizados
https://sprites.dev/ é realmente muito interessante
Resolve de uma vez dois problemas de que eu gosto
Também tem recurso de snapshot, então é fácil voltar ao estado anterior depois de executar algo
Escrevi mais detalhes no meu blog → post no simonwillison.net
E fiquei feliz em ver que o Simon está tentando monetizar mais o próprio trabalho. Quanto mais ele ganhar, melhor o mundo fica
Filosoficamente eu gosto da Fly e sou cliente desde o começo
Mas ainda tenho receio de qualquer coisa ligada ao CLI. Mesmo usando só uma vez a cada poucas semanas, ele tenta se atualizar automaticamente com frequência demais e quebra meu fluxo
Fico preocupado se o Sprite CLI vai repetir o mesmo problema
Isso é muito interessante!
Na empresa usamos um servidor de desenvolvimento persistente com o Claude conectado via SSH, e é inconveniente quando o repositório git ou o ambiente desaparecem
Parece que o Sprite permitiria salvar dados com algo como SQLite e criar apps simples acessíveis por URL
Se a estrutura expira automaticamente depois de pouco tempo, isso parece perfeito para software pessoal simples
Seria ainda melhor se houvesse algo como os ambientes de preview da Vercel, onde você pudesse ver a URL após autenticar com a conta da Fly
Parece legal, mas os outros produtos da Fly não são exatamente exemplo em estabilidade ou acabamento
Há muito downtime de API e erros transitórios, e os problemas de cobrança demoram a ser resolvidos
Por exemplo, instâncias já apagadas ainda aparecem como em uso, e a cobrança por hora é calculada como o dobro do valor real
Eles lançaram novos produtos de IA, como Phoenix.new e Sprites, mas parecem mais focados em novidade do que em melhorar a qualidade do que já existe
Eu queria algo assim para sandboxes de desenvolvimento — um ambiente que não custe caro mesmo se eu esquecer de encerrar
Mas tive alguns problemas
manpath: can't set the locale— provavelmente a configuração de locale da minha máquina local foi repassada como estava$SHELLestava definido como/opt/homebrew/bin/fish. Fiquei um pouco desconfortável com a impressão de que variáveis de ambiente locais foram enviadas sem autorização para o remotoIsso é realmente muito legal. É o tipo de ambiente de execução em sandbox com DX e API que eu estava esperando
Eu gostaria de poder customizar a imagem base ou a VM para incluir só os binários de que preciso, sem ferramentas desnecessárias
Ou então ter um recurso para clonar sprites com base em checkpoints. No momento não vejo essa opção
Foi muito divertido trabalhar em Sprites nos últimos meses
Em breve vamos abrir como código aberto parte do lado em Elixir
Também há um vídeo de demonstração de 5 minutos → demo no YouTube
Sprites não usados quase não custam nada. Sempre que surge uma tarefa nova, você pode simplesmente criar outro
É uma sensação curiosa ter um ambiente que pode ser executado a qualquer momento, sem precisar decidir nada antes
Como o domínio é fly.io, de início achei que seria uma solução local
Mesmo que não fosse self-hosted, eu esperava algo como um wrapper de VM local em cima de Docker ou bubblewrap
Rodar o IncusOS baseado em ZFS em hardware local cria um ambiente de sandbox extremamente poderoso
Talvez eu tenha deixado passar isso na documentação, mas queria saber se dá para fazer fork/clone de sprites ou restaurar um checkpoint como um novo sprite
Por exemplo, usar um sprite como template para subir vários, ou deixar o Claude Code explorar várias soluções e depois manter só uma e limpar o resto
A ideia era incluir isso no lançamento, mas decidiram juntar um pouco mais de dados de uso real primeiro