Sprites - sandbox avec état persistant

 (fly.io)
5 points par GN⁺ 2026-01-11 | 1 commentaires | Partager sur WhatsApp
  • Fly.io a récemment dévoilé « Sprites », un concept d’ordinateur cloud persistant destiné à remplacer les sandboxes éphémères existantes
  • Création possible en 1 à 2 secondes, avec mise en veille automatique en cas d’inactivité, restauration par checkpoint et 100 Go de stockage durable
  • L’entreprise souligne que le modèle de conteneurs sans état existant est inefficace pour les agents IA (ex. Claude) et insiste sur la nécessité d’un environnement persistant
  • Comme cas concret, elle présente l’expérience où Claude a construit et exploité sur la durée une application Go basée sur SQLite (MDM) sur un Sprite
  • Conclusion de l’article : « L’ère des sandboxes est terminée, celle des ordinateurs jetables a commencé »

Sprites : des ordinateurs cloud persistants - https://sprites.dev/

  • Fly.io affirme que le modèle traditionnel de sandbox en lecture seule est dépassé et a présenté « Sprite » pour le remplacer
    • La commande sprite create crée un shell root Linux en 1 seconde
    • Un Sprite dispose de 100 Go de stockage durable, passe automatiquement en mode économie d’énergie lorsqu’il est inactif, puis peut être restauré
  • Avec sprite-env checkpoints create, il est possible de créer instantanément un checkpoint de l’ensemble du système
    • sprite checkpoint restore v1 permet une restauration en 1 seconde, avec une gestion de versions du système entier comparable à Git
  • Principales caractéristiques
    • Création facile de centaines d’instances
    • Arrêt automatique de la facturation en période d’inactivité (Idle metering) pour réduire les coûts
    • Connectivité réseau Anycast avec URL HTTPS fournie
    • Durabilité complète, conservée jusqu’à suppression explicite
Publicité

Claude et les limites des conteneurs sans état

  • Aujourd’hui, la plupart des environnements cloud reposent sur une architecture centrée sur des conteneurs sans état (stateless)
    • Les données ne sont stockées que dans des bases externes, dans un objectif de simplicité et de montée en charge
  • Mais les agents IA comme Claude ne sont pas adaptés à cette architecture
    • Ils montrent des comportements cherchant à contourner ou à sortir du conteneur et veulent accéder à l’ordinateur dans son ensemble
  • L’auteur présente comme définition d’un ordinateur la durabilité et un environnement qui ne disparaît pas après le travail effectué
    • Les sandboxes actuelles manquent précisément de ces deux aspects

La simplicité l’emporte (Simple Wins)

  • Dans un environnement persistant, il devient inutile de reconstruire l’environnement de développement (node_modules, etc.)
    • L’industrie investit des dizaines de millions de dollars dans des technologies de snapshot pour résoudre ce problème
    Publicité
  • Il existe des cas où l’on met en place une véritable infrastructure pour permettre à un agent d’accéder à des ressources externes comme S3, Redis, RDS
    • Il s’agit d’un expédient pour contourner le problème de non-persistance des sandboxes
  • Sprites supprime cette complexité et fournit un environnement où les fichiers écrits restent en place
  • Exemple : dans le projet Phoenix.new, un agent basé sur Fly Machine observe directement les logs de l’application afin de corriger les erreurs

Galaxy Brain Win : fusion du développement et de l’exploitation

  • L’auteur a construit avec Claude une application Go basée sur SQLite (MDM) sur un Sprite
    • Elle a été utilisée comme URL d’inscription MDM via une URL Anycast
    • Claude a même automatisé la configuration du certificat APNS
  • Cette application fonctionne de manière stable sur un Sprite depuis plus d’un mois
    • Cela concrétise l’idée que « l’environnement de développement est l’environnement de production (dev is prod, prod is dev) »
    Publicité
  • L’auteur soutient que la plupart des applications n’ont pas besoin d’un trafic massif et que des applications persistantes personnalisées sont plus importantes
    • Une structure dans laquelle l’utilisateur peut demander directement des fonctionnalités et les voir intégrées immédiatement

La fin des sandboxes et l’ère des ordinateurs jetables

  • Fly.io développe depuis longtemps une plateforme de micro-VM à montée en charge horizontale, mais estime que le modèle de sandbox a atteint ses limites
  • Sprites ressemble à Fly Machines, mais avec une nouvelle pile de stockage et une nouvelle architecture d’orchestration, sans besoin de Dockerfile
  • Question centrale posée :

    « Si l’on peut exécuter un agent, ne voudrait-on pas plutôt une instance EC2 invocable immédiatement qu’une sandbox en lecture seule ? »

  • Conclusion : « L’ère des sandboxes est terminée, celle des ordinateurs jetables a commencé. »

À lire aussi

1 commentaires

 
GN⁺ 2026-01-11
Avis Hacker News

  • Au début, j’ai vraiment aimé, mais comme avec d’autres expériences autour de l’API Fly, ça m’a encore donné une impression de truc cassé
    Si on exécute telle quelle la commande d’exemple de la doc https://sprites.dev/api, on obtient {"error":"name is required"}
    En revanche, si on utilise le corps de requête complet de la doc Create Sprite, ça fonctionne normalement
    Pour un workflow perso, on peut tolérer ce genre d’angles morts, mais pour du CI/CD qui impacte toute une équipe, ça fait hésiter
    J’aimerais demander à l’équipe Fly de valider systématiquement les exemples de la documentation avec de l’automatisation de tests

    • C’est probablement parce que l’en-tête Content-Type n’est pas inclus
    • Ce serait bien de pouvoir signaler ce type de problème dans un issue tracker public. Pas forcément GitHub, mais il faut un espace où les utilisateurs peuvent en discuter publiquement

  • https://sprites.dev/ est vraiment intéressant
    Ça résout d’un coup deux problèmes que j’aime bien

    1. Sandbox d’environnement de développement — un environnement VM peu coûteux et persistant pour exécuter Claude Code ou Codex CLI en toute sécurité
    2. Sandbox API — permet d’exécuter du code non fiable dans un environnement isolé via un simple appel d’API JSON
      Il y a aussi des snapshots, donc on peut facilement revenir à l’état précédent après exécution
      J’ai détaillé ça sur mon blog → article sur simonwillison.net

  • Philosophiquement, j’aime bien Fly et j’en suis client depuis le début
    Mais tout ce qui touche au CLI me fait toujours un peu peur. Même si je ne l’utilise qu’une fois toutes les quelques semaines, les mises à jour automatiques tombent trop souvent et cassent mon flux
    J’ai peur que le CLI de Sprite répète le même problème

    • J’ai abandonné Fly pour la même raison et je suis passé chez Digital Ocean. Le “just works” ne marchait pas assez souvent

  • C’est vraiment intéressant !
    Dans l’entreprise, on utilise un serveur de développement persistant avec Claude connecté en SSH, et c’est pénible quand le dépôt git ou l’environnement disparaît
    Avec Sprite, on pourrait sans doute stocker les données dans quelque chose comme SQLite et créer une petite app accessible par URL
    Si la structure disparaît automatiquement après un court délai, ce serait parfait pour des petits logiciels personnels
    Ce serait encore mieux s’il y avait une fonction permettant de voir l’URL après authentification sur un compte Fly, un peu comme les environnements de preview Vercel

  • Ça a l’air cool, mais les autres produits de Fly ne sont pas exemplaires en matière de stabilité ou de finitions
    Il y a souvent des indisponibilités de l’API et des erreurs temporaires, et les problèmes de facturation sont lents à être résolus
    Par exemple, des instances supprimées apparaissent encore comme actives, et la facturation horaire est calculée au double du réel
    Ils ont lancé les nouveaux produits IA Phoenix.new et Sprites, mais donnent l’impression de se concentrer davantage sur les nouveautés que sur l’amélioration de la qualité des produits existants

    • Si on ne regarde que la fiabilité et le support, je ne vois pas de raison d’utiliser ça

  • Je voulais ce type de sandbox de développement — un environnement qui ne coûte pas cher même si on oublie de l’arrêter
    J’ai quand même eu quelques problèmes

    1. Erreur manpath: can't set the locale — visiblement, les réglages de locale de ma machine ont probablement été transmis tels quels
    2. $SHELL était défini sur /opt/homebrew/bin/fish. Le fait que des variables d’environnement locales aient été transmises sans autorisation m’a mis un peu mal à l’aise

  • C’est vraiment génial. C’est exactement le type d’environnement d’exécution sandbox avec DX et API que j’attendais
    J’aimerais pouvoir personnaliser l’image de base ou la VM pour n’inclure que les binaires nécessaires, sans outils inutiles
    Ou alors avoir une fonction pour dupliquer un sprite à partir d’un checkpoint. Pour l’instant, je ne vois pas cette option

    • Ce serait bien d’avoir une fonction du type déploiement Docker, où je pourrais publier l’image de sprite de base comme je le souhaite, puis continuer à travailler dessus

  • J’ai vraiment pris du plaisir à travailler sur Sprites ces derniers mois
    On va bientôt publier en open source une partie du côté Elixir
    Il y a aussi une démo vidéo de 5 minutes → démo YouTube

    • Ce qui est intéressant, c’est que Claude contrôle lui-même Sprites. Quand on lance le serveur, il l’enregistre automatiquement comme service local, et en cas de gros changement, il crée lui-même des checkpoints
      Les sprites inutilisés ne coûtent presque rien. On peut simplement en créer un nouveau à chaque nouveau travail
      C’est une sensation étrange d’avoir un environnement qu’on peut lancer à tout moment, sans avoir à prendre de décision

  • Comme le domaine est en fly.io, au début j’ai cru que ce serait une solution locale
    Même si ce n’était pas self-hosted, je m’attendais à un wrapper de VM locale autour de Docker ou de bubblewrap

    • Pour ce type d’usage, ça vaut le coup de regarder le projet LXC/Incus → https://linuxcontainers.org/incus/
      Faire tourner IncusOS, basé sur ZFS, sur du matériel local donne un environnement sandbox très puissant

  • Je l’ai peut-être raté dans la documentation, mais je me demande s’il est possible de forker/cloner un sprite ou de restaurer un checkpoint dans un nouveau sprite
    Par exemple, j’aimerais utiliser un sprite comme modèle pour en lancer plusieurs, ou laisser Claude Code explorer plusieurs solutions puis n’en garder qu’une seule et nettoyer le reste

    • Cette fonctionnalité va arriver bientôt. Un billet “how this works” prévu la semaine prochaine expliquera pourquoi et comment c’est structuré
      On voulait l’inclure au lancement, mais il a été décidé de recueillir un peu plus de données d’usage réelles d’abord