Sprites – zustandsbehaftete Sandbox

 (fly.io)
5 Punkte von GN⁺ 2026-01-11 | 1 Kommentare | Auf WhatsApp teilen
  • Fly.io hat mit „Sprites“ ein neues Konzept eines persistenten Cloud-Computers vorgestellt, das bestehende Einweg-Sandboxes ersetzen soll
  • Erstellung in 1–2 Sekunden, mit automatischem Wechsel in den Leerlauf, Wiederherstellung von Checkpoints und 100 GB dauerhaftem Speicher
  • Es wird darauf hingewiesen, dass das bisherige zustandslose Containermodell für KI-Agenten (z. B. Claude) ineffizient ist, und die Notwendigkeit einer persistenten Umgebung betont
  • Als reales Beispiel wird vorgestellt, wie Claude auf einem Sprite eine SQLite-basierte Go-App (MDM) aufgebaut und über längere Zeit betrieben hat
  • Fazit des Artikels: „Die Ära der Sandboxes ist vorbei, die Ära der Wegwerf-Computer hat begonnen“

Sprites: persistente Cloud-Computer - https://sprites.dev/

  • Fly.io bezeichnet das bisherige schreibgeschützte Sandbox-Modell als veraltet und stellt als Ersatz „Sprite“ vor
    • Mit dem Befehl sprite create wird innerhalb von 1 Sekunde eine Linux-Root-Shell erzeugt
    • Sprites verfügen über 100 GB dauerhaften Speicher und können bei Inaktivität automatisch in den Energiesparmodus wechseln und später wiederhergestellt werden
  • Mit sprite-env checkpoints create lässt sich sofort ein Checkpoint des gesamten Systems erstellen
    • Mit sprite checkpoint restore v1 erfolgt die Wiederherstellung innerhalb von 1 Sekunde; dadurch wird Versionsverwaltung auf Systemebene wie bei Git möglich
  • Wichtige Merkmale
    • Hunderte Instanzen lassen sich unkompliziert erzeugen
    • Automatische Abrechnungsunterbrechung (Idle metering) senkt die Kosten
    • Anycast-Netzwerkanbindung stellt HTTPS-URLs bereit
    • Vollständige Persistenz bleibt erhalten, bis eine explizite Löschung erfolgt

Claude und die Grenzen zustandsloser Container

  • Die meisten Cloud-Umgebungen basieren derzeit auf zustandslosen (stateless) Containern
    • Daten werden nur in externen Datenbanken gespeichert, um Einfachheit und Skalierbarkeit zu sichern
  • Für KI-Agenten wie Claude ist diese Struktur jedoch ungeeignet
    • Sie zeigen Verhalten, bei dem sie Container umgehen oder aus ihnen ausbrechen wollen, und verlangen Zugriff auf den gesamten „Computer“
  • Als Definition eines „Computers“ werden Persistenz (durability) und eine Umgebung, die nach der Arbeit nicht verschwindet, genannt
    • Heutige Sandboxes fehlen beide Eigenschaften

Einfachheit (Simple Wins)

  • In einer persistenten Umgebung ist ein Neuaufbau der Entwicklungsumgebung (node_modules usw.) nicht nötig
    • Die Branche investiert zig Millionen Dollar in Snapshot-Technologien, um genau dieses Problem zu lösen
  • Es gibt reale Infrastrukturen, in denen Agenten auf S3, Redis, RDS und andere externe Ressourcen zugreifen
    • Das ist ein Behelf, um das Nicht-Persistenz-Problem von Sandboxes zu umgehen
  • Sprites beseitigen diese Komplexität und bieten eine Umgebung, in der geschriebene Dateien einfach erhalten bleiben
  • Als Beispiel wird das Projekt Phoenix.new genannt, in dem ein auf Fly Machines basierender Agent App-Logs direkt beobachtet und Fehler behebt

Galaxy Brain Win: Verschmelzung von Entwicklung und Betrieb

  • Der Autor hat zusammen mit Claude eine SQLite-basierte Go-App (MDM) auf einem Sprite aufgebaut
    • Über eine Anycast-URL wurde sie als MDM-Registrierungs-URL genutzt
    • Claude hat sogar die Einrichtung des APNS-Zertifikats automatisch erledigt
  • Diese App läuft seit mehr als einem Monat stabil auf einem Sprite
    • Damit wird das Konzept „dev is prod, prod is dev“ verwirklicht
  • Die meisten Apps brauchen keine massiven Zugriffszahlen; wichtiger seien personalisierte persistente Apps
    • In einer solchen Struktur können Nutzer Funktionen direkt anfordern und sofort umgesetzt bekommen

Das Ende der Sandboxes und die Ära der Wegwerf-Computer

  • Fly.io entwickelt seit Langem eine horizontal skalierende Micro-VM-Plattform, doch das Sandbox-Modell stößt an seine Grenzen
  • Sprites ähneln Fly Machines, bieten aber einen neuen Storage-Stack und eine neue Orchestrierungsstruktur und benötigen kein Dockerfile
  • Zentrale Frage:

    „Wenn man einen Agenten ausführen kann, möchte man dann nicht lieber eine sofort aufrufbare EC2-Instanz statt einer schreibgeschützten Sandbox?“

  • Schlussfolgerung: „Die Ära der Sandboxes ist vorbei, die Ära der Wegwerf-Computer hat begonnen.“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-11
Hacker-News-Kommentare

  • Anfangs war ich wirklich begeistert, aber wie bei anderen Erfahrungen mit der Fly API wirkte auch das hier wieder kaputt
    Wenn man die Beispielbefehle aus der Doku unter https://sprites.dev/api genau so ausführt, kommt als Antwort {"error":"name is required"}
    Verwendet man aber den vollständigen Request-Body aus der Create-Sprite-Doku, funktioniert es korrekt
    Für einen persönlichen Workflow könnte ich solche rauen Kanten noch akzeptieren, aber bei CI/CD, das ein ganzes Team betrifft, würde ich zögern
    Ich hätte eine Bitte an das Fly-Team — prüft die Beispiele in der Doku unbedingt per automatisierten Tests

    • Vermutlich liegt es daran, dass der Content-Type-Header fehlt
    • Es wäre gut, wenn man solche Probleme in einem öffentlichen Issue-Tracker melden könnte. Es muss nicht unbedingt GitHub sein, aber es braucht einen Ort, an dem Nutzer öffentlich darüber diskutieren können

  • https://sprites.dev/ ist wirklich spannend
    Es löst auf einmal zwei Probleme, die ich mag

    1. Sandbox für Entwicklungsumgebungen — eine günstige und persistente VM-Umgebung, in der man Claude Code oder Codex CLI sicher ausführen kann
    2. Sandbox API — nicht vertrauenswürdiger Code lässt sich in einer isolierten Umgebung mit einem simplen JSON-API-Aufruf ausführen
      Es gibt auch Snapshot-Funktionen, sodass man nach der Ausführung leicht auf einen früheren Zustand zurückgehen kann
      Mehr Details habe ich in meinem Blog zusammengefasst → Beitrag auf simonwillison.net

  • Philosophisch mag ich Fly und war schon früh Kunde
    Aber bei allem rund um die CLI habe ich immer noch Angst. Selbst wenn ich sie nur alle paar Wochen nutze, schlagen die Auto-Updates viel zu oft zu und reißen mich aus dem Flow
    Ich mache mir Sorgen, dass die Sprite-CLI dasselbe Problem wiederholt

    • Ich habe Fly aus genau diesem Grund ebenfalls aufgegeben und bin zu Digital Ocean gewechselt. Das angebliche „just works“ hat viel zu oft eben nicht funktioniert

  • Das ist wirklich interessant!
    In der Firma nutzen wir einen persistenten Entwicklungsserver mit Claude per SSH, und es ist lästig, wenn ein Git-Repo oder die Umgebung verschwindet
    Mit Sprite könnte man Daten in etwas wie SQLite speichern und einfache Apps bauen, die per URL erreichbar sind
    Wenn die Struktur sich nach kurzer Zeit automatisch auflöst, wäre das perfekt für einfache persönliche Software
    Noch besser wäre es, wenn es eine Funktion gäbe, mit der man eine URL erst nach Authentifizierung über ein Fly-Konto sehen kann, ähnlich wie bei Vercel-Preview-Umgebungen

  • Sieht cool aus, aber andere Produkte von Fly sind bei Stabilität und Reifegrad nicht gerade vorbildlich
    API-Downtime und vorübergehende Fehler kommen häufig vor, und auch Abrechnungsprobleme werden nur langsam gelöst
    Zum Beispiel werden gelöschte Instanzen weiterhin als genutzt angezeigt, und stündliche Gebühren werden doppelt so hoch berechnet wie tatsächlich
    Sie haben neue AI-Produkte wie Phoenix.new und Sprites veröffentlicht, scheinen sich aber eher auf neue Produkte als auf Qualitätsverbesserungen der bestehenden zu konzentrieren

    • Wenn man nur Zuverlässigkeit und Support betrachtet, sehe ich keinen Grund, das zu verwenden

  • So eine Entwicklungs-Sandbox wollte ich schon lange — eine Umgebung, die nicht viel kostet, selbst wenn man vergisst, sie zu beenden
    Allerdings gab es ein paar Probleme

    1. Fehler manpath: can't set the locale — vermutlich wurde die lokale Locale-Konfiguration einfach durchgereicht
    2. $SHELL war auf /opt/homebrew/bin/fish gesetzt. Dass lokale Umgebungsvariablen offenbar ungefragt übertragen wurden, hat mich etwas verunsichert

  • Das ist wirklich großartig. Genau auf so eine Sandbox-Laufzeitumgebung in Form von DX und API habe ich gewartet
    Ich würde gern das Basis-Image oder die VM anpassen, damit nur die benötigten Binärdateien enthalten sind und keine unnötigen Tools
    Oder es wäre schön, wenn man Sprites auf Checkpoint-Basis klonen könnte. Im Moment sehe ich dafür keine Option

    • Es wäre schön, wenn es wie bei einer Docker-Bereitstellung möglich wäre, ein Basis-Sprite-Image nach eigenen Vorstellungen hochzuladen und darauf weiterzuarbeiten

  • Es hat in den letzten Monaten wirklich Spaß gemacht, an Sprites zu arbeiten
    Bald werden wir einen Teil der Elixir-Seite als Open Source veröffentlichen
    Es gibt auch ein fünfminütiges Demo-Video → YouTube-Demo

    • Interessant ist, dass Claude Sprites selbst steuert. Wenn man einen Server startet, registriert er ihn automatisch als lokalen Service, und bei größeren Änderungen erstellt er selbstständig Checkpoints
      Nicht genutzte Sprites kosten fast nichts. Für jede neue Aufgabe kann man einfach ein neues erstellen
      Es fühlt sich seltsam an, jederzeit eine Umgebung starten zu können, ohne vorher eine Entscheidung treffen zu müssen

  • Weil die Domain fly.io ist, dachte ich zuerst, es sei eine lokale Lösung
    Auch wenn es nicht self-hosted ist, hatte ich eher einen lokalen VM-Wrapper erwartet, der Docker oder bubblewrap umhüllt

    • Für so einen Einsatzzweck lohnt sich ein Blick auf das LXC/Incus-Projekt → https://linuxcontainers.org/incus/
      Wenn man IncusOS auf Basis von ZFS auf lokaler Hardware betreibt, ergibt das eine sehr leistungsfähige Sandbox-Umgebung

  • Vielleicht habe ich es in der Doku übersehen, aber ich frage mich, ob man Sprites forken/klonen oder einen Checkpoint als neues Sprite wiederherstellen kann
    Zum Beispiel würde ich gern ein Sprite als Vorlage für viele weitere verwenden oder Claude Code mehrere Lösungsansätze erkunden lassen und dann nur einen behalten und den Rest aufräumen

    • Diese Funktion soll bald dazukommen. Nächste Woche soll ein Beitrag „how this works“ erklären, warum und wie das aufgebaut ist
      Eigentlich sollte sie schon zum Launch dabei sein, aber man wollte erst noch etwas mehr echte Nutzungsdaten sammeln