sandboxd auf VPS selbst hosten: Setup und Voraussetzungen

Was sandboxd ist und was Sie beim eigenen Betrieb erhalten

Für den Self-Hosting-Betrieb von sandboxd benötigen Sie einen Linux-Server mit Docker und einen Domainnamen. Sie senden einen Prompt. Ein Coding-Agent erstellt eine echte Anwendung in einem isolierten Container. Anschließend ist diese Anwendung unter einer eigenen Preview-URL erreichbar. Prompt-to-App-Builder sind 2026 die sichtbarste Kategorie gehosteter Dienste. sandboxd läuft dagegen auf Ihrem VPS, steht unter der MIT-Lizenz, und der generierte Code liegt auf Ihrer eigenen Festplatte.

Das Design ist bewusst kompakt. Eine in Go geschriebene Control Plane steuert Docker. Traefik v3 routet jeden Preview-Hostnamen. SQLite speichert den Status. Jede Anwendung läuft in einem eigenen Container. Es gibt kein Kubernetes und keinen separaten Datenbankserver. Deshalb kann sandboxd überhaupt auf einem System mit 2 vCPU betrieben werden.

Vier Objekte bilden das gesamte Modell. Eine App ist das dauerhafte Projekt. Sie enthält den Namen, die Git-Metadaten und die Secrets. Eine Sandbox ist der Docker-Container, in dem die App ausgeführt wird. Eine App verweist jeweils auf eine Sandbox. Ein Workspace enthält die Dateien der App. Diese liegen auf dem Host und bleiben über den Container hinweg erhalten. Eine Task ist ein einzelner Prompt, der an den Agenten in der Sandbox übergeben wird. Wenn Sie eine Sandbox stoppen, wird Arbeitsspeicher freigegeben und die Dateien bleiben erhalten. Beim Löschen wird der Container entfernt. Die App kann anschließend in einer neuen Sandbox gestartet werden.

Wie unterscheidet sich sandboxd von Dify und OpenHands?

Diese drei Projekte werden verwechselt, weil sie alle ein LLM (Large Language Model) auf Ihrem Server ausführen. Sie erzeugen jedoch unterschiedliche Ergebnisse. Dify erstellt LLM-Anwendungen: Chat-Oberflächen, Retrieval-Pipelines und Workflows, die bei jeder Nutzung ein Modell aufrufen. Das Modell ist Bestandteil des fertigen Produkts. OpenHands arbeitet mit einem vorhandenen Repository: Sie geben Ihr Repository vor, und OpenHands liest Dateien, führt Befehle aus und schlägt Änderungen vor. sandboxd beginnt ohne vorhandenes Projekt. Es erstellt anhand eines Presets die Grundstruktur eines Projekts, baut es in einem neuen Container und stellt Ihnen eine URL zur Ansicht bereit. Das Ergebnis ist eine gewöhnliche React- oder FastAPI-Anwendung, die für den Betrieb kein Modell benötigt.

Wählen Sie daher danach aus, was am Ende vorhanden sein soll. sandboxd eignet sich, wenn Sie mit einem Satz beginnen und den erzeugten Code anschließend behalten möchten. Die beiden anderen Projekte eignen sich, wenn das Repository oder das modellgestützte Produkt bereits vorhanden ist.

Der andere Unterschied ist das Alter. Diesen Punkt sollten Sie abwägen, bevor Sie etwas Reales darauf aufbauen.

[
  {
    "tool": "sandboxd",
    "github_stars": "875",
    "forks": "50"
  },
  {
    "tool": "OpenHands",
    "github_stars": "83,091",
    "forks": "10,711"
  },
  {
    "tool": "Dify",
    "github_stars": "151,320",
    "forks": "23,886"
  }
]

sandboxd hat 875 Sterne, OpenHands 83,091 und Dify 151,320. Das Repository wurde am 3. Juni 2026 erstellt. Im August 2026 ist es daher zwei Monate alt. OpenHands stammt dagegen aus dem März 2024 und Dify aus dem April 2023. Release v0.1.0 wurde am 6. Juni 2026 veröffentlicht, v0.3.6 am 1. August 2026. Das Projekt bezeichnet sich selbst als Beta und weist darauf hin, dass 0.x-Releases die Kompatibilität beeinträchtigen können. Verstehen Sie diese Zahlen als Hinweis auf ein Abhängigkeitsrisiko und nicht als Bewertung der Qualität: Ein zwei Monate altes Projekt hatte erst zwei Monate Zeit, in denen andere Benutzer seine Fehler finden konnten.

Was der Server benötigt und was bei zu knappen Ressourcen ausfällt

Das Projekt gibt 2 vCPU und 4 GB RAM als ausreichende Einstiegskonfiguration an. Das trifft auf die Control Plane und eine kleine Sandbox zu. Für zwei Personen, die gleichzeitig Builds erstellen, reicht es nicht. Planen Sie den Speicher in Bestandteilen. Traefik und die Go-Control-Plane sind klein. Jede laufende Sandbox enthält eine vollständige Node- oder Python-Toolchain. Die maximale Auslastung entsteht bei einem npm install mit anschließendem Production-Build. Planen Sie für einen Server, auf dem einige Anwendungen dauerhaft laufen, 8 GB ein. Betrachten Sie Swap als Sicherheitsnetz und nicht als Kapazität. Ein Build, der auf Swap ausweicht, benötigt Minuten statt Sekunden.

Wenn der Speicher ausgeht, treten zwei unterschiedliche Fehler auf. Sie sehen völlig verschieden aus. Innerhalb einer Sandbox erreicht der Container die von sandboxd gesetzte harte --memory-Grenze. Der Kernel beendet dann den größten Prozess. Dadurch bricht der Build ohne hilfreiche Meldung des Agents ab. docker ps -a zeigt für diesen Container den Exit-Code 137 an. docker inspect meldet dafür "OOMKilled": true. Ein Node-Build, der auf diese Weise beendet wird, gibt häufig zuerst JavaScript heap out of memory aus.

Der zweite Fehler tritt auf dem Host auf. sandboxd führt einen Reaper aus, der Sandboxes beendet, wenn der freie Host-Speicher knapp wird. Auf einem kleinen Server kann eine Sandbox daher verschwinden, während Sie ihre Vorschau beobachten. Die Dateien bleiben erhalten. Die nächste Anfrage an die Vorschau-URL startet sie wieder. Eine Aufgabe, die beim Stoppen des Containers ausgeführt wurde, wird jedoch nicht fortgesetzt.

Das leisere Problem ist der Speicherplatz. Jede Anwendung besitzt ihren eigenen Workspace auf dem Host. Ein JavaScript-Projekt enthält einen node_modules-Baum mit mehreren hundert Megabytes. Zehn Anwendungen benötigen bereits mehrere Gigabytes für Abhängigkeiten, noch bevor die Images berücksichtigt werden. Beginnen Sie mit 40 GB und überwachen Sie den Speicherplatz:

docker system df
sudo du -sh /var/lib/sandboxed/workspaces

Das standardmäßige Datenverzeichnis ist /var/lib/sandboxed. Dabei wird das zusätzliche e geschrieben. Mit /var/lib/sandboxd erhalten Sie ein leeres Verzeichnis und verlieren fünf Minuten mit der Fehlersuche.

Eine festgelegte sandboxd-Version installieren

Docker Engine mit dem Compose-Plugin sowie git müssen zuerst auf dem Server installiert sein. Docker auf einem VPS installieren behandelt diesen Teil.

docker compose version
git --version

Beide Befehle müssen eine Version ausgeben. docker: 'compose' is not a docker command bedeutet, dass das alte eigenständige docker-compose-Binary installiert ist. Das Installationsprogramm erwartet das v2-Plugin.

Das Installationsprogramm ist ein Shell-Skript, das über das Netzwerk abgerufen wird. Lesen Sie es daher vor der Ausführung und legen Sie die Version fest.

curl -fsSL https://raw.githubusercontent.com/tastyeffectco/sandboxd/v0.3.6/install.sh -o install-sandboxd.sh
less install-sandboxd.sh
SANDBOXD_REF=v0.3.6 bash install-sandboxd.sh

SANDBOXD_REF ist die Git-Referenz, die das Installationsprogramm in $HOME/.sandboxd/src auscheckt. Standardmäßig wird main verwendet. Wenn die Variable nicht gesetzt ist, entspricht Ihre Installation dem Stand, der an diesem Morgen zuletzt zusammengeführt wurde. Das ist bei einem Projekt relevant, das allein im Juli 2026 sechs Releases veröffentlicht hat. Legen Sie die Version fest und aktualisieren Sie sie erst nach Prüfung des Changelogs.

Das Skript klont den Quellcode, erstellt die Images, startet den Stack mit docker compose up -d und gibt am Ende die URL der Konsole sowie ein API-Token aus. Speichern Sie dieses Token an einem sicheren Ort. Es ist das Zugangsmittel für eine API, die Docker als root steuert.

curl http://127.0.0.1:9090/healthz

Bei laufender Control Plane wird ok ausgegeben. Wenn keine Ausgabe erscheint, wurde der Stack nicht gestartet. Führen Sie docker compose ps aus ~/.sandboxd/src aus, um zu prüfen, welcher Dienst nicht läuft. Führen Sie anschließend docker compose logs sandboxd aus, um die Ursache zu ermitteln.

Die Konsole auf einem entfernten Server erreichen

Die Konsole wird über Traefik auf HTTP_PORT bereitgestellt. Standardmäßig ist das Port 80. Sie ist unter dem Hostnamen http://console.localhost erreichbar. Traefik verwendet den Hostnamen für das Routing. Wenn Sie stattdessen die IP-Adresse des Servers im Browser eingeben, passt sie zu keiner Regel und liefert einen 404-Fehler zurück. Bis Sie eine echte Domain konfigurieren, leiten Sie den Port weiter und behalten den Hostnamen bei:

ssh -L 8080:127.0.0.1:80 you@your-vps

Öffnen Sie anschließend http://console.localhost:8080 auf Ihrem Laptop. Unter Linux und macOS wird jeder Name mit der Endung .localhost zu 127.0.0.1 aufgelöst. Die Anfrage läuft daher mit dem richtigen Host-Header durch den Tunnel. Legen Sie beim ersten Aufruf das Passwort für die Konsole fest.

Geben Sie dem Agenten ein Modell

Im Basis-Image sind zwei Coding-Agenten enthalten: OpenCode und Claude Code. SANDBOXD_DEFAULT_AGENT entscheidet, welcher Agent eine Aufgabe ausführt, wenn die Aufgabe keinen Agenten angibt, und verwendet standardmäßig opencode. Wenn überhaupt kein Schlüssel hinterlegt ist, werden Aufgaben mit den kostenlosen, schlüssellosen Modellen von OpenCode Zen ausgeführt. Dadurch kostet Ihr erster Build nichts, und Sie können den gesamten Ablauf testen, bevor Kosten entstehen.

Hinterlegen Sie Ihren eigenen Schlüssel, wenn Sie ein leistungsfähigeres Modell verwenden möchten. Schlüssel werden an die Control Plane übertragen, niemals in die Sandbox: Sie werden verschlüsselt im Datenverzeichnis gespeichert und von einem Credential-Proxy über die Verbindung injiziert. Dadurch können weder der Agent noch der von ihm erstellte Code die Schlüssel lesen.

export API=http://127.0.0.1:9090
export SANDBOXD_TOKEN=sk_...                       # printed by the installer
export AUTH="Authorization: Bearer $SANDBOXD_TOKEN"

curl -s -XPOST $API/v1/agents/claude-code/api-key -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"api_key":"sk-ant-..."}'

Die Konsole bietet unter Settings, AI Agents dieselbe Funktion, einschließlich eines geführten OAuth-Ablaufs, wenn Sie statt eines API-Schlüssels ein Claude-Abonnement verwenden möchten. Das Standardmodell für jeden Agenten befindet sich im selben Bereich. Eine einzelne Aufgabe kann dieses Modell überschreiben.

Eine kleine Anwendung vollständig erstellen

Erstellen Sie die Anwendung, starten Sie ihre Sandbox und senden Sie anschließend eine Eingabe. Die IDs werden als JSON zurückgegeben. Der Quickstart extrahiert sie mit sed, sodass jq nicht installiert sein muss.

APP=$(curl -s -XPOST $API/v1/apps -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"name":"todo","runtime_preset":"react-vite"}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

SB=$(curl -s -XPOST $API/v1/apps/$APP/sandbox -H "$AUTH" \
  -H 'content-type: application/json' -d '{"ports":[3000]}' \
  | sed -E 's/.*"id":"([^"]+)".*/\1/')

echo "app=$APP sandbox=$SB"

Beide Variablen müssen eine ID enthalten. Ein leeres $SB bedeutet, dass die Sandbox nie gestartet wurde. Die häufigsten Ursachen sind, dass das Basis-Image noch erstellt wird oder der Host nicht genügend Arbeitsspeicher hat. Ein 401 anstelle einer ID bedeutet, dass das Bearer-Token falsch ist.

curl -s -XPOST $API/v1/sandboxes/$SB/tasks -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"prompt":"Add a todo list with a text input, an add button, and a delete button on each row. Keep the list in localStorage.","agent":"opencode"}'

Die Antwort enthält eine Task-ID. GET /v1/sandboxes/$SB/tasks/<task id> gibt das Ergebnis zurück. Der /events-Pfad für dieselbe Task ist ein Live-SSE-Stream (Server-Sent Events) der Aktionen des Agents. Die Konsole zeigt denselben Stream als Chat an.

Die Anwendung ist anschließend unter http://s-<sandbox id>-3000.preview.localhost erreichbar, wobei 3000 dem angeforderten Port entspricht. Wenn die Sandbox im Ruhezustand war, trifft die erste Anfrage auf Traefiks Catch-all. sandboxd startet den Container, wartet auf eine Antwort am Port und liefert eine kurze Aufwärmseite aus, die anschließend automatisch zu Ihrer Anwendung weiterleitet. Eine Vorschau, die diese Seite nicht verlässt, bedeutet, dass der Prozess innerhalb der Sandbox nicht auf dem in sandbox.yaml der Anwendung angegebenen Port lauscht.

Vorschauen unter einer echten Domain mit HTTPS bereitstellen

Jede Sandbox erhält einen eigenen Hostnamen. Daher deckt ein Wildcard-DNS-Eintrag alle Sandboxes ab. Verweisen Sie *.preview.yourdomain.com mit einem A-Record auf die IP-Adresse des Servers. Setzen Sie anschließend die Vorschauvariablen in .env unter ~/.sandboxd/src:

PREVIEW_DOMAIN=yourdomain.com
PREVIEW_ENTRYPOINT=websecure
PREVIEW_TLS=true
SANDBOXD_API_AUTH_DISABLED=false

Traefik benötigt die passende Gegenstelle: Aktivieren Sie den websecure-Entrypoint in traefik/traefik.yml und fügen Sie einen Zertifikatsresolver hinzu. Verwenden Sie die DNS-01-Challenge, weil ein Wildcard-Zertifikat dann alle Vorschau-Hostnamen abdeckt. Bei HTTP-01 müsste für jede neue Sandbox ein eigenes Zertifikat ausgestellt werden. Bei einem arbeitsreichen Nachmittag mit vielen Builds erreichen Sie dadurch schnell die Rate Limits von Let's Encrypt. Wildcard-Zertifikate mit der DNS-01-Challenge behandelt die DNS-Seite dieses Verfahrens.

cd ~/.sandboxd/src
docker compose up -d

Die Vorschau-URLs haben dann das Format https://s-<id>-3000.preview.yourdomain.com. Öffnen Sie Port 80 und 443 in der Firewall. Lassen Sie Port 9090 für das Internet geschlossen. Siehe dazu Grundlegende ufw-Firewallregeln. Denken Sie daran: Jeder, der einen Vorschau-Hostnamen erraten kann, kann die Anwendung laden. Behandeln Sie Vorschauen daher als öffentlich.

Wohin wird der generierte Code geschrieben, und können Sie ihn exportieren?

Auf dem Host liegt er unterhalb des Datenverzeichnisses. Jeder Workspace ist ein einfaches Verzeichnis unter /var/lib/sandboxed/workspaces/<id>/, das in den Container eingebunden wird. Die Dateien der Anwendung liegen innerhalb der Sandbox unter /home/sandbox/workspace/app. Der Status der Steuerungsebene befindet sich in einer einzelnen SQLite-Datei unter state/sandboxd.db. Verschlüsselte Zugangsdaten für Agents liegen unter agent-auth/. Nichts wird in einer Container-Schicht verborgen. Für ein Backup müssen Sie daher nur das Verzeichnis und diese Datenbankdatei kopieren. restic-Backups auf einem VPS übernimmt beides.

sudo ls /var/lib/sandboxed/workspaces
sudo du -sh /var/lib/sandboxed/workspaces/*

Der Git-Export ist integriert und nicht nachträglich ergänzt. Die API stellt zunächst Status und Diff zum Lesen bereit. Anschließend können Sie committen und pushen:

curl -s $API/v1/apps/$APP/git/status -H "$AUTH"

curl -s -XPOST $API/v1/apps/$APP/git/commit -H "$AUTH" \
  -H 'content-type: application/json' \
  -d '{"message":"todo list, first pass"}'

curl -s -XPOST $API/v1/apps/$APP/git/push -H "$AUTH" \
  -H 'content-type: application/json' -d '{"branch":"main"}'

Für ein privates Remote benötigen Sie ein persönliches Zugriffstoken. Sie legen es einmal in der Konsole unter Settings, Git credentials fest. Es wird verschlüsselt gespeichert und bleibt außerhalb der Sandbox. Der Agent kann es daher weder lesen noch unbemerkt damit pushen. Pushen Sie frühzeitig und regelmäßig. Bis dahin ist das Workspace-Verzeichnis die einzige Kopie des Codes. DELETE /v1/apps/<id> löscht es unwiederbringlich.

Was kostet ein Build in Modell-Tokens?

sandboxd erfasst Ihre Ausgaben nicht. Maßgeblich ist daher die Anzeige in der Konsole Ihres Providers. Die kostenlosen OpenCode-Zen-Modelle kosten nichts. Sie sind jedoch langsamer und weniger leistungsfähig als kostenpflichtige Modelle. Das zeigt sich bei allem, was über eine einfache Testanwendung hinausgeht, durch mehr Korrekturrunden.

Die Kostenstruktur hängt davon ab, wie die Agent-Schleife arbeitet. Bei jeder Runde wird der benötigte Kontext erneut gesendet. Die Kosten richten sich daher nach der Anzahl der Runden und nicht nach der Anzahl der Anwendungen. Ein einzelner erfolgreicher Prompt ist günstig. Fünfzehn Runden mit „korrigieren Sie jetzt die Abstände“ für ein Projekt mit fünfzig Dateien sind es nicht, weil die Dateiinhalte jedes Mal erneut übertragen werden. Eingabe- und Ausgabetokens werden unterschiedlich berechnet, und welche Kosten ein Coding-Agent pro Sitzung verursacht zeigt die realistische Größenordnung. Legen Sie beim Provider ein festes Ausgabenlimit fest, bevor Sie eine unbeaufsichtigte Schleife mit Zugriff auf Ihre Systeme starten.

Veraltete Sandboxes bereinigen

Der Idle-Reaper stoppt jede Sandbox, die länger als SANDBOXD_IDLE_THRESHOLD_SECONDS inaktiv war. Der Standardwert beträgt 2100 Sekunden oder 35 Minuten. Dadurch wird der Arbeitsspeicher freigegeben, während die Dateien erhalten bleiben. Die nächste Anfrage an die Preview-URL startet den Container wieder. Setzen Sie den Wert auf einem kleinen Server niedriger. 35 Minuten mit inaktiven Containern bedeuten 35 Minuten belegten Arbeitsspeicher, den Sie nicht anderweitig nutzen können.

Stoppen ist nicht dasselbe wie Löschen. An dieser Stelle füllen sich Datenträger unbemerkt. Eine gestoppte Sandbox besitzt weiterhin ihren Workspace und ihren Container. Das Entfernen der Sandbox bei Beibehaltung der Anwendung ist ein DELETE für die Sandbox. Dabei werden der Container und der Workspace entfernt. Wenn Sie die Anwendung entfernen, wird alles dauerhaft gelöscht.

curl -s -XPOST $API/v1/sandboxes/$SB/stop -H "$AUTH"     # frees RAM, keeps files
curl -s -XDELETE $API/v1/sandboxes/$SB -H "$AUTH"        # container and workspace gone
curl -s -XDELETE $API/v1/apps/$APP -H "$AUTH"            # app and everything under it

Nach einigen Wochen mit Experimenten zeigt docker system df möglicherweise mehr freigebbaren Speicherplatz für Images als erwartet. Jede Anwendung, die ihre eigene Toolchain abgerufen hat, hinterlässt Layer. docker image prune entfernt die verwaisten Layer. Prüfen Sie zuerst GET /v1/apps. Ein Image, auf das eine inaktive Sandbox noch verweist, ist kein ungenutztes Objekt.

Was die Container-Grenze leistet und was nicht

Jede Sandbox wird als nicht privilegierter Benutzer mit einem schreibgeschützten Root-Dateisystem, ohne Linux-Capabilities, mit gesetztem no-new-privileges, einer Speicherobergrenze und einer Prozessbegrenzung ausgeführt. Das Projekt benennt die Grenze dieser Isolation offen: Ein Linux-Container mit gemeinsamem Kernel ist eine starke Isolationsgrenze, aber eine schwache Sicherheitsgrenze. Eine Kernel-Schwachstelle kann zur Kompromittierung des Hosts führen.

Zwei Punkte erfordern Maßnahmen. Der ausgehende Netzwerkverkehr aus einer Sandbox ist im selbst gehosteten Build uneingeschränkt. Generierter Code kann daher das Internet, Ihr lokales Netzwerk und Cloud-Metadatenendpunkte erreichen. Im Quellcode gibt es ein nftables-Subsystem für ausgehenden Datenverkehr. Im portablen Docker-Compose-Build ist es jedoch deaktiviert. Die Einschränkungen müssen daher von der Firewall des Hosts kommen. Außerdem hat die API der Steuerungsebene faktisch Root-Rechte auf dem Host, weil sie den Docker-Socket steuert. Sie bindet standardmäßig an 127.0.0.1:9090. SANDBOXD_API_AUTH_DISABLED muss auf false gesetzt bleiben. Die API darf niemals im Internet veröffentlicht werden.

Wenn andere Personen Prompts an Ihren Rechner senden dürfen, reicht dieses Modell allein nicht aus. Das Projekt verweist auf gVisor mit SANDBOXD_RUNTIME=runsc. Dabei wird ein Kernel im Userspace zwischen die Sandbox und den Host geschaltet. Bei syscall-lastigen Aufgaben führt das zu einer ungefähr 1.7- bis 4-mal langsameren Ausführung. Die stärkere Lösung ist ein eigener Rechner pro Mandant. Das entspricht demselben Grundsatz wie beim Ausführen von Coding-Agents in einer kurzlebigen VM.

Sollten Sie auf einem zwei Monate alten Projekt aufbauen?

Für eine persönliche Build-Umgebung: ja, mit den offensichtlichen Vorsichtsmaßnahmen: Pinnen Sie SANDBOXD_REF, sichern Sie /var/lib/sandboxed und pushen Sie jede wichtige Anwendung in ein Git-Remote-Repository. Bei allem, womit Kunden arbeiten, sollten Sie auf Version 1.0 warten oder Ausfälle einplanen, denn die Maintainer weisen ausdrücklich darauf hin, dass sich bei 0.x grundlegende Dinge ändern können. Die Maintainer bieten außerdem seit August 2026 eine verwaltete Installation für 79 Dollar pro Monat an. Das sollten Sie berücksichtigen, wenn Sie beurteilen, ob das Projekt langfristig weitergeführt wird.

Das Risiko ist vertretbar, weil das Ergebnis zählt. sandboxd erzeugt eine gewöhnliche Anwendung in einem gewöhnlichen Git-Repository. Wenn die Entwicklung des Projekts ins Stocken gerät, behalten Sie den Code und verlieren nur den Wrapper. Das ist eine deutlich bessere Ausgangslage als bei einem gehosteten Builder, der Ihr Projekt besitzt. Einen breiteren Überblick darüber, was in diesem Jahr einen Platz auf Ihrem Server verdient, finden Sie unter was sich 2026 für Self-Hosting lohnt.

FAQ

Was sind die Mindestanforderungen an den Server für sandboxd?

Das Projekt gibt an, dass 2 vCPU und 4 GB RAM für den Start ausreichen. Damit sind die Control Plane, Traefik und eine kleine Sandbox abgedeckt. Wenn mehrere Anwendungen gleichzeitig laufen sollen, verwenden Sie 8 GB RAM und 40 GB Speicherplatz. Jede laufende Sandbox enthält eine vollständige Node- oder Python-Toolchain. Außerdem speichert jeder Arbeitsbereich seinen eigenen Abhängigkeitsbaum auf dem Datenträger. Wenn der Host knapp an Arbeitsspeicher wird, beendet der Pressure-Reaper von sandboxd Sandboxes, um Speicher freizugeben. Überschreitet ein Build die Speichergrenze seines Containers, beendet der Kernel den Prozess: docker ps -a zeigt dafür den Exit-Code 137 an.

Wie unterscheidet sich sandboxd von Dify oder OpenHands?

Die Systeme erzeugen unterschiedliche Ergebnisse. Dify erstellt Anwendungen, die zur Laufzeit ein Modell aufrufen, beispielsweise Chat-Oberflächen und Retrieval-Pipelines. OpenHands bearbeitet ein bereits vorhandenes Repository, führt Befehle aus und schlägt Änderungen am bestehenden Code vor. sandboxd erstellt aus einem Prompt ein vollständig neues Projekt, baut es in seinem eigenen Container und stellt es unter einer Vorschau-URL bereit. Das Ergebnis ist eine gewöhnliche Webanwendung, die für den Betrieb kein Modell benötigt.

Wo liegt der Code, den der Agent tatsächlich schreibt?

Im Dateisystem des Hosts, nicht in einem Container-Image. Jede Anwendung erhält unter /var/lib/sandboxed/workspaces/<id>/ ein Verzeichnis. Dieses wird in ihre Sandbox eingebunden, und die Dateien sind darin unter /home/sandbox/workspace/app sichtbar. Der Zustand der Control Plane liegt als einzelne SQLite-Datei unter state/ im selben Datenverzeichnis. Sie können über den Git-Tab der Konsole oder über die Endpunkte /v1/apps/<id>/git/commit und /git/push in ein Git-Remote committen und pushen. Ein Token für private Remotes wird von der Control Plane verschlüsselt gespeichert und nicht an die Sandbox übergeben.

Ist es sicher, sandboxd im Internet bereitzustellen?

Veröffentlichen Sie die Vorschau-URLs und die Konsole, aber niemals die API der Control Plane. Diese API steuert Docker auf dem Host und entspricht daher einem Zugriff mit root-Rechten. Aus diesem Grund wird sie standardmäßig an 127.0.0.1:9090 gebunden. Sandboxes dürfen im Self-Hosted-Build außerdem uneingeschränkt ausgehenden Netzwerkverkehr aufbauen. Der vom Agenten geschriebene Code kann dadurch Ihr lokales Netzwerk und Cloud-Metadatenendpunkte erreichen. Fügen Sie Host-Firewallregeln hinzu, wenn sich auf dem System schützenswerte Systeme im selben Netzwerk befinden. Bei Prompts von Personen, denen Sie nicht vertrauen, sollten Sie pro Tenant einen eigenen Host verwenden und sich nicht auf die Container-Grenze verlassen.