Microsandbox – eine virtuelle Maschine, die sich wie ein Container anfühlt und verhält

• microsandbox bietet für die Ausführung von nicht vertrauenswürdigem Benutzer- und AI-Code eine sichere Isolierung auf Ebene virtueller Maschinen
• Mit ultraschnellem Start (unter 200 ms), OCI-Container-Kompatibilität und Self-Hosting überwindet es die Schwächen bestehender VMs und Container
• Mit SDKs für verschiedene Programmiersprachen und CLI-Tools wird die Effizienz bei der Integration für Entwickler und AI-Tools maximiert
• Geeignet für ein breites Spektrum an AI- und Entwicklungsanwendungen wie Code-Ausführung, Entwicklungsumgebungen, Datenanalyse, Web-Automatisierung und App-Hosting
• Alle Aufgaben lassen sich projektbasiert verwalten, einschließlich systemweiter Installation sowie Unterstützung für Sitzungsbeibehaltung und isolierte Ausführungsumgebungen

---

• microsandbox ist eine Open-Source-Self-Hosting-Plattform, die für die sichere Ausführung von nicht vertrauenswürdigem Benutzercode oder AI-Code (z. B. AI-Agenten, von Nutzern eingereichter Code oder experimenteller Code) entwickelt wurde
• Klassische lokale Ausführung hat Sicherheitslücken, Container bieten wegen des gemeinsam genutzten Kernels keine vollständige Isolierung, traditionelle VMs starten langsam und Cloud-Angebote sind oft unflexibel
• microsandbox unterstützt echte Prozessisolierung auf Basis von microVMs (ultraleichten virtuellen Maschinen) und bietet zugleich dieselbe schnelle Startgeschwindigkeit und entwicklerfreundliche Erfahrung wie Container
• Es hebt sich durch Boot-Zeiten unter 200 ms nach der initialen Umgebungseinrichtung, Kompatibilität mit Container-Images (OCI), MCP-basierte AI-Integration und Kontrolle über die Nutzung der eigenen Infrastruktur ab

Zusammenfassung der wichtigsten Merkmale

• Bulletproof Security: Auf Basis von microVMs wird Sicherheit auf Ebene virtueller Maschinen geboten, die Schwachstellen von Containern wie Kernel-Escapes grundsätzlich blockiert
• Instant Startup: Die anfängliche Boot-Zeit liegt unter 200 ms und ermöglicht damit einen im Vergleich zu VMs extrem schnellen Start der Code-Ausführung
• Self-Hosting & Full Control: Kann ohne Cloud-Abhängigkeit direkt lokal oder auf eigenen Servern aufgebaut und betrieben werden
• OCI-Kompatibilität: Kann unverändert mit Standard-Container-Images ausgeführt werden und bleibt damit mit bestehenden Docker- und Container-Workflows kompatibel
• AI-Ready (MCP-Unterstützung): Lässt sich mit MCP-basierten AIs wie Claude oder Agno nahtlos integrieren und erweitern

Schneller Entwicklungs- und Ausführungs-Workflow

1. Server starten

• Mit einfachen Befehlen lassen sich der microsandbox-Server starten und die Entwicklungsumgebung einrichten
• Der Server fungiert zugleich als MCP-Server und kann daher direkt von AI-Tools wie Claude aufgerufen werden

2. SDK installieren

• microsandbox SDKs stehen für wichtige Sprachen wie Python, JavaScript und Rust bereit
• Durch Unterstützung weiterer Sprachen und die Erweiterbarkeit der SDKs ergeben sich breite Integrationsmöglichkeiten für Entwickler und AI

3. Code sicher ausführen

• Sandbox-Umgebungen für verschiedene Sprachen wie Python, JavaScript und Rust können jeweils getrennt ausgewählt und ausgeführt werden
• Jede Sandbox ist eine unabhängige Laufzeitumgebung und gewährleistet damit auch bei der Ausführung externen Codes die Systemsicherheit
• Über SDK-Beispiele lassen sich asynchrone und automatisierte Prozesse zur sicheren Code-Ausführung leicht umsetzen

Projektbasierte Umgebungsverwaltung

• Ein Sandboxfile (Konfigurationsdatei) wird pro Projekt erstellt und verwaltet, ähnlich einem entwicklerfreundlichen Workflow mit Paketmanager-Charakter
• Mehrere Sandbox-Umgebungen (z. B. unterschiedliche Sprachen oder Konfigurationen) können zu einem Projekt hinzugefügt und nach Version bzw. Umgebung verwaltet werden
• Beim Ausführen von Projekt-Sandboxes werden Datei- und Installationsänderungen automatisch im lokalen Verzeichnis (./menv) gespeichert
• Option zur Aktivierung temporärer Sandboxes, bei denen nach Sitzungsende alle Spuren und Zustände vollständig gelöscht und isoliert werden

Systemweite Sandbox-Installation

• Häufig genutzte Umgebungen oder Apps können als eigenständige ausführbare Dateien installiert und registriert werden
• Auch ohne Projektpfad lässt sich direkt im Terminal per Einzeiler in eine Sandbox-Ausführungsumgebung wechseln
• Für jede Sandbox können Namen vergeben und mehrere unterschiedliche Konfigurationen parallel betrieben werden; der Sitzungszustand bleibt ebenfalls erhalten

Wichtige Einsatzszenarien

AI-Code-Ausführung und Entwicklungsumgebungen

• Wenn AI den tatsächlichen Build, die Ausführung und das Debugging von Quellcode automatisiert, stellt microsandbox schnell eine isolierte und reproduzierbare Entwicklungsumgebung bereit
• Geeignet für Code-Automatisierung wie Web-App-Erstellung, Bugfixing und Prototyping

Datenanalyse

• Wichtige Data-Science-Bibliotheken wie NumPy, Pandas und TensorFlow lassen sich sicher innerhalb der Sandbox nutzen
• Ideal für Analyse-Workflows mit schützenswerten personenbezogenen oder sensiblen Daten

Web-Browsing-Agenten

• AI kann Automatisierungsaufgaben wie Website-Navigation, Formularübermittlung, Login und Datencrawling sicher ausführen
• Nützlich für Anwendungsfälle wie Content-Erfassung, Preisvergleich und automatisierte Tests

Sofortiges App-Hosting

• Von Nutzern erstellte Tools, Demos, Rechner oder Visualisierungen können sofort als Dienst geteilt werden
• Jede App läuft in einem separaten Isolationsraum und unterstützt die schnelle Erstellung und Beendigung temporärer Umgebungen

Systemarchitektur

• Nutzer rufen das microsandbox SDK aus ihrer eigenen Business-Logik heraus auf
• An den Serverprozess (microsandbox server) wird die Übergabe und Ausführung nicht vertrauenswürdigen Codes angefordert
• Innerhalb des Servers wird jede Ausführungsanfrage in einer separaten microVM verarbeitet und damit voneinander isoliert
• Jede microVM kann eine unabhängige Python- oder Node-Umgebung bereitstellen

Open-Source-Richtlinie

• Open-Source-Veröffentlichung unter der Apache License 2.0

[GN⁺]

Hacker-News-Kommentare

• Ich würde gern ein offizielles Sicherheitsrating für Container sehen
  1. Eine kuratierte Liste aller bekannten Container-Schwachstellen erstellen
  2. Jede Schwachstelle in verschiedenen Sicherheitsumgebungen ausführen, etwa permissions-basiert, jail, Docker, Emulatoren usw.
  3. Dann als Score bewerten, wie viel Prozent aller Exploits blockiert wurden
     Bei so einem Ansatz würden einfache permissions- oder jail-basierte Container wohl nahe 0 % liegen, Docker bei über 50 % und Microsandbox vielleicht nahe 100 %
     Das könnte die intuitive Frage beantworten wie „Warum nicht einfach jail benutzen?“
     Es wäre auch interessant, Honeypot-Container ins offene Web zu stellen und erfolgreiche Hacks mit Bargeld oder Coins zu belohnen, um zu „beweisen“, welcher Container 100 % erreicht
     Wegen Schwachstellen wie Rowhammer oder Spectre muss man in letzter Zeit womöglich die Sicherheit konventioneller und Cloud-Computing-Systeme insgesamt neu definieren
     Letztlich steckt dahinter der Wunsch nach Erkenntnissen darüber, wie man ohne perfekte Emulation einen zu 100 % sicheren Container bauen und die Basisdienste des OS absichern könnte
• In Multi-Tenant-Umgebungen ist nicht die „Container-Schwachstelle“ das Problem, sondern die grundlegende Struktur des geteilten Kernels
  Denn eine Kernel-LPE-Schwachstelle (Local Privilege Escalation) führt direkt zu einem Container-Escape
  Das wird meist nicht explizit als Container-Escape bezeichnet, aber in der Branche gilt ein Kernel-LPE selbstverständlich als Bruch der Containersicherheit
• Gegen bösartige Container lässt sich mit Linux-kernelbasierten Container-Runtimes keine vollständig sichere Umgebung aufbauen
  Die naheliegende Alternative ist, innerhalb der Sandbox die Nutzung von System Calls (APIs) massiv einzuschränken, aber dann ist der Container keine universelle Plattform mehr und muss jedes Mal fallweise neu abgestimmt werden
  Deshalb halte ich Virtualisierung für notwendig
  Solange es kein speichersicheres und robustes OS gibt, bleibt wohl nur dieser Weg, und selbst wenn es ein solches OS gäbe, ist offen, ob es schneller wäre, als eine MicroVM auf Host-Linux zu betreiben
• Ich hätte gern auch die Maschinenkonfiguration gesehen
  Bei Docker oder systemd hängt das Sicherheitsniveau extrem von den jeweiligen Einstellungen ab
  Ich denke, wir brauchen einen großen experimentellen Datensatz dazu, welche Konfiguration welches Risiko- bzw. Sicherheitsniveau ergibt
• Tatsächlich werden Container schon heute als Honeypots mit Bargeld- oder Coin-Bounties betrieben
  In der Praxis ist die reale Produktionsumgebung selbst Ziel zahlloser Hackerangriffe
  So ein Incentive-Modell könnte unterhaltsam sein, aber die tatsächliche Attraktivität als Angriffsziel und die finanziellen Anreize wären vermutlich deutlich geringer als in der realen Welt
• Ich frage mich, warum traditionelle VMs beim Start so lange brauchen
  Wenn ich zum Beispiel unter Windows eine VM starte, warte ich mehrere Sekunden, bevor überhaupt irgendetwas losläuft
  Mit „es läuft nichts“ meine ich den Zustand vor dem Start eines User-Programms, noch bevor überhaupt der erste Firmware-Befehl ausgeführt wird
  Es gibt sogar lange Wartephasen noch bevor die virtuelle Festplattendatei geleert wird oder überhaupt ein VM-Fenster erscheint
  Mich würde interessieren, warum
  • Einen Linux-Kernel in unter einer Sekunde zu booten, ist mit Optimierung durchaus möglich
    Mit einem Standardkernel gibt es aber viele zeitaufwendige Vorgänge wie Timeouts oder Polling
    Auch auf UEFI-/CSM-Systemen kostet das Vorbereiten virtueller Hardware und das Initialisieren der Systemumgebung einiges an Zeit
    Bei WSL2 wird vermutlich ein spezieller Kernel genutzt, um unnötigen Overhead zu entfernen
    Auch das Starten diverser OS-Dienste, das Vorbereiten des Dateisystems, das Anlegen von Caches und die Netzwerkkonfiguration spielen hinein
    Im traditionellen Ablauf werden Bootloader → initramfs → Haupt-OS jeweils separat geladen
    Um Bootzeiten extrem zu verkürzen, nutzt man Verfahren wie bei Amazon Firecracker, bei denen ein vorinitialisiertes VM-Image direkt in den Speicher geladen wird
    Einführung in Firecracker MicroVM
    Unter Windows hängt die Bootgeschwindigkeit auch davon ab, welchen Hypervisor man verwendet, etwa HyperV
    HyperV-UEFI ist recht langsam, und viele Linux-Distributionen liefern keine optimierten minimalistischen Kernel aus
  • Dazu bräuchte man mehr Informationen darüber, welche VM-Software verwendet wird
    Bei VirtualBox ist das beschriebene Verhalten deutlich zu sehen, ältere Versionen hatten diese Verzögerung aber nicht
    Vielleicht ist das also keine grundsätzliche Grenze „traditioneller VMs“, sondern ein Problem dieser konkreten Software
  • Das muss nicht zwingend so sein
    Generell sind VMs langsam, weil sie auch unnötige Komponenten emulieren
    Wenn man einen Hypervisor primär auf Bootgeschwindigkeit auslegt und Legacy-Kompatibilität ignorieren kann, sind wie bei Firecracker Starts in 125 ms möglich
  • Unter Linux ist ein Hauptgrund für langsame VM-Speicherzuweisung, dass mehrere GB in 4-KB-Seiten allokiert werden
    Mit Zuweisung in 1-GB-Einheiten könnte es drastisch schneller werden
    Unter Windows gibt es vermutlich etwas Ähnliches
  • Es könnte schlicht ein VirtualBox-Problem sein
    Ich selbst habe auf Hyper-V schon Ubuntu 22 mit GUI per XRDP in 10 Sekunden und Ubuntu 22 Server per SSH in unter 3 Sekunden erreicht
• Es ist schon ironisch, in einem Kontext, in dem man nicht vertrauenswürdigen Code ausführen will, Installationsanweisungen zu sehen, die ein Remote-Installationsskript direkt in Bash pipen
  Ungeachtet dessen ist die Grundidee selbst äußerst interessant
  • Zuerst wusste ich nicht, was gemeint war, aber man kann das Installationsskript natürlich auch separat herunterladen und selbst prüfen
    Eine offizielle Distributionsmethode soll bald bereitstehen
• Dank fürs Teilen des Projekts, plus der Hinweis, dass man selbst der Ersteller von microsandbox ist
  Ziel war es, MicroVMs so einfach zu machen wie Docker-Container
  Bei Fragen jederzeit gern fragen
  • Ich nutze es gerade erfolgreich als Python-Bibliothek, würde die Sandbox aber gern über mehrere getrennte Aufrufe hinweg persistent halten
    Ich bekomme gelegentlich Fehler wie „Sandbox is not started. Call start() first“
    Das Muster in der offiziellen Doku ist async with, ich würde aber lieber pro Klasse einmal instanziieren und sie dann über mehrere Methoden hinweg weiterverwenden
    Mich würden empfohlene Vorgehensweisen oder Best Practices dafür interessieren
  • Ich baue gerade ein verteiltes/dezentrales Testnetz für Software auf, das Valet Network, und microsandbox scheint dafür sehr nützlich zu sein
    Mich interessiert, wie das Networking funktioniert
    Kann man zum Beispiel einschränken, dass eine microVM nur auf öffentliche IPs zugreifen darf?
    Also dass die microVM keine lokalen Netzwerk-IP-Adressen erreichen kann?
  • Wirklich tolles Projekt, großes Kompliment an appcypher
    Mich interessiert, ob die eingebaute MicroVM-Funktionalität ein OCI-Runtime-Interface bereitstellt
    Kann man sie statt runc/crun auch in Docker/Podman verwenden?
  • Ich habe das readme nur kurz überflogen, hätte aber ein paar Fragen mit mehr Erklärungsbedarf
    Wie kann es so schnell sein?
    Welche Trade-offs gibt es gegenüber traditionellen VMs?
    Gibt es mögliche Wege, auf denen die VM-Isolation geschwächt werden könnte?
    Kann man eine GUI starten?
    Ist das als eine Art neues Vagrant gedacht?
    Wie funktionieren Daten-Ein- und -Ausgabe?
  • Sieht sehr sauber aus
    Wenn ich es richtig verstehe, könnte man damit auch in Echtzeit Backends wie Server hochfahren?
    Die Liste der unterstützten Sprachen ist beeindruckend Liste der von microsandbox unterstützten Sprachen
    Ich wünschte, der Beitragenden-Leitfaden wäre ausführlicher contributor guide
• Es überrascht mich, wie viele ultraleichte, fast wegwerfartige VM-Optionen es in den letzten Jahren gegeben hat
  Früher habe ich VMs als langsam und schwerfällig erlebt
  Ich würde das gern mit Orbstack auf macOS vergleichen, vor allem mit der Funktion „Linux machines“
  Ich frage mich auch, ob Orb nur eine einzige VM wiederverwendet
  • Orbstack-Website
  • Orbstack-Dokumentation zu Linux machines
• Glückwunsch
  VMs in Millisekunden zu booten, ist ein enorm wichtiger Fortschritt
  Allerdings lässt sich Ähnliches auch mit CloudHypervisor und Firecracker umsetzen
  Container schlagen VMs bei der Runtime-Performance
  Langsam werden VMs vor allem durch die Emulation von IO-Geräten
  Gerade bei AI-Agent-Workloads dürfte der Overhead auf Anwendungsebene spürbar sein
  Mich würde interessieren, wie ihr Performance-Probleme angehen wollt
  • Völlig richtiger Punkt
    Microsandbox nutzt libkrun, und libkrun verwendet virtio-mmio für block, vsock und virtio-fs, um Performance-Overhead zu reduzieren
    Firecracker ist im Kern ähnlich, und das E2B-Projekt nutzt Firecracker, um agentische AI-Workloads zu bedienen
    Abgesehen von Dateisystemthemen gibt es aktuell keine größeren Performance-Verbesserungspläne
• Meinem Geschmack nach dehnt Containertechnologie das OS zu sehr aus
  Wer einmal den Befehl mount ausführt, versteht vermutlich, was ich meine
  Informationen, die eigentlich verborgen bleiben sollten, liegen plötzlich offen, wodurch die Nützlichkeit bisher einfacher Kommandos sinkt
  Noch gravierender ist, dass Nutzer interne Datenstrukturen direkt anfassen können
  Das fühlt sich an, als gäbe man den Nutzern sowohl Peek- als auch Poke-Rechte
  Die Container-Idee selbst ist gut, aber solange der Kernel nicht neu entworfen wird, ist die aktuelle Form nur ein Provisorium
  • Ich verstehe den Kommentar nicht ganz
    Könntest du erklären, was an mount innerhalb eines Containers so problematisch ist?
    Werden Host-Mounts dem Container tatsächlich offengelegt?
    Ich dachte, das passiert normalerweise nur, wenn man dem Container ausdrücklich etwa ein Volume anhängt
• Sieht so interessant aus, dass ich es sofort ausprobieren möchte
  Ich hatte auch schon viel Spaß mit dem CodeSandbox SDK, E2B usw.; mich interessieren die Unterschiede zu diesen Angeboten und die weitere Richtung
  Ich würde auch gern wissen, ob intern Firecracker verwendet wird
  • Microsandbox bietet keine Cloud-Lösung an
    Es ist für Self-Hosting gedacht
    Wie E2B soll es leicht machen, microVM-basierte Sandboxes in lokalen Umgebungen (Linux, macOS, Windows folgt) auszuführen und dann einfach in Produktion zu überführen
    Statt Firecracker kommt libkrun zum Einsatz
  • Am meisten interessierte mich gerade, ob Firecracker verwendet wird; genau das war mein Hauptpunkt
    Ich frage mich, wie es um Wartungsthemen und fortlaufende Security-Audits bei microVM-Lösungen steht
    Da Firecracker und das Einrichten von OCI-Images schwierig sind, begrüße ich das Auftauchen von Alternativen ausdrücklich
    Auch Kata Containers ist nicht leicht zu handhaben
• Bei Projekten dieser Art werde ich immer aufmerksam
  Der größte Vorteil von Containern ist, dass man sie schnell starten kann, ohne konkrete Ressourcen wie Plattengröße oder CPU-Kerne im Detail festzulegen
  Man kann den Zustand außerdem mit dem Image und dem Diff vergleichen und so sehen, welche Änderungen ein laufendes Programm am System vorgenommen hat
  Es wäre großartig, wenn sich mit einer so komfortablen Mini-VM sichereres Sandboxing umsetzen ließe
  Manchmal nutze ich auch bwrap, aber das ist kein Werkzeug, das sich besonders für die Kommandozeile eignet
  • Ressourcen wie Speicherplatz, CPU usw. kann man einmalig in einer YAML-Datei deklarieren
    Auch Templates oder remote/automatisch erzeugte Varianten sind möglich
• Das ist thematisch etwas daneben, aber ich arbeite gerade an einem Projekt, in dem ich unbedingt nicht vertrauenswürdigen JavaScript-Code ausführen muss
  Dank microsandbox habe ich Hoffnung, solchen Code sicher isoliert laufen zu lassen
  Selbst die Boot-Verzögerung von 200 ms ließe sich mit einem Pool aus Live-Sandboxes umgehen
  Dank OCI-Kompatibilität könnte man sogar die vollständige Sandbox-Umgebung bereitstellen
  Mich würde interessieren, ob das wirklich ein guter Anwendungsfall ist oder ob es bessere Alternativen gibt
  • runsc/gVisor könnte ebenfalls einen Blick wert sein
    Die runsc-Engine lässt sich auch in Docker/Docker Desktop ausführen
    Allerdings liegt gVisor bei Dingen wie paralleler Netzwerkverarbeitung leistungsmäßig nur bei etwa einem Drittel von Docker
  • Genau für solche Fälle ist microsandbox ideal
    Ich habe keine bessere Alternative gefunden und deshalb microsandbox selbst gebaut