shuru – Open-Source-Sandbox für lokale Linux-MicroVMs auf macOS

 (shuru.run)
10 Punkte von GN⁺ 2026-02-24 | 1 Kommentare | Auf WhatsApp teilen
  • Leichtgewichtige Linux-VM-Umgebung zum Ausführen von AI-Agenten, basierend auf dem Virtualization.framework von macOS. Docker wird nicht benötigt
  • Jede Ausführung startet standardmäßig ephemer (Ephemeral), sodass Installationen oder Änderungen beim Beenden automatisch zurückgesetzt werden
  • Mit der Checkpoint-Funktion lässt sich der Festplattenzustand als Snapshot speichern sowie wiederherstellen, verzweigen und wiederverwenden
  • Netzwerk, CPU, Arbeitsspeicher und Festplattengröße lassen sich per Kommandozeilenoptionen oder Konfigurationsdatei fein steuern
  • Bietet eine sichere und reproduzierbare lokale Sandbox-Umgebung für die Ausführung von AI-Code, Paketinstallationen, Evaluierung und Tests

Überblick über die lokale Sandbox shuru

  • Struktur zum Ausführen einer leichtgewichtigen Linux-VM für AI-Agenten auf macOS
    • Nutzt Apple Virtualization.framework und bietet native ARM64-Geschwindigkeit ohne Emulation
    • Keine Docker-Abhängigkeit und standardmäßig ephemere (Ephemeral) Ausführung
  • Jede Ausführung startet mit einem sauberen rootfs, und Änderungen bleiben nur erhalten, wenn sie explizit gespeichert werden

Zustandsverwaltung und Snapshots

  • Mit der Checkpoint-Funktion kann der Festplattenzustand als benannter Snapshot gespeichert werden
    • Gespeicherte Snapshots lassen sich wiederherstellen, verzweigen und wiederholt ausführen
    • Dadurch ist eine Versionsverwaltung der Umgebung ähnlich wie bei Git-Commits möglich
  • Beispielbefehle:
    • $ shuru checkpoint create myenv --allow-net -- sh -c 'apk add nodejs npm' → Speichert den Snapshot „myenv“
    • $ shuru run --from myenv -- node -e 'console.log("ready")' → Führt sofort in der gespeicherten Umgebung aus

CLI-Funktionen

  • Bietet eine einfache CLI-Oberfläche, die eine VM mit einem einzelnen Befehl startet und beendet
    • $ shuru run -- echo "hello from the sandbox" → Führt einen Befehl in der Sandbox aus
    • $ shuru run -- cat /etc/os-release | head -1 → Prüft die Alpine-Linux-Umgebung
  • Netzwerkzugriff ist standardmäßig deaktiviert, mit dem Flag --allow-net kann NAT aktiviert werden
  • Ressourceneinstellungen: Mit den Optionen --cpus, --memory, --disk-size lässt sich die Laufzeitumgebung anpassen
  • Port-Forwarding wird unterstützt: Im Format -p 8080:8000 kann eine Verbindung zwischen Host und Gast hergestellt werden

Ausführung und Nutzung mit AI-Agenten

  • Stellt eine isolierte VM-Umgebung für die Ausführung von AI-generiertem Code bereit
    • Echtzeit-Ausgabe kann überprüft werden
  • Paketinstallationen, Code-Kompilierung und die Nutzung von Systemwerkzeugen lassen sich sicher ausführen
  • Parallele Sandbox-Ausführung ermöglicht konsistente Evaluierungen zwischen Umgebungen
  • Kann als wegwerfbare Linux-Umgebung für Tests, Debugging und Prototyping genutzt werden

Installation und Start

  • Sowohl Installation als auch Ausführung sind mit einem einzelnen Befehl möglich
  • Mit schneller Initialisierung und verwerfbarer Umgebung bietet es sowohl Entwicklern als auch AI-Systemen einen sicheren Ausführungsraum

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-24
Hacker-News-Kommentare

  • Wichtig ist hier nicht die „lokale VM“ an sich, sondern dass die Standardrichtung umgekehrt ist
    Bei den meisten Systemen ist ein persistenter, netzwerkverbundener Zustand der Standard, hier dagegen ist standardmäßig eine flüchtige und isolierte Umgebung gesetzt
    Wenn man nicht vertrauenswürdigen Code ausführt, ist dieser Unterschied ziemlich wichtig

  • Ich überlege, eine Local-First-Version von microterm.dev für macOS zu bauen
    Das Ziel ist, auf allen Zielplattformen dieselbe Umgebung beizubehalten, wobei sich nur Geschwindigkeit und RAM-Größe unterscheiden

    • Ich frage mich, wie das VMs oder Container ausführt — Cloud-basiert oder eher auf eine Art wie container2wasm?
      Ich benutze gerade auf dem Handy ein Alpine-Terminal und frage mich wirklich, ob das im Browser läuft oder nicht
    • In iOS Safari gerät es in eine Redirect-Schleife (der Ladeindikator bleibt bei etwa 90 % stehen, dann folgen wiederholte Reloads und schließlich ein Fehler)
    • Sieht großartig aus, würde ich gern sehen

  • Ich frage mich, was „local first“ hier bedeutet. Heißt das einfach, dass es lokal ausgeführt wird?

    • Genau, es bedeutet, dass alles auf meinem Rechner läuft
      Dienste wie E2B oder sprites.dev bieten Cloud-Sandboxes an, aber shuru nutzt Apples Virtualization.framework, um die VM lokal auszuführen
      Das heißt, die Daten verlassen den Mac nicht
    • Da nur macOS unterstützt wird, ist es praktisch gesehen nur lokal
    • Schade, dass solche Begriffe inzwischen einfach wie ein weiteres Marketing-Buzzword verwendet werden

  • Der Agenten-Stack teilt sich zunehmend in eine spezialisierte Schichtenstruktur auf, und Sandboxing entwickelt sich zu einem eigenen Bereich
    Es gibt Beispiele wie Shuru, E2B, Modal und Firecracker-Wrapper
    In dem Artikel „Don’t go monolithic — the agent stack is stratifying“, den ich früher geschrieben habe, ging es ebenfalls um diesen strukturellen Wandel und die Grenzen monolithischer Ansätze

    • Der Artikel war gut. Ich habe bei der teilweise KI-gestützten Softwareentwicklung ähnliche Erfahrungen gemacht
      Wenn man den Kontext von Designentscheidungen, die Entwickler und KI gemeinsam getroffen haben, nicht speichert, gehen wichtige Informationen verloren
      Allerdings bin ich mir nicht sicher, ob der Artikel direkt mit dem Thema MicroVM zusammenhängt

  • Ich frage mich, worin im Vergleich zu Apples container-Projekt die Unterschiede liegen
    Der Innovationsfluss in diesem Bereich ist spannend

    • Apple container ist ein Docker-artiger Workflow mit Fokus auf OCI-Images und Registries
      shuru dagegen konzentriert sich auf MicroVMs mit Checkpoint-Funktion und hat dadurch einen deutlich einfacheren Umfang

  • Ich frage mich, ob es so etwas auch für Windows gibt
    WSL erfordert Konfiguration, wenn man Apps für normale Nutzer verteilen will, und ist deshalb für Endverbraucher nicht geeignet

  • Dieses Projekt ist wirklich großartig. Ich habe seit Monaten auf eine MicroVM auf Basis von Virtualization.framework gewartet
    Docker ist auch okay, aber das Problem ist der hohe Overhead
    Mir gefällt, dass standardmäßig alles flüchtig ist und das Netzwerk deaktiviert bleibt
    Ich frage mich auch, ob geplant ist, Host-Verzeichnis-Mapping hinzuzufügen
    Ich betreibe einen MCP-Server für ephemeral Sandboxes, der mehrere Backends unterstützt (Docker, E2B, Modal, WASM usw.), und denke darüber nach, das hier zu integrieren
    Link zum Kilntainers-Projekt

  • Ich frage mich, welche Vorteile es gegenüber Lima gibt

    • Mit der richtigen Konfiguration kann Lima auch etwas Ähnliches wie shuru leisten
      Der Unterschied liegt in den Standards und darin, wie stark die Ersteinrichtung vereinfacht wurde
      shuru bietet standardmäßig flüchtige VMs, deaktiviertes Netzwerk und bei jedem Start ein sauberes rootfs
      Ohne Konfigurationsdatei reicht einfach shuru run, und es startet sofort
      Checkpoints und Branching sind ebenfalls direkt in die CLI eingebaut
      Lima ist ein viel größeres und reiferes Projekt, aber shuru wird als einfaches, lernfreundliches Werkzeug entwickelt

  • Ich hatte für ein neues Projekt nach so etwas gesucht
    Was ich baue, ist ein kombiniertes Tool aus retool + OpenClaw, eine Lösung, mit der kleine und mittlere Unternehmen interne Apps schnell erstellen können

  • Shuru ist wirklich großartig
    Ich entwickle ebenfalls ein MicroVM-basiertes Tool für Linux mit einem ähnlichen Konzept
    Standardmäßig ist es offline, und obwohl es noch nicht bereit für eine Veröffentlichung ist, wird es intern bereits zum Dogfooding genutzt