Dormice selbst hosten: Agent-Sandboxes auf einem VPS

Was Dormice ist und was es nicht ist

Dormice ist eine selbst gehostete Agent-Sandbox: ein Daemon auf einem Linux-VPS, den Sie besitzen und den Ihr Agent-Code über HTTP aufruft, um nicht vertrauenswürdigen Code in einem isolierten Container auszuführen. Ihr Programm fordert eine Sandbox anhand ihres Namens an, erhält unabhängig von ihrem vorherigen Zustand dieselbe Sandbox zurück, führt darin einen Befehl aus und liest die Ausgabe. Die Sandbox ist eine programmatisch verwaltete Ressource und kein Rechner, auf dem Sie sich anmelden.

Das unterscheidet sich davon, einem Agenten einen vollständigen Rechner zu überlassen. Eine wegwerfbare VM für einen Coding-Agenten ist ein System, auf das Sie sich per SSH verbinden, das der Agent beschädigen darf und das Sie anschließend löschen. Dormice liegt eine Ebene darunter: Es ist die Ausführungs-API, die Ihr Programm aufruft, wenn bereits Code vorhanden ist und ein sicherer Ausführungsort benötigt wird. Verwenden Sie die wegwerfbare VM, wenn ein vollständiger Rechner die Arbeitseinheit ist. Verwenden Sie Dormice, wenn ein einzelner exec-Aufruf die Arbeitseinheit ist und Sie davon täglich hundert ausführen möchten, ohne hundert VMs zu betreiben.

Das Projekt bezeichnet sich als E2B-kompatibel. E2B ist ein gehosteter Sandbox-Dienst, dessen Client-Bibliothek bereits von vielen Agent-Frameworks importiert wird. Dormice stellt dasselbe Protokoll unter eigenen URL-Präfixen bereit. Dadurch läuft eine Anwendung, die für das offizielle e2b-Paket entwickelt wurde, weiter, wenn Sie sie auf Ihren eigenen Server verweisen. Der Anwendungscode muss nicht geändert werden. Sie ändern zwei URLs und ein Präfix des API-Schlüssels.

Was „SQLite der Agent-Sandboxen“ in der Praxis bedeutet

SQLite ist eine Datenbank, die Sie einbetten, statt einen separaten Dienst zu betreiben. Dormice übernimmt diesen Vergleich direkt. Ein Daemon, eine SQLite-Datei für das Ledger, ein TCP-Port. Kein Kubernetes, keine separate Datenbank, kein Scheduler. Der Daemon setzt neben seinem Ledger eine Sperre und verweigert den Start, wenn Ledger und gefundene Maschine nicht zusammengehören können. Dadurch kann kein Split-Brain unbemerkt entstehen. Das Design ist auf eine Maschine ausgelegt. Wenn Sie eine Flotte über mehrere Hosts benötigen, empfiehlt die README ausdrücklich, etwas anderes zu wählen. Daran sollten Sie sich halten.

Die zweite Hälfte des Konzepts betrifft die Kosten. Für eine gehostete Sandbox wird jede Sekunde ihrer Laufzeit berechnet. Gehostete Sandboxen sind deshalb grundsätzlich kurzlebig. Dormice läuft auf Hardware, für die Sie bereits bezahlen. Seine Sandboxen bleiben dauerhaft bestehen und werden günstiger, je länger sie unverändert bleiben. Eine Sandbox fährt stufenweise herunter: aktiv, dann eingefroren, dann gestoppt und schließlich archiviert. Jeder acquire holt sie von der erreichten Stufe wieder zurück.

Das Einfrieren ist der entscheidende Teil. Dadurch bleibt es bezahlbar, die Sandbox jedes Agents dauerhaft aufzubewahren. Die folgenden Zahlen stammen aus den veröffentlichten Messungen des Projekts. Sie wurden auf dessen Hardware ermittelt, nicht auf Ihrer.

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

Eine inaktive Sandbox mit 1024 MiB Speicher belegt nach dem Einfrieren resident nur noch 5 MiB. Sie ist nach etwa 50 ms wieder verfügbar. Prozesse werden an Ort und Stelle angehalten und fortgesetzt. Ein langlebiger Agent behält daher seinen Shell-Zustand und seine unvollständige Arbeit über das Einfrieren hinweg. Reproduzieren Sie das Verhalten auf Ihrem eigenen Host, bevor Sie darauf eine Kapazitätsplanung aufbauen.

Voraussetzungen auf dem Host vor der Installation

Der Host muss Ubuntu oder Debian auf x86_64 ausführen, und das Installationsprogramm benötigt root. Der Daemon verwendet auch zur Laufzeit root, weil er Loop-Mounts erstellt und cgroups schreibt.

Die Sandboxes laufen unter Docker mit gVisor. gVisor ist eine Container-Runtime, die einen Kernel im Userspace zwischen den Container und den Host-Kernel setzt. Sie stellt die runsc-Runtime bereit, die jede Sandbox verwendet. Node 22 oder neuer führt den Daemon aus. Das Installationsprogramm bringt eine eigene Kopie mit, sodass das System-Node unverändert bleibt.

Swap muss vorhanden sein, und vm.swappiness muss 100 sein. Das ist keine Tuning-Empfehlung, sondern eine funktionale Voraussetzung. Beim Einfrieren wird der Speicher einer inaktiven Sandbox in den Swap ausgelagert. gVisor hält den Sandbox-Speicher als Shared Memory, und der Kernel lagert Shared Memory bei der standardmäßigen Swappiness nicht aus. Das Projekt hat beim Standardwert 0 Bytes zurückgewonnen, bei 100 dagegen 99.5 Prozent. Prüfen Sie den Wert, den der Kernel tatsächlich verwendet, da manche Cloud-Images vm.swappiness = 0 in einer Datei festlegen, an die Sie vermutlich nicht denken würden.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness sollte vm.swappiness = 100 ausgeben, und swapon --show sollte eine Swapfile auflisten. Wenn die Swappiness 0 ausgibt, ist jedes Einfrieren wirkungslos. Sie zahlen dann für jede inaktive Sandbox weiterhin den vollen Speicherbedarf.

Dormice unter Ubuntu installieren

Die dokumentierte Installation besteht aus einer Pipe in bash:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

Laden Sie das Skript herunter und lesen Sie es, bevor Sie es ausführen. Das Skript läuft als root und verändert Ihren Host: Es installiert Docker, falls Docker fehlt, lädt gVisor und Caddy mit Prüfsummenprüfung herunter, erstellt eine Swap-Datei, schreibt systemd-Units und fügt Firewall-Regeln hinzu.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

--swap-gb legt die Größe der Swap-Datei fest. Der Standardwert ist 16, was für einen kleinen VPS viel belegten Speicherplatz bedeutet. --mirror cn leitet die Downloads auf Mirrors um, die vom chinesischen Festland aus erreichbar sind. Wenn Sie das Installationsprogramm erneut ausführen, aktualisiert es den Code und korrigiert Abweichungen. Das API-Token wird dabei nie erneuert.

Der Code wird nach /opt/dormice installiert, die Konfiguration nach /etc/dormice/env geschrieben, Sandbox-Daten werden in /var/lib/dormice abgelegt, und die Befehle dormice und dor werden in /usr/local/bin installiert. Das Installationsprogramm erzeugt das API-Token während der Installation und schreibt es mit dem Modus 600 nach /etc/dormice/env.

Es gibt kein getaggtes Release, auf das Sie die Installation festlegen können. Am 4. August 2026 enthielt das Repository keine git-Tags und keine GitHub-Releases. Deshalb klont das Installationsprogramm main, und Sie erhalten den Stand, der an diesem Morgen zuletzt hinzugefügt wurde. Eine Version festzulegen bedeutet daher, den tatsächlich installierten Commit zu dokumentieren.

git -C /opt/dormice rev-parse HEAD

Speichern Sie diesen Hash zusammen mit Ihren Deploy-Notizen. Wenn ein Upgrade etwas beschädigt, ist dieser Commit Ihre einzige Möglichkeit zur Rückkehr, weil es keine Versionsnummer gibt, die Sie angeben können.

Am Ende führt das Installationsprogramm dor doctor aus. Dabei handelt es sich um eine schreibgeschützte Host-Prüfung, die echte gVisor-Container startet, um die Funktionsfähigkeit der Laufzeitumgebung zu bestätigen, statt lediglich eine Paketliste zu prüfen. Führen Sie die Prüfung erneut aus, wenn sich der Daemon nicht erwartungsgemäß verhält.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice sollte active ausgeben. Wenn failed ausgegeben wird, enthält journalctl -u dormice -n 50 den Grund. Ein fehlgeschlagener Start hängt meistens mit der Swap-Datei oder einer gVisor-Voraussetzung zusammen, nicht mit dem Daemon selbst.

Das Installationsprogramm installiert außerdem Caddy auf dem Host. Prüfen Sie daher, welche Ports abgehört werden, bevor Sie die Firewall-Konfiguration als abgeschlossen betrachten.

sudo ss -lntp

Der Daemon bindet an 127.0.0.1:3676. Diese Bind-Adresse lässt sich absichtlich nicht ändern. Der Zugriff von Ihrem Laptop aus muss ausdrücklich eingerichtet werden. Die einfachste Variante ist ein SSH-Tunnel.

ssh -L 3676:127.0.0.1:3676 root@your-server

Wenn der Tunnel geöffnet ist, erreichen Sie die Webkonsole auf Ihrem Laptop unter http://127.0.0.1:3676/console. Melden Sie sich einmal mit dem Token an. Danach wird es als httpOnly-Session-Cookie verwendet, sodass das Token selbst nie an einem Ort gespeichert wird, den die Seite lesen kann. Die Connect-Seite zeigt Client-Snippets zum Kopieren und Einfügen an, die bereits auf Ihren eigenen Endpunkt verweisen.

Eine Sandbox erstellen und Code darin ausführen

Ein Vorgang erstellt eine Sandbox: acquire. Er ist idempotent. Derselbe Schlüssel liefert daher immer dieselbe Sandbox. Dabei wird sie bei Bedarf erstellt, aufgeweckt, gestartet oder wiederhergestellt. Jeder andere Verb antwortet für einen Schlüssel, den es noch nicht kennt, mit 404. Die dor CLI hat kein acquire-Verb. Ihre erste Sandbox erstellen Sie daher über die Konsole oder eine Clientbibliothek.

Der Weg über die Konsole ist am schnellsten. Öffnen Sie /console über den Tunnel und erstellen Sie eine Sandbox mit dem Namen my-agent. Danach arbeitet die CLI damit.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

dor sandbox ls listet jede Sandbox mit ihrem Lebenszyklusstatus auf. Damit können Sie beobachten, wie eine Sandbox von active zu frozen wechselt. dor sandbox exec gibt die Version von Python 3.12 aus, weil das Standard-Image Ubuntu 24.04 mit Python 3.12, Node 24, git und ripgrep enthält. Ein Authentifizierungsfehler bedeutet dagegen, dass die kopierte Tokenzeile den Variablennamen enthielt.

Dateien werden mit dor sandbox push my-agent ./script.py übertragen und unter /home/user/script.py abgelegt. dor sandbox pull my-agent notes.txt holt eine Datei zurück. Die nativen Datei-Verb unterstützen pro Datei höchstens 16 MiB. Die E2B-Dateischnittstelle streamt dagegen. Dadurch ist nur das Festplattenkontingent der Sandbox begrenzend.

Nur das Löschen entfernt Daten. Es zeigt außerdem beispielhaft das Alter des Projekts: Die Haupt-README und der mitgelieferte Agent-Skill dokumentieren dor sandbox destroy <key>, während die README des CLI-Pakets dor sandbox release <key> dokumentiert. Führen Sie dor sandbox --help in Ihrer eigenen Build-Version aus und verlassen Sie sich stattdessen auf dieses Ergebnis.

Ihren vorhandenen E2B-Code auf Ihren eigenen Server ausrichten

Das ist der entscheidende Vorteil. Das offizielle e2b-Paket von npm kommuniziert unverändert mit Dormice. Führen Sie dies bei geöffnetem SSH-Tunnel auf Ihrem Laptop aus. Dadurch lauscht auf dem Server kein zusätzlicher Dienst.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

Bei einer erfolgreichen Ausführung werden der Exit-Code 0 und 42 ausgegeben. Der API-Schlüssel ist Ihr Dormice-Token mit dem Präfix e2b_. Dieses Format erwartet die Kompatibilitätsschicht.

Die Kompatibilität ist kein Stub. Streaming von stdout und stderr, Hintergrundbefehle, ein interaktives PTY, signierte Upload- und Download-URLs, die Überwachung von Verzeichnissen und ein Port-Proxy werden über das offizielle Paket gegen einen echten Docker- und gVisor-Daemon getestet. Dies geschieht in der End-to-End-Suite des Projekts. Vor einer Migration produktiver Workloads sind einige Abweichungen wichtig:

• Template-Builds sind nicht implementiert. Ein Template ist ein Docker-Image, das Sie selbst erstellen und mit dor template add registrieren. Sandbox.create('name') löst dieses Image auf. Für einen nicht registrierten Namen wird 404 zurückgegeben, statt ein vorhandenes Template vorzutäuschen.
• Sandboxes, die über die E2B-Schnittstelle erstellt werden, erhalten echte Deadlines, weil die E2B-Semantik dies voraussetzt. Für Sandboxes, die über die native API erstellt werden, werden niemals Deadlines gesetzt.
• Eine eingefrorene Sandbox behält ihre Prozesse bei und setzt sie an ihrer bisherigen Ausführungsposition fort. Pause und Resume bedeuten hier daher nicht das Stoppen und den anschließenden Kaltstart, den Sie möglicherweise gewohnt sind.

Was die Sandbox verhindert und was nicht

gVisor fängt die Systemaufrufe des Containers im Userspace ab und verarbeitet sie selbst. Der Code in der Sandbox kommuniziert daher nicht direkt mit dem Kernel Ihres Hosts. Innerhalb der Sandbox läuft alles als nicht privilegierter Benutzer mit der UID 1000. Diese Kombination deckt den normalen Fall ab: Ein generiertes Skript, das rm -rf / ausführt, den Datenträger füllt oder so lange neue Prozesse forkt, bis etwas ausfällt, beschädigt seine eigene Sandbox und bleibt dort.

Das wird nicht verhindert. Für jeden dieser Punkte sind Sie selbst verantwortlich.

• Eine Sandbox verfügt über ausgehenden Netzwerkzugriff. Generierter Code kann beliebige Daten herunterladen und beliebige gefundene Daten übertragen. Die Netzwerksicherheit des Installers deckt zwei konkrete Punkte ab: Sie verwirft Containerverkehr zum Cloud-Metadatendienst unter 169.254.0.0/16. Dort stellt eine Cloud Instanzanmeldedaten für alles bereit, was diesen Dienst erreichen kann. Außerdem deaktiviert sie den Datenverkehr zwischen Containern mit "icc": false in Docker's daemon.json. Alles andere bleibt erlaubt. Lesen Sie sudo iptables -S DOCKER-USER und ergänzen Sie eigene DROP-Regeln für private Bereiche, die eine Sandbox nicht erreichen darf.
• Docker fügt seine eigenen Regeln vor Ihrer Firewall ein. Daher kann ein veröffentlichter Container-Port aus dem Internet antworten, obwohl ufw darauf besteht, dass er geschlossen ist. Lesen Sie wie Docker Ports an ufw vorbei veröffentlicht und die Grundlagen der ufw-Firewall für einen VPS, bevor Sie auf diesem Host etwas veröffentlichen.
• gVisor ist ein Kernel im Userspace und kein Hypervisor. Das ist ein bewusst eingegangener Kompromiss. Für das Einfrieren müssen Sandboxes Prozesse sein, und eine Voraussetzung von KVM würde verhindern, dass die Software überall installiert werden kann. Wenn Ihr Bedrohungsmodell Hardware-Virtualisierung erfordert, verwenden Sie eine Isolation der Firecracker-Klasse und akzeptieren Sie den damit verbundenen betrieblichen Aufwand.
• Das API-Token bildet die gesamte Sicherheitsgrenze auf der Clientseite. Alles, was DORMICE_API_TOKEN besitzt, kann jede Sandbox auf dem Rechner erstellen, lesen und löschen. Geben Sie dem Agent-Prozess einen eigenen Benutzer mit den geringsten erforderlichen Rechten auf dem VPS und behandeln Sie das Token wie einen SSH-Schlüssel. Die Vorgehensweisen aus Claude Code sicher auf einem VPS ausführen lassen sich direkt übertragen.

Der Daemon selbst läuft als root auf Ihrem Host. gVisor schützt den Host vor dem Code innerhalb einer Sandbox. Den Host schützt jedoch nichts vor dem Daemon oder vor Personen, die dessen Token besitzen. Der Rechner, auf dem Dormice läuft, sollte daher ausschließlich diese Aufgabe übernehmen. Wenn Ihr Agent außerdem über MCP (Model Context Protocol) auf Tools zugreift, betreiben Sie diese MCP-Server aus demselben Grund auf einem separaten VPS.

Wie viele Sandboxes passen in 4 GB und 8 GB?

Zwei Dinge verbrauchen Speicher: der Grundbedarf des Hosts und der Arbeitssatz jeder Sandbox, die aktuell aktiv ist. Reservieren Sie etwa 1 GB für Ubuntu, Docker und den Daemon. Teilen Sie dann den verbleibenden Speicher durch den tatsächlichen Bedarf einer Sandbox. Eine Sandbox, in der ein Python-Skript einige Dateien liest, benötigt etwa 200 bis 300 MiB. Eine Sandbox, in der ein Compiler oder eine vollständige Testsuite läuft, kann 1 GiB überschreiten.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

Ein VPS mit 4 GB hält etwa 6 gleichzeitig aktive Sandboxes, wenn jede 512 MiB verwendet, oder 3, wenn jede ein vollständiges GiB verwendet. Bei einem VPS mit 8 GB sind es 14 und 7. Das sind Obergrenzen für gleichzeitig ausgeführte Arbeiten und keine Benchmarkwerte. Sie ergeben sich aus einer Berechnung. Überwachen Sie daher free -m, während Ihre eigene Last ausgeführt wird.

Eingefrorene Sandboxes werden durch den Swap statt durch den RAM begrenzt. Das ist der zentrale Zweck dieses Designs. Eine eingefrorene Sandbox, die 1 GiB belegt hat, hält ungefähr diese Menge im Swap und fast nichts im Arbeitsspeicher. Die standardmäßige 16-GB-Swapdatei des Installers kann daher etwa 16 solcher Sandboxes aufnehmen. Danach müssen sie in den gestoppten Zustand wechseln, in dem sie nur noch Speicherplatz belegen. Der Speicherplatz ist hier die tatsächliche langfristige Grenze: Jede Sandbox behält ihr Dateisystem. Einige Dutzend Agents, die jeweils ein node_modules-Verzeichnis enthalten, füllen ein kleines Volume lange bevor der Speicherverbrauch relevant wird.

Einfrieren, Stoppen, Archivieren: die Lifecycle-Einstellungen

Die Standardeinstellungen sind: nach 10 Minuten Inaktivität einfrieren, nach 3 Tagen stoppen und nach 7 Tagen archivieren, wenn die Archivierung konfiguriert ist. Wenn Sie stopAfterSeconds auf null setzen, erhalten Sie einen dauerhaft aktiven Agenten: Er kann bei Inaktivität eingefroren werden, führt aber nie einen Cold Start aus.

Die Archivierung ist optional, und der Daemon weist darauf hin. Setzen Sie die vier Variablen DORMICE_S3_*. Dann wird die Festplatte einer gestoppten Sandbox mit tar und zstd gepackt, in einen beliebigen S3-kompatiblen Bucket übertragen und lokal freigegeben. Dieser Bucket kann ein von Ihnen selbst gehosteter MinIO-Bucket auf einem anderen Rechner sein. Wenn Sie die Variablen nicht setzen, bleiben Sandboxes dauerhaft im Status stopped. Eine Policy, die eine Archivierung verlangt, wird dann abgelehnt und nicht stillschweigend ignoriert. Wiederherstellungen bleiben sichtbar: Der nächste acquire-Aufruf liefert sofort den Status restoring und einen Fortschrittswert. Sobald die Festplatte wiederhergestellt ist, wechselt der Status zu ready.

Sollten Sie schon darauf setzen?

Klare Antwort: nicht für etwas, das Sie nicht neu erstellen können. Der erste Commit im Repository ist vom 8. Juli 2026. Am 4. August 2026 weist das Projekt 446 Stars, 37 Forks und eine Apache-2.0-Lizenz auf. Eine getaggte Release-Version gibt es überhaupt nicht. Die Statuszeile der README sagt selbst, dass nichts für den Produktivbetrieb bereit ist.

Diese Kombination erzeugt ein spezifisches Risikoprofil. Der Code kann sich unter Ihnen ändern, weil der Installer main verfolgt. Die Schnittstelle ist noch nicht stabil. Genau deshalb haben zwei Dateien im selben Repository für das Verb zum Löschen unterschiedliche Bezeichnungen. Außerdem kann ein vier Wochen altes Projekt jederzeit eingestellt werden, weil keine Lizenzklausel jemanden zur Weiterentwicklung verpflichtet.

Die E2B-Kompatibilität macht dieses Risiko beherrschbar. Ihre Anwendung spricht mit einem Protokoll, für das es eine gehostete Implementierung gibt. Wenn Dormice nicht weiterentwickelt wird, ändern Sie zwei URLs und können weiterarbeiten. Schreiben Sie Ihren Agenten gegen die E2B-Schnittstelle statt gegen die native API. So bleibt diese Ausweichmöglichkeit erhalten. Das native @dormice/sdk-Paket ist ebenfalls noch nicht auf npm verfügbar. Für seine Verwendung müssen Sie es aus dem Repository erstellen. Das ist ein weiterer Grund, zunächst den kompatiblen Weg zu wählen.

Betreiben Sie es dort, wo ein Verlust vertretbar ist. Erstellen Sie den Host aus einem Skript neu. Halten Sie das Token aus jeder Eingabeaufforderung und jedem Commit heraus. Sichern Sie alles, was Sie behalten möchten, nach Ihrem eigenen Backup-Zeitplan außerhalb der Sandboxes.

FAQ

Ist Dormice für den Produktivbetrieb bereit?

Nein, und das Projekt weist selbst darauf hin. Die Statuszeile der README besagt, dass dort derzeit noch nichts für den Produktivbetrieb bereit ist. Außerdem ist das Repository am 4. August 2026 etwa vier Wochen alt und enthält keine Git-Tags und keine Releases. Daher gibt es keine Versionsnummer, auf die Sie festschreiben können. Das Installationsprogramm klont den main-Branch. Dadurch erhalten Sie bei jedem Lauf den neuesten Commit. Notieren Sie git -C /opt/dormice rev-parse HEAD nach jeder Installation und speichern Sie alle wichtigen Daten außerhalb der Sandboxes.

Wie unterscheidet sich Dormice davon, meinem Agenten eine temporäre VM zu geben?

Eine temporäre VM ist ein Rechner mit SSH, den Sie für eine Sitzung erstellen und anschließend löschen. Dormice ist eine Execution-API: Ihr Programm ruft acquire und danach exec auf und erhält stdout sowie einen Exit-Code zurück. Dazwischen gibt es keine Shell-Sitzung. Eine VM eignet sich für einen Menschen oder einen Agenten, der für eine gewisse Zeit einen vollständigen Rechner benötigt. Dormice eignet sich für eine Anwendung, die mehrmals täglich generierten Code ausführt und bei jedem Lauf nicht den Aufwand für Einrichtung und Abbau eines vollständigen Rechners betreiben möchte.

Funktioniert das offizielle E2B SDK wirklich ohne Codeänderungen?

Ja, mit Änderungen an der Konfiguration. Setzen Sie apiUrl und sandboxUrl auf /e2b/api und /e2b/envd Ihres Daemons und übergeben Sie Ihr Dormice-Token mit dem Präfix e2b_ als API-Key. Befehlsausführung, PTY-Sitzungen, Dateiübertragung, signierte URLs und der Port-Proxy werden alle durch die End-to-End-Test-Suite des Projekts über das offizielle Paket abgedeckt. Der Aufbau von Templates ist die wesentliche Lücke: e2b template build ist nicht implementiert. Ein Template ist daher ein Docker-Image, das Sie erstellen und mit dor template add registrieren.

Wie viele Sandboxes passen auf einen 4-GB-VPS?

Etwa 6 gleichzeitig aktive Sandboxes, wenn jede Sandbox 512 MiB verwendet. Bei jeweils einem vollständigen Gibibyte sind es etwa 3. Dabei sind ungefähr 1 GB für das Betriebssystem, Docker und den Daemon reserviert. Eingefrorene Sandboxes werden stattdessen durch den Swap begrenzt. Die standardmäßige 16-GB-Swap-Datei des Installationsprogramms kann etwa 16 Sandboxes aufnehmen, die jeweils ein Gibibyte belegt haben. Messen Sie die Werte unter realer Last mit free -m selbst, da eine Sandbox, die eine Testsuite ausführt, ein Mehrfaches des Speicherbedarfs einer Sandbox verwendet, die nur ein kleines Skript ausführt.

Warum muss bei Dormice vm.swappiness auf 100 gesetzt werden?

Beim Einfrieren einer Sandbox wird deren ungenutzter Speicher in den Swap ausgelagert. gVisor hält den Speicher der Sandbox als Shared Memory. Der Linux-Kernel lagert Shared Memory beim standardmäßigen Swappiness-Wert nicht aus. Daher wird beim standardmäßigen Wert durch das Einfrieren kein Speicher freigegeben, und die Sandbox belegt weiterhin den vollständigen Speicher. Das Projekt hat beim Standardwert 0 Byte und bei einem Wert von 100 eine Freigabe von 99,5 Prozent gemessen. Prüfen Sie den effektiven Wert mit sysctl vm.swappiness, statt Konfigurationsdateien zu lesen, da einige Cloud-Images den Wert 0 verwenden.