10 points par GN⁺ 2026-02-24 | 1 commentaires | Partager sur WhatsApp
  • Environnement de machine virtuelle Linux léger pour exécuter des agents IA, fonctionnant sur la base de Virtualization.framework de macOS. Docker n'est pas nécessaire
  • Toutes les exécutions démarrent par défaut en mode éphémère (Ephemeral), de sorte que les installations et modifications sont automatiquement réinitialisées à la fin
  • Grâce à la fonction Checkpoint, l'état du disque peut être enregistré sous forme de snapshot, puis restauré, dérivé et réutilisé
  • Le réseau, le CPU, la mémoire et la taille du disque peuvent être contrôlés finement via des options en ligne de commande ou un fichier de configuration
  • Fournit un environnement de sandbox local sûr et reproductible pour l'exécution de code IA, l'installation de paquets, l'évaluation et les tests

Présentation de shuru, le sandbox local-first

  • Une architecture pour exécuter des VM Linux légères pour agents IA sur macOS
    • Utilise Apple Virtualization.framework pour offrir des performances ARM64 natives sans émulation
    • Sans dépendance à Docker, avec des exécutions éphémères (Ephemeral) par défaut
  • Chaque exécution démarre depuis un rootfs propre, et les changements ne sont pas conservés sauf s'ils sont enregistrés

Gestion d'état et snapshots

  • La fonction Checkpoint permet d'enregistrer l'état du disque dans des snapshots nommés
    • Les snapshots enregistrés peuvent être restaurés, dérivés et rejoués
    • Il devient possible de versionner les environnements comme des commits Git
  • Exemples de commandes :
    • $ shuru checkpoint create myenv --allow-net -- sh -c 'apk add nodejs npm' → enregistre le snapshot myenv
    • $ shuru run --from myenv -- node -e 'console.log("ready")' → exécute immédiatement depuis l'environnement enregistré

Fonctionnalités CLI

  • Fournit une interface CLI simple qui démarre et arrête la VM avec une seule commande
    • $ shuru run -- echo "hello from the sandbox" → exécute une commande dans le sandbox
    • $ shuru run -- cat /etc/os-release | head -1 → vérifie l'environnement Alpine Linux
  • L'accès réseau est désactivé par défaut, et le NAT peut être activé avec le flag --allow-net
  • Paramètres de ressources : options --cpus, --memory, --disk-size pour ajuster l'environnement d'exécution
  • Prise en charge du port forwarding : format -p 8080:8000 pour relier l'hôte et l'invité

Exécution et usages pour les agents IA

  • Fournit un environnement VM isolé pour exécuter du code généré par IA
    • La sortie en temps réel peut être consultée
  • Permet d'effectuer en toute sécurité l'installation de paquets, la compilation de code et l'utilisation d'outils système
  • Des sandboxes parallèles permettent des évaluations cohérentes entre environnements
  • Peut servir d'environnement Linux jetable pour les tests, le débogage et le prototypage

Installation et démarrage

  • L'installation comme l'exécution peuvent se faire avec une seule commande
  • Avec une initialisation rapide et un environnement jetable, il fournit un espace d'exécution sûr pour les développeurs comme pour les systèmes d'IA

1 commentaires

 
GN⁺ 2026-02-24
Commentaires sur Hacker News
  • Le point important ici, ce n’est pas la « VM locale » en soi, mais le fait que l’orientation par défaut est inversée
    La plupart des systèmes partent d’un état persistant et connecté au réseau, alors qu’ici, c’est au contraire un environnement éphémère et isolé qui est le comportement par défaut
    Cette différence est assez importante quand on exécute du code non fiable

  • Je pense créer pour macOS une version local first de microterm.dev
    L’objectif est de garder le même environnement sur toutes les cibles, avec seulement des différences de vitesse et de capacité RAM

    • Je me demande comment cela exécute les VM ou les conteneurs — est-ce basé sur le cloud, ou sur une approche du type container2wasm ?
      J’utilise en ce moment un terminal alpine sur mon téléphone, et je me demande vraiment si cela tourne dans le navigateur
    • Sur Safari iOS, ça entre dans une boucle de redirection (l’indicateur de chargement reste bloqué vers 90 %, puis après plusieurs rafraîchissements une erreur apparaît)
    • Génial, j’aimerais vraiment voir ça
  • Je me demande ce que signifie « local first » ici. Est-ce que ça veut simplement dire que ça s’exécute localement ?

    • Oui, cela signifie que tout s’exécute sur ma machine
      Des services comme E2B ou sprites.dev fournissent des sandboxes dans le cloud, mais shuru fait tourner la VM localement en utilisant Virtualization.framework d’Apple
      Autrement dit, les données ne quittent pas le Mac
    • Comme cela ne prend en charge que macOS, c’est en pratique uniquement local
    • C’est dommage qu’en ce moment ce genre d’expression soit utilisé comme un autre mot à la mode marketing
  • La stack des agents se divise progressivement en une structure en couches plus spécialisée, et le sandboxing devient un domaine à part entière
    On voit des exemples comme Shuru, E2B, Modal ou des wrappers autour de Firecracker
    Dans un billet que j’ai écrit auparavant, « Don’t go monolithic — the agent stack is stratifying », j’abordais aussi ce changement structurel et les limites d’une approche monolithique

    • Très bon article. J’ai eu une expérience similaire en faisant du développement logiciel avec une utilisation partielle de l’IA
      Si l’on ne conserve pas le contexte des décisions de conception prises conjointement par le développeur et l’IA, des informations importantes se perdent
      Cela dit, je ne sais pas très bien si cet article est directement lié au sujet des micro VM
  • Je me demande quelle est la différence par rapport au projet container d’Apple
    Le courant d’innovation dans ce domaine est intéressant

    • Apple container suit un workflow de style Docker, centré sur les images OCI et les registres
      shuru, en revanche, se concentre sur des micro VM avec fonction de checkpoint et a un périmètre bien plus simple
  • Je me demande s’il existe un équivalent de ce genre pour Windows
    WSL nécessite une configuration lorsqu’on veut distribuer une application au grand public, donc ce n’est pas adapté à un usage grand public

  • Ce projet est vraiment génial. Cela faisait des mois que j’attendais des micro VM basées sur Virtualization.framework
    Docker est correct aussi, mais le problème était son overhead important
    J’aime le fait que le mode par défaut soit éphémère et que le réseau soit désactivé
    Je me demande aussi s’il est prévu d’ajouter une fonctionnalité de mapping de répertoires hôte
    J’exploite un serveur MCP pour sandboxes éphémères prenant en charge plusieurs backends (Docker, E2B, Modal, WASM, etc.), donc je pense essayer d’y intégrer ceci
    Lien vers le projet Kilntainers

  • Je me demande quels sont les avantages par rapport à Lima

    • Avec la bonne configuration, Lima peut aussi faire quelque chose de similaire à shuru
      La différence tient aux valeurs par défaut et au degré de simplification de la configuration initiale
      shuru fournit par défaut des VM éphémères, le réseau désactivé et un rootfs propre à chaque exécution
      Il suffit de taper shuru run, sans fichier de configuration
      Les checkpoints et le branching sont aussi intégrés à la CLI
      Lima est un projet bien plus vaste et mature, mais shuru est développé comme un outil simple et adapté à l’apprentissage
  • Je cherchais quelque chose comme ça pour un nouveau projet
    Ce que je construis est un outil hybride entre retool et OpenClaw, une solution destinée à aider les PME à créer rapidement des applications internes

  • Shuru est vraiment génial
    Je développe aussi un outil basé sur des MicroVM pour Linux avec un concept similaire
    Le mode par défaut est hors ligne, et même si ce n’est pas encore prêt à être rendu public, nous l’utilisons déjà en dogfooding en interne