Smol machines – démarrage à froid en moins d’une seconde et machine virtuelle portable

 (github.com/smol-machines)
7 points par GN⁺ 2026-04-18 | 1 commentaires | Partager sur WhatsApp
  • smolvm est un outil de gestion de machines virtuelles en ligne de commande qui exécute des logiciels dans un environnement isolé
  • Il prend en charge un démarrage à froid en moins d’une seconde, une gestion élastique de la mémoire et une portabilité en fichier unique, pour exécuter des VM rapidement et avec légèreté
  • Les VM s’exécutent sous forme de microVM basées sur le noyau Linux et peuvent être empaquetées dans un fichier .smolmachine pour être relancées sans dépendances
  • Il offre une prise en charge intégrée des environnements de développement et de sécurité avec l’isolation par frontière d’hyperviseur, le transfert d’agent SSH et la déclaration d’environnement via Smolfile
  • Il prend en charge le démarrage d’images OCI sans démon Docker et propose une alternative de virtualisation légère avec un temps de démarrage inférieur à 200 ms et une isolation au niveau matériel

Vue d’ensemble

  • smolvm est un outil de gestion de machines virtuelles en ligne de commande conçu pour exécuter des logiciels dans un environnement isolé
  • Il fonctionne sur macOS et Linux et prend en charge un cold start en moins d’une seconde, une utilisation élastique de la mémoire et un empaquetage portable en fichier unique
  • Chaque charge de travail s’exécute dans une microVM basée sur le noyau Linux, offrant une isolation au niveau matériel
  • Une VM empaquetée dans un fichier .smolmachine peut être relancée sans dépendances sur des plateformes de même architecture

Fonctionnalités principales

  • Gestion et exécution de machines virtuelles locales

    • Exécution d’une VM Linux personnalisée avec la commande smolvm machine run
    • Le démarrage à froid prend moins d’une seconde, avec prise en charge de macOS et Linux
    • La mémoire est gérée de façon élastique via virtio balloon, et seule la consommation réelle est allouée à l’hôte

  • Empaquetage portable en fichier unique

    • La VM, état inclus, peut être regroupée dans un fichier .smolmachine puis recréée sur une autre plateforme
    • Toutes les dépendances sont intégrées, ce qui permet une exécution immédiate sans installation, avec un temps de démarrage inférieur à 200 ms

  • Sandbox pour code non fiable

    • La frontière de l’hyperviseur isole complètement le système de fichiers hôte, le réseau et les identifiants
    • Le réseau est désactivé par défaut, et l’option --allow-host permet d’autoriser uniquement des hôtes précis

  • VM persistantes pour le développement

    • Création et gestion des VM avec les commandes machine create, start, stop
    • Les paquets installés sont conservés après redémarrage, ce qui permet un usage comme environnement de développement

  • Transfert d’agent SSH

    • L’agent SSH de l’hôte est transmis à l’intérieur de la VM, mais la clé privée n’est pas copiée dans l’invité
    • L’option --ssh-agent permet d’utiliser en toute sécurité l’authentification SSH de l’hôte

  • Déclaration d’environnement via Smolfile

    • La configuration de la VM est déclarée dans un Smolfile au format TOML
    • Il est possible de définir l’image, le réseau, les commandes d’initialisation, les volumes, les options d’authentification, etc., pour obtenir un environnement reproductible

Exemples d’utilisation

  • Exécution d’une VM temporaire

    • smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"
    • Mode d’exécution ponctuel dans lequel la VM est automatiquement nettoyée à la fermeture

  • Création d’un exécutable empaqueté

    • smolvm pack create --image python:3.12-alpine -o ./python312
    • L’exécutable généré permet de lancer un environnement Python autonome

  • Contrôle réseau

    • Le réseau est désactivé par défaut
    • L’option --allow-host permet d’autoriser l’accès uniquement à des domaines précis

  • Utilisation de SSH et Git

    • smolvm machine run --ssh-agent --net --image alpine
    • Accès possible à des dépôts Git en utilisant en toute sécurité les clés SSH de l’hôte

Architecture interne et fonctionnement

  • Chaque charge de travail exécute un noyau indépendant sur Hypervisor.framework (macOS) ou KVM (Linux)
  • Utilise un VMM basé sur libkrun ainsi qu’un noyau personnalisé (libkrunfw)
  • Prend en charge le format d’image OCI, ce qui permet de récupérer et d’exécuter directement des images depuis Docker Hub, ghcr.io, etc.
  • Aucun démon Docker requis, avec possibilité de démarrer directement des images OCI standard
  • La configuration par défaut est de 4 vCPU et 8 Gio de RAM, ajustables via les options --cpus et --mem
  • Les threads vCPU passent automatiquement en veille côté hyperviseur lorsqu’ils sont inactifs, ce qui rend le coût de surallocation quasi nul

Comparaison

Élément smolvm Containers Colima QEMU Firecracker Kata
Niveau d’isolation VM par charge de travail namespaces (noyau partagé) namespaces (VM unique) VM individuelles VM individuelles VM par conteneur
Temps de démarrage <200ms environ 100ms quelques secondes 15–30s <125ms environ 500ms
Architecture bibliothèque (libkrun) démon démon dans la VM processus processus pile d’exécution
VM par charge de travail pris en charge non pris en charge partagé pris en charge pris en charge pris en charge
macOS natif pris en charge via VM Docker basé sur krunkit pris en charge non pris en charge non pris en charge
SDK intégré pris en charge non pris en charge non pris en charge non pris en charge non pris en charge non pris en charge
Artefact portable .smolmachine image nécessitant un démon non pris en charge non pris en charge non pris en charge non pris en charge

Prise en charge des plateformes

Hôte Invité Exigences
macOS Apple Silicon Linux arm64 macOS 11 ou supérieur
macOS Intel Linux x86_64 macOS 11 ou supérieur (tests non finalisés)
Linux x86_64 Linux x86_64 KVM (/dev/kvm) requis
Linux aarch64 Linux aarch64 KVM (/dev/kvm) requis

Limitations connues

  • Le réseau est désactivé par défaut et ne peut être activé qu’avec l’option --net
  • Seuls TCP/UDP sont pris en charge, pas ICMP
  • Les montages de volumes ne sont possibles qu’au niveau des répertoires, pas pour un fichier unique
  • Sur macOS, seuls les binaires signés avec les autorisations Hypervisor.framework peuvent être exécutés
  • Lors de l’utilisation de --ssh-agent, un agent SSH doit être en cours d’exécution sur l’hôte (SSH_AUTH_SOCK doit être défini)

Développement

  • Les consignes de développement sont disponibles dans docs/DEVELOPMENT.md
  • Publié sous licence Apache-2.0, créé par @binsquare

À lire aussi

1 commentaires

 
GN⁺ 2026-04-18
Avis Hacker News

  • Je suis en train de construire une machine virtuelle qui pourrait remplacer les conteneurs Docker
    avec la même ergonomie que les conteneurs, tout en visant un temps de démarrage inférieur à 1 seconde
    En travaillant chez AWS sur Firecracker, j’ai réalisé que les conteneurs ajoutaient une couche inutile, et que Firecracker était une technologie conçue pour l’architecture interne d’AWS
    J’ai donc fini par créer moi-même une forme hybride qui combine les avantages des conteneurs et ceux de Firecracker
    J’aimerais avoir vos avis

    • C’est vraiment génial. J’ai moi aussi étudié des solutions de sandboxing pour l’IA, puis j’ai créé Locki avec une combinaison Lima+Incus
      Le problème, c’est que les microVM ne peuvent généralement pas exécuter Docker ou Kubernetes
      Moi, j’aimerais mettre un cluster Kubernetes complet dans une sandbox. Je me demande si l’exécution de k3s est aussi prise en charge
    • Je me demande où en est la prise en charge de la migration à chaud
      C’est une fonctionnalité qui manque toujours dans ce genre de système, alors qu’il existe encore beaucoup d’environnements qui en ont besoin au-delà des workloads cloud native
      Si vous l’ajoutez, ce serait un vrai facteur de différenciation
    • Je me demande quelle part du code a été écrite avec des LLM / de l’IA
    • J’ai moi aussi construit quelque chose de similaire — ça s’appelle shuru.run
      Firecracker ne fonctionne pas sur macOS, et je voulais pouvoir créer facilement des sandboxes microVM pour des apps d’IA
      Pour un utilisateur classique, Firecracker est beaucoup trop lourd
    • Je me demande quel a été le défi de conception le plus difficile pour atteindre un temps de boot inférieur à 1 seconde
      Et j’aimerais aussi savoir quels sont aujourd’hui les goulots d’étranglement si vous voulez encore réduire ce temps

  • Ce projet ressemble à plusieurs implémentations de unikernel — par exemple Unikraft

    • Je ne connais pas bien les détails internes d’Unikraft, car ce n’est pas open source
      Mais Smol Machines n’est pas une implémentation de unikernel : c’est une version allégée du noyau Linux
      Il est donc hautement compatible avec la plupart des logiciels

  • La fonction de génération de binaire autonome ressemble à une manière de packager des apps JVM plus simplement qu’avec GraalVM Native
    Exemple de commande :
    smolvm pack create --image python:3.12-alpine -o ./python312
    ./python312 run -- python3 --version
    → Python 3.12.x s’exécute de façon totalement isolée, sans pyenv/venv/conda

    • C’est un concept similaire à Electron
      De la même manière qu’Electron distribue des apps web avec le navigateur, Smol Machines packagerait le logiciel avec une VM Linux
      Cela permet d’éviter les problèmes de gestion des dépendances et de compatibilité
      Personnellement, j’aimerais que des outils comme Codex ou Claude Code soient aussi distribués de cette manière
    • Tout le monde a déjà, au moins une fois, “cassé son environnement de développement”
      C’est l’idée d’une « machine distribuable » pour résoudre ce problème
      Une fois bien configurée, on peut la partager et l’exécuter immédiatement chez n’importe qui

  • Je me demande si le fichier .smolmachine prend en charge la signature numérique et l’auto-authentification
    J’aimerais savoir si cela peut fonctionner comme dans la documentation de signature/vérification de Sylabs

  • Je me demande s’il serait possible d’aller encore plus vite en appliquant les idées de zeroboot

  • Le tableau comparatif est vraiment très bien fait
    Au début, je me suis dit « ça ressemble à Firecracker », mais en voyant le tableau, les différences sont devenues très claires
    C’était facile à lire et, dans l’ensemble, c’est un travail très impressionnant

    • Merci

  • Dans la documentation CLI, j’ai vu les images alpine et python:3.12-alpine, et je me demande d’où elles viennent
    Est-ce que ça vient d’un registre Docker, est-ce intégré, ou est-ce qu’on les crée soi-même avec un smolfile ?
    Je me demande aussi s’il existe une image Ubuntu
    Ce serait bien d’ajouter le redimensionnement à chaud de la mémoire et du CPU, et je pense que cela pourrait aussi servir à orchestrer une infrastructure backend par client

  • La plupart des projets open source démarrent leurs conteneurs avec Docker Compose, mais Smol Machines ne prend pas en charge Docker dans la microVM
    C’est aussi dommage qu’il ne prenne pas en charge les VM imbriquées comme Vagrant

    • La prise en charge de Docker est prévue. Nous comptons distribuer dans la prochaine version un noyau compatible avec les flags noyau nécessaires
    • Comme Vagrant démarre une VM en local, il semble qu’il ait besoin de nesting
      À la place, il est proposé d’utiliser une approche trampoline pour l’exécuter comme VM sœur de la VM Vagrant

  • Je me demande si vous pourriez expliquer brièvement quelle est la raison principale d’utiliser Smol Machines plutôt qu’une sandbox Docker

  • Très beau résultat. Félicitations