Microsandbox - Une machine virtuelle qui se comporte comme un conteneur

• microsandbox fournit une exécution sûre de code utilisateur non fiable et de code IA grâce à une isolation au niveau machine virtuelle
• Démarrage ultra-rapide (moins de 200 ms), compatibilité avec les conteneurs OCI, auto-hébergement : il surmonte ainsi les limites des VM et des conteneurs traditionnels
• Des SDK pour plusieurs langages et des outils CLI maximisent l’efficacité de l’intégration pour les développeurs et les outils d’IA
• Convient à un large éventail de cas d’usage IA et développement, notamment l’exécution de code, les environnements de développement, l’analyse de données, l’automatisation web et l’hébergement d’applications
• Toutes les tâches peuvent être gérées par projet, avec prise en charge de l’installation à l’échelle du système ainsi que d’environnements d’exécution persistants ou isolés

---

• microsandbox est une plateforme open source auto-hébergée conçue pour exécuter en toute sécurité du code utilisateur non fiable ou du code IA (par ex. agents IA, code soumis par des utilisateurs, code expérimental)
• L’exécution locale présente des failles de sécurité, les conteneurs ont une isolation incomplète à cause du partage du kernel, les VM traditionnelles démarrent lentement et le cloud manque de flexibilité
• microsandbox repose sur des microVM (machines virtuelles ultra-légères) pour offrir une véritable isolation des processus, tout en conservant la rapidité de démarrage et l’expérience développeur des conteneurs
• Il se distingue par un démarrage en moins de 200 ms après l’initialisation de l’environnement, la compatibilité avec les images de conteneur (OCI), l’intégration IA basée sur MCP et le contrôle de l’usage sur sa propre infrastructure

Résumé des principales fonctionnalités

• Bulletproof Security : basé sur des microVM, il fournit une sécurité au niveau machine virtuelle qui bloque à la source les vulnérabilités des conteneurs (évasion du kernel)
• Instant Startup : avec un temps de démarrage initial inférieur à 200 ms, il permet un lancement de l’exécution du code extrêmement plus rapide qu’une VM classique
• Self-Hosting & Full Control : déploiement et exploitation en local ou sur ses propres serveurs, sans dépendance au cloud
• Compatibilité OCI : exécution directe d’images de conteneurs standard, avec compatibilité avec les workflows Docker et conteneurs existants
• AI-Ready (prise en charge de MCP) : intégration et extension naturelles avec des IA basées sur MCP, comme Claude ou Agno

Workflow de développement et d’exécution rapide

1. Démarrer le serveur

• Quelques commandes simples suffisent pour lancer le serveur microsandbox et mettre en place l’environnement de développement
• Le serveur joue aussi le rôle de serveur MCP, ce qui permet une utilisation directe depuis des outils IA comme Claude

2. Installer le SDK

• Le SDK microsandbox est fourni pour les principaux langages comme Python, JavaScript et Rust
• La prise en charge de langages supplémentaires (extensibilité des SDK) ouvre de larges possibilités d’intégration pour les développeurs et l’IA

3. Exécuter du code en toute sécurité

• Il est possible de choisir et d’exécuter séparément des environnements sandbox pour plusieurs langages, dont Python, JavaScript et Rust
• Chaque sandbox est un environnement d’exécution indépendant, garantissant la sécurité du système même lors de l’exécution de code externe
• Les exemples du SDK facilitent la mise en place de processus asynchrones et automatisés d’exécution sécurisée du code

Gestion d’environnement par projet

• Les Sandboxfile (fichiers de configuration) sont créés et gérés par projet, dans un workflow proche de celui d’un gestionnaire de paquets pensé pour les développeurs
• Plusieurs environnements sandbox (par ex. différents langages ou configurations) peuvent être ajoutés à un projet pour une gestion par version ou par environnement
• Lors de l’exécution d’un sandbox de projet, les fichiers et les modifications d’installation sont automatiquement conservés dans le répertoire local (./menv)
• Option d’activation de sandbox temporaires (suppression complète de tout historique et de tout état à la fin de la session, avec isolation totale)

Installation de sandboxes à l’échelle du système

• Il est possible d’installer et d’enregistrer comme exécutable distinct un environnement ou une application fréquemment utilisé
• Depuis le terminal, on peut entrer directement dans un environnement sandbox avec une simple commande, sans chemin de projet
• Chaque sandbox peut recevoir un nom, fonctionner avec des configurations différentes en parallèle, et conserver l’état de la session

Principaux cas d’usage

Exécution de code IA et environnement de développement

• Lorsque l’IA automatise concrètement la compilation, l’exécution et le débogage du code source, elle peut disposer rapidement d’environnements de développement isolés et reproductibles
• Adapté à l’automatisation de code pour la création de web apps, la correction de bugs ou les prototypes

Analyse de données

• Les principales bibliothèques de data science comme NumPy, Pandas et TensorFlow peuvent être utilisées en toute sécurité dans le sandbox
• Idéal pour les workflows d’analyse nécessitant la protection de données personnelles ou sensibles

Agents de navigation web

• L’IA peut exécuter en toute sécurité des tâches automatisées comme la navigation sur des sites web, l’envoi de formulaires, la connexion ou le scraping de données
• Utile pour la collecte de contenu, la comparaison de prix ou les tests automatisés

Hébergement instantané d’applications

• Les utilisateurs peuvent partager immédiatement sous forme de service des outils, démos, calculatrices ou visualisations qu’ils ont créés
• Chaque application fonctionne dans un espace isolé distinct, avec prise en charge de la création et de l’arrêt rapides d’environnements temporaires

Architecture du système

• L’utilisateur appelle le SDK microsandbox depuis sa propre logique métier
• Il demande au processus serveur (microsandbox server) de transmettre et d’exécuter du code non fiable
• Dans le serveur, chaque requête d’exécution s’exécute dans une microVM distincte, isolée des autres
• Chaque microVM peut disposer de son propre environnement Python/Node indépendant

Politique open source

• Distribution open source sous Apache License 2.0

[GN⁺]

Avis Hacker News

• J’aimerais voir une véritable classification de sécurité des conteneurs.
  1. Constituer une liste exhaustive de toutes les vulnérabilités connues des conteneurs
  2. Exécuter chaque vulnérabilité dans plusieurs environnements de sécurité : permissions seules, jail, Docker, émulateur, etc.
  3. Attribuer un score selon le pourcentage d’exploits effectivement bloqués
     Avec une telle méthode, on pourrait s’attendre à ce que les conteneurs basés simplement sur des permissions ou sur des jails soient proches de 0 %, que Docker dépasse 50 %, et que Microsandbox approche 100 %.
     Cela permettrait aussi de répondre plus intuitivement à des questions du genre « pourquoi ne pas simplement utiliser un jail ? ».
     Il serait aussi amusant de « prouver » quel conteneur atteint 100 % en lançant des conteneurs honeypot sur le web public, avec une récompense en cash ou en crypto pour toute compromission réussie.
     Avec des vulnérabilités récentes comme Rowhammer ou Spectre, il faut peut-être même redéfinir la sécurité du cloud computing conventionnel.
     Au fond, la motivation est d’obtenir des pistes sur la façon de construire un conteneur sûr à 100 % sans émulation complète, ainsi que sur la sécurisation des services de base de l’OS.
• En environnement multi-tenant, le problème n’est pas une « vulnérabilité de conteneur » en soi, mais le fait structurel que le noyau est partagé.
  Dès qu’il existe une vulnérabilité de type kernel LPE (Local Privilege Escalation), cela devient immédiatement une évasion de conteneur potentielle.
  Ce n’est généralement pas étiqueté comme une évasion de conteneur, mais dans l’industrie, s’il y a une kernel LPE, on considère naturellement que la sécurité des conteneurs est compromise.
• Face à des conteneurs malveillants, il est impossible de construire un environnement totalement sûr avec un runtime de conteneur fondé sur le noyau Linux.
  L’alternative la plus visible consiste à restreindre massivement l’usage des appels système (API) à l’intérieur de la sandbox ; mais dans ce cas, le conteneur cesse d’être une plateforme générique, et il faut le retuner à la main à chaque cas d’usage.
  C’est pourquoi certains estiment que la virtualisation est nécessaire.
  Tant qu’on n’aura pas un OS sûr en mémoire et vraiment robuste, il n’y a guère d’autre voie ; et même si un tel OS existait, on ne sait pas encore s’il serait plus rapide que d’exécuter une MicroVM sur un hôte Linux.
• J’aimerais aussi qu’on affiche la configuration de la machine.
  Avec Docker ou systemd, le niveau de sécurité varie énormément selon les paramètres choisis.
  Je pense qu’il faut un grand jeu de données expérimental montrant quel réglage mène à quel niveau de risque ou de sécurité.
• En réalité, les conteneurs fonctionnent déjà comme des honeypots avec primes en cash ou en crypto.
  En pratique, les environnements de production réels sont déjà la cible d’attaques de nombreux hackers.
  Ce type de modèle d’incitation peut être amusant, mais en termes de valeur de la cible et d’incitation financière, ce sera sans doute bien inférieur à un environnement réel.
• Je me demande pourquoi les VM traditionnelles sont si longues à démarrer.
  Par exemple, sous Windows, quand on lance une VM, il faut souvent attendre plusieurs secondes avant que quoi que ce soit ne commence.
  Par « rien ne s’exécute », je parle d’un état avant même le lancement du moindre programme utilisateur, voire avant la toute première instruction du firmware.
  Il y a même parfois une longue attente avant le vidage du fichier de disque virtuel, ou avant même que la fenêtre de la VM n’apparaisse.
  Je me demande d’où cela vient.
  • Démarrer un noyau Linux en moins d’une seconde est tout à fait faisable avec de l’optimisation.
    Mais avec un noyau standard, il y a beaucoup d’opérations qui prennent du temps, comme des timeouts ou du polling.
    La préparation du matériel virtuel, l’initialisation de l’environnement système sur des systèmes UEFI/CSM, etc., prennent aussi un certain temps.
    WSL2 utilise probablement un noyau spécial pour éliminer les surcoûts inutiles.
    Le démarrage des services de l’OS, la préparation du système de fichiers, l’initialisation des caches, la configuration réseau, etc., jouent également.
    Dans l’approche traditionnelle, le bootloader, l’initramfs et l’OS principal sont tous chargés séparément.
    Pour réduire le temps de boot à l’extrême, on peut utiliser une approche comme Amazon Firecracker, qui charge directement en mémoire une image de VM préinitialisée.
    Présentation de Firecracker MicroVM
    Sous Windows, la vitesse de démarrage dépend aussi de l’hyperviseur utilisé, comme Hyper-V.
    L’UEFI d’Hyper-V est assez lente, et beaucoup de distributions Linux ne fournissent pas de noyau minimal optimisé.
  • Il faudrait plus d’informations sur le logiciel de VM utilisé.
    Dans le cas de VirtualBox, le phénomène décrit est très visible, alors que les anciennes versions n’avaient pas ce délai.
    Ce n’est peut-être pas une limite intrinsèque des « VM traditionnelles », mais simplement un problème propre à ce logiciel.
  • Ce n’est pas forcément le cas.
    En général, les VM sont lentes parce qu’elles émulent aussi des éléments inutiles.
    Si l’on construisait un hyperviseur orienté uniquement vers la vitesse de démarrage, en ignorant la compatibilité héritée, un boot en 125 ms comme Firecracker serait possible.
  • Sous Linux, une cause majeure de lenteur lors de l’allocation mémoire des VM est l’allocation de plusieurs Go en pages de 4 KB.
    En allouant en blocs de 1 GB, cela peut devenir radicalement plus rapide.
    Windows a probablement un mécanisme comparable.
  • C’est peut-être un problème de VirtualBox.
    Pour ma part, j’ai déjà accédé en 10 secondes à une Ubuntu 22 GUI via XRDP sous Hyper-V, et en moins de 3 secondes à un serveur Ubuntu 22 via SSH.
• J’ai relevé l’ironie des instructions d’installation qui disent de « pipe un script d’installation distant directement dans Bash » précisément dans un contexte où il faut exécuter du code non fiable.
  Cela dit, l’idée de base reste extrêmement intéressante.
  • Au début, je n’avais pas compris non plus, mais on peut aussi télécharger le script séparément puis le vérifier manuellement.
    Une méthode de distribution officielle devrait arriver bientôt.
• Merci d’avoir partagé le projet, et précision : j’en suis le créateur.
  L’objectif est de permettre de créer des microVM aussi facilement que des conteneurs Docker.
  N’hésitez pas à poser vos questions.
  • Je l’utilise déjà avec succès comme bibliothèque Python, mais j’aimerais garder la sandbox active à travers plusieurs appels séparés.
    Je tombe parfois sur des erreurs du type « Sandbox is not started. Call start() first ».
    Le pattern de la documentation est async with, mais dans mon cas j’aimerais instancier une fois par classe puis la réutiliser dans plusieurs méthodes.
    Je serais curieux d’avoir une méthode recommandée ou une bonne pratique à ce sujet.
  • Je construis un réseau de test logiciel distribué/décentralisé (Valet Network), et microsandbox pourrait être très utile.
    Je me demande comment le réseau fonctionne.
    Par exemple, peut-on limiter une microVM à l’accès aux seules IP publiques ?
    Autrement dit, peut-on empêcher la microVM d’accéder aux IP du réseau local ?
  • Très beau projet, bravo à appcypher.
    Je me demande si la fonctionnalité MicroVM intégrée fournit une interface de runtime OCI.
    Peut-on l’utiliser dans Docker/Podman à la place de runc/crun ?
  • J’ai parcouru rapidement le readme et j’ai plusieurs questions pour lesquelles j’aimerais plus d’explications.
    Comment cela peut-il être aussi rapide ?
    Quels sont les compromis par rapport à une VM traditionnelle ?
    Y a-t-il un risque que l’isolation de la VM soit affaiblie ?
    Peut-on lancer une GUI ?
    Faut-il voir cela comme un nouveau Vagrant ?
    Comment se passent les entrées/sorties de données ?
  • Cela a l’air remarquablement propre.
    Si j’ai bien compris, peut-on aussi lancer en temps réel un backend comme un serveur avec ça ?
    La liste des langages pris en charge est impressionnante liste des langages pris en charge par microsandbox
    J’aimerais un guide de contribution plus détaillé contributor guide
• Je suis surpris du nombre d’options de VM ultra-légères, presque jetables, apparues ces dernières années.
  J’ai connu une époque où les VM étaient lentes, lourdes et pénibles à utiliser.
  J’aimerais comparer cela à Orbstack sur macOS, en particulier à la fonctionnalité « Linux machines ».
  Je me demande aussi si Orb réutilise une seule VM.
  • Site d’Orbstack
  • Documentation Orbstack Linux machines
• Félicitations.
  Démarrer des VM en quelques millisecondes est une amélioration très importante.
  Mais on peut déjà obtenir quelque chose de similaire avec CloudHypervisor ou Firecracker.
  Là où les conteneurs gardent un avantage sur les VM, c’est la performance à l’exécution.
  Les VM sont ralenties par l’émulation des périphériques d’E/S.
  En particulier sur des charges de travail de type agents IA, ce surcoût risque de se sentir au niveau applicatif.
  Je me demande comment vous comptez traiter cet enjeu de performance.
  • Remarque juste.
    Microsandbox utilise libkrun, et libkrun emploie virtio-mmio pour block, vsock et virtio-fs afin de réduire le surcoût de performance.
    Firecracker est fondamentalement similaire, et le projet E2B utilise Firecracker pour traiter des charges de travail d’IA agentique.
    À part quelques questions actuelles autour du système de fichiers, aucun plan majeur d’amélioration des performances n’est prévu pour l’instant.
• Personnellement, j’ai l’impression que les technologies de conteneur étirent beaucoup trop l’OS.
  Il suffit de lancer la commande mount pour voir ce que je veux dire.
  On expose énormément d’informations qui devraient rester cachées, ce qui réduit l’utilité des commandes simples traditionnelles.
  Plus grave encore, l’utilisateur peut manipuler directement les structures de données internes.
  C’est comme donner à l’utilisateur à la fois des droits de peek et de poke.
  L’idée des conteneurs en elle-même est bonne, mais tant que le noyau ne sera pas repensé, l’approche actuelle restera un expédient.
  • Je ne comprends pas très bien le propos.
    Peux-tu expliquer en quoi le fait d’exécuter mount dans un conteneur est si problématique ?
    Est-ce que les montages de l’hôte sont réellement exposés au conteneur ?
    En général, je pensais que cela n’était possible que si l’on connecte explicitement des volumes au conteneur.
• Cela a l’air très intéressant, au point de me donner envie de l’essayer immédiatement.
  J’ai déjà beaucoup joué avec le SDK CodeSandbox, E2B, etc., et je suis curieux des différences entre les deux, ainsi que de la direction que vous prenez.
  Je voudrais aussi savoir si vous utilisez Firecracker en interne.
  • Microsandbox ne fournit pas de solution cloud.
    C’est une architecture que l’on héberge soi-même.
    Comme E2B, l’objectif est de faciliter l’exécution locale (Linux, macOS, Windows à venir) de sandboxes basées sur des microVM, puis de rendre le passage en production simple.
    Nous utilisons libkrun plutôt que Firecracker.
  • Mon principal intérêt était justement de savoir si Firecracker était utilisé.
    Je m’interroge sur les questions de maintenance et sur la continuité des audits de sécurité pour ce type de solution microVM.
    Comme Firecracker et la mise en place d’images OCI sont difficiles, j’accueille volontiers l’arrivée d’une alternative.
    Kata container est également difficile à manier.
• Ce type de projet m’intéresse toujours quand il apparaît.
  Le plus grand avantage des conteneurs, c’est qu’on peut les lancer rapidement sans avoir à préciser à l’avance des ressources concrètes comme la taille disque ou le nombre de cœurs CPU.
  On peut aussi comparer leur état à l’image et au diff, pour voir quelles modifications un programme a apportées au système pendant son exécution.
  J’aimerais qu’une VM minuscule offrant cette simplicité permette aussi un sandboxing plus sûr.
  Il m’arrive d’utiliser bwrap, mais ce n’est pas un outil vraiment adapté à la ligne de commande.
  • Les ressources (capacité disque, CPU, etc.) peuvent être déclarées une fois dans un fichier YAML.
    On peut aussi utiliser des templates ou générer cela à distance / automatiquement.
• Un peu hors sujet, mais je travaille sur un projet où je dois impérativement exécuter du code JavaScript non fiable.
  Microsandbox me donne l’espoir de pouvoir isoler proprement ce code pour l’exécuter en sécurité.
  Même un délai de boot de 200 ms peut se gérer avec un pool de sandboxes déjà prêtes.
  Comme il y a une compatibilité OCI, on peut potentiellement fournir l’environnement complet de sandbox.
  Je me demande si c’est effectivement un très bon cas d’usage, ou s’il existe de meilleures alternatives.
  • Tu peux aussi envisager runsc/gVisor.
    Le moteur runsc peut fonctionner dans Docker / Docker Desktop.
    En revanche, gVisor tourne à environ un tiers des performances de Docker sur des points comme le parallélisme réseau.
  • C’est précisément le cas d’usage idéal pour microsandbox.
    Je n’ai pas trouvé de meilleure alternative, alors j’ai fini par créer microsandbox moi-même.