Rollback. Branch. Teilen. Das Zustandsmodell unter jedem Container.
Fünf Dateisystem-Primitive und eine BTRFS-Copy-on-Write-Schicht lassen Container-Zustände überleben, in der Zeit reisen und zwischen Servern wechseln – ohne HTTP zu verlassen.
/hoody/storage · /hoody/databases · /ramdisk · /hoody/shares · BTRFS-Snapshots
/ ├── hoody/ │ ├── storage/ ← persistent, per-container │ ├── databases/ ← concurrent-safe SQLite (FUSE) │ └── shares/ ← inter-container directory mounts ├── ramdisk/ ← RAM-backed, 50% of container memory └── ... ← standard Linux FS (ext4, POSIX)
Die Dateisystem-Karte.
Jeder Pfad hat eine andere Persistenz- und Parallelitäts-Geschichte. Den richtigen zu wählen ist das gesamte mentale Modell. Vollständige Tiefen-Einblicke in den folgenden Abschnitten.
/hoody/storage
Persistentes Container-Verzeichnis. Überlebt Neustarts; Snapshots erfassen es. Ein reguläres ext4-Verzeichnis – kein FUSE, keine Parallelitätssicherheit jenseits dessen, was deine App bereitstellt.
/hoody/databases
FUSE-Mount. Viele Prozesse, viele Container (gleicher Server) können SQLite sicher gleichzeitig schreiben – kein 'Datenbank gesperrt'. Nur Pfadänderung: Datei von /app/data.db nach /hoody/databases/data.db verschieben. Nur Host-Ebene – nicht serverübergreifend repliziert.
/ramdisk
RAM-gesichertes tmpfs mit 10–20 GB/s, <1µs Latenz. Decke von 50% Container-Speicher, bei-Bedarf-Zuweisung (0 Bytes bei leer). Überlebt Container-Neustart, wird bei Host-Neustart geleert. Deine Nutzung konkurriert mit Anwendungsspeicher.
/hoody/shares
Container-übergreifende Verzeichnis-Mounts über die Storage-Shares-API. Nur-Lesen oder Lesen-Schreiben, 1-zu-1 oder projektübergreifend. Serverübergreifende Shares nutzen automatisches NFS – kein Mount-Setup. Lebenszyklus (akzeptieren / ablehnen / mounten / widerrufen) auf /platform/control-plane.
/ (ext4)
Standard-Linux-Dateisystem überall sonst. POSIX, ext4, vollständige Semantik. Verhält sich wie jeder VPS außerhalb der /hoody/*-Pfade.
BTRFS unter allem
Copy-on-Write-Schicht unter den disk-gesicherten Pfaden. Block-Level-Snapshots, Deduplizierung über Container hinweg. Sofortige Erstellung, speicherplatzsparende Wiederherstellung. (Nicht /ramdisk – das ist tmpfs im RAM.)
Copy-on-Write, Block-Level, sofort.
BTRFS speichert nur die Blöcke, die sich seit dem Snapshot-Punkt geändert haben. Ein Snapshot erstellen fügt eine Markierung hinzu, keine Daten. Die Kosten skalieren damit, wie viel sich ein Container verändert.
t0 – Snapshot A
Container-Dateisystem hat Blöcke a, b, c. Snapshot A referenziert alle drei.
t1 – Block b ändert sich
Schreib-Modifikation kopiert b nach b'. Originales b bleibt von Snapshot A referenziert. Container sieht jetzt a, b', c.
t2 – Snapshot B
Snapshot B erfasst a, b', c. A und B teilen sich a und c. Nur b/b' divergiert. Gesamtspeicher: 4 Blöcke, nicht 6.
Laufend oder gestoppt – der Container-Zustand bestimmt den Snapshot-Typ.
Einen Snapshot während des Betriebs erstellen gibt dir die Prozesse, den Speicher, die Terminal-Historie, Browser-Tabs und Netzwerkverbindungen zusammen mit dem Dateisystem. Gestoppt gibt dir nur das Dateisystem.
Laufend → stateful
Der vollständige Maschinen-Zustand, eingefroren.
- +Dateisystem (alles in / einschließlich /hoody/*)
- +Laufende Prozesse (PIDs, Eltern-Beziehungen)
- +Speicher + RAM-Dump
- +Terminal-Verlauf und offene Sitzungen
- +Browser-Tabs und aktiver Display-Inhalt
- +Datenbank-Verbindungszustand
- +Netzwerkverbindungen (Sockets, etabliertes TCP)
- +Offene Dateien (fd-Tabellen)
- +Umgebungsvariablen
Gestoppt → stateless
Nur Dateisystem. Wiederherstellung = Neustart von diesem FS.
- ·Nur Dateisystem
- ·Keine Prozesse – Wiederherstellung startet einen kalten Container
- ·Kein Speicher – kein RAM-Dump im Snapshot
- ·Kein Netzwerkzustand – Verbindungen müssen neu aufgebaut werden
— Wiederherstellung ist destruktiv: sie überschreibt den aktuellen Live-Zustand. Wenn du den aktuellen Zustand behalten möchtest, mache zuerst einen Snapshot, dann stelle das Ziel wieder her.
Den Agenten ausprobieren lassen. Den Rückgängig-Knopf behalten.
LLMs, die Auth-Middleware, Datenbank-Migrationen oder umfangreiche Refactorings anfassen, profitieren am meisten von einem Snapshot-vor-Ausführung-Muster. Günstig zu erstellen. Schnell wiederherzustellen.
Ohne Snapshots
- 1.Agent refactort deine Auth-Middleware. Erste Smoke-Tests bestehen.
- 2.Du mergst und deployst. Alles sieht tagelang gut aus.
- 3.Sitzungen beginnen still in der Produktion zu scheitern.
- 4.Das Bisekting neuerer Agent-Commits dauert Stunden – die Änderung ist in einem großen Diff begraben.
- 5.Rollback bedeutet, jeden gemergten Agent-PR manuell zu revertieren und neu zu deployen.
Mit Hoody-Snapshots
- 1.Den Container vor dem Agenten-Lauf mit Snapshot sichern. Einen Alias wie pre-auth-refactor vergeben.
- 2.Den Agenten arbeiten lassen. Er bearbeitet Dateien, startet Services neu, führt Smoke-Tests aus.
- 3.Eine Woche später fällt etwas in der Produktion auf.
- 4.PATCH /snapshots/pre-auth-refactor — the container restores to the pre-agent state in 5–15s.
- 5.Mit dem aus dem Snapshot wiederhergestellten Service kannst du einen neuen Snapshot des kaputten Zustands für Offline-Untersuchung erstellen.
Das Sicherheitsnetz-Muster ist der Grund, warum jeder KI-unterstützte Workflow – Code-Generierung, Infrastruktur-Refactoring, Datenbank-Migrationen – innerhalb eines Snapshot-gesicherten Containers laufen sollte.
Der Workflow ist ein Commit-Graph für ganze Maschinen.
Snapshot vor einer riskanten Änderung. Iterieren. Wenn das Ergebnis gut ist, weitermachen – der Snapshot ist günstig und läuft ab. Wenn es kaputt geht, ein PATCH-Aufruf stellt ihn wieder her.
t0 – Basis
POST /snapshots — tagged v1.4.0-pre
t1 – riskante Arbeit
KI-Agent refactort, Migrationen laufen, Services starten neu
t2 – etwas ist kaputt gegangen
Smoke-Tests schlagen fehl. Muss zurückgehen.
t3 – Wiederherstellung
PATCH /snapshots/v1.4.0-pre — 5–15s restore
t4 – identisch zu t0
RAM, Prozesse, FS passen alle zu t0. Null Drift.
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preWenn SSD der Engpass ist, ist /ramdisk die Antwort.
Die Hälfte des Container-Speichers, erreichbar als /ramdisk, bei-Bedarf zugeteilt. Er ist da, wenn du ihn nutzt, verschwindet wenn du es nicht tust. Überlebt Container-Neustarts, wird bei Host-Neustarts geleert.
⚠ /ramdisk-Nutzung zählt gegen den Container-Speicher. Wenn der Container 4 GB hat und /ramdisk 3 GB hält, hat die Anwendung 1 GB zum Arbeiten. Mit /api/v1/system/resources überwachen.
Fünf Snapshot-Strategien, die Teams wirklich verwenden.
Eines wählen und deine Zustandsdisziplin wird zur Ein-Zeilen-Entscheidung, kein Policy-Dokument. Die meisten Teams kombinieren zwei oder drei davon.
1 · Pre-Operation-Sicherheit
Vor allem Destruktivem snapshotten: Migrationen, AI-Code-Generierung, Incident-Response, manuelle Hotfixes.
2 · Versionierte Meilensteine
Snapshots an Release-Punkten alias vergeben — v1.4.0, v1.5.0-rc. Ablauf Wochen später. Sofortiger Rollback auf jede benannte Version.
3 · Taeglich automatisiert
Cron-Snapshot mit Auto-Ablauf = selbst bereinigender Verlauf. Sieben Tage von gestern, dreißig Tage von letzten Monaten.
4 · Git-artiges Branching
Snapshot + Container-Kopie = eine alternative Zeitlinie auf einem anderen Projekt oder Server. Riskanten Pfad auf der Kopie ausprobieren. Bei Erfolg wird er der Hauptstrang.
5 · Golden-Image-Templates
Snapshot als Ausgangspunkt erstellen, für jeden neuen Dev-Container aus Snapshot kopieren. Onboarding wird zu einem POST-Aufruf.
Bonus · Forensische Aufbewahrung
Wenn die Produktion kompromittiert ist: kompromittierten Zustand für Untersuchung snapshotten, Produktion von einem saubereren früheren Snapshot wiederherstellen.
Was du sonst zusammenstrickst.
Rollback, zustandsbehaftetes Capture, concurrent-sicheres SQLite, container-übergreifende Shares, RAM-gestützter Scratch — jeder hat einen herkömmlichen Ersatz.
| Concern | Hoody Daten & Zustand | Herkömmlicher Stack |
|---|---|---|
| Gesamte Maschine zurücksetzen | PATCH /containers/ID/snapshots/NAME | Tarball + manuelles Re-Deploy + Daumen druecken |
| Laufenden Speicherzustand aufnehmen | Stateful snapshot (automatic) | VMware Suspend + benutzerdefiniertes Tooling |
| Container-übergreifende Verzeichnis-Freigabe | /hoody/shares + Shares API | NFS- oder SMB-Server selbst betreiben |
| Gleichzeitige SQLite-Schreibvorgaenge | /hoody/databases (FUSE mount) | Datenschicht auf Postgres umschreiben |
| RAM-gestützter Scratch-Speicher | /ramdisk (ceiling 50% memory) | tmpfs + sorgfaeltige ulimits |
| Speicher-Dedup über ähnliche Container | BTRFS copy-on-write (built in) | rsync --link-dest, manuelle Policy |
| Zustandsreplikation über Server | POST /containers/ID/copy + /sync | Eigene rsync-Schleifen + Service-Neustart |
Wenn du bereits ein verwaltetes VM-Snapshot-System für eine bestimmte Arbeitslast verwendest, bleib dabei. Hoodys Zustandsprimitive ergaenzen diesen Stack.
Dein Zustand ist bereits ein Commit-Graph. Lern, ihn zu nutzen.
Das Dateisystem ist bereits da. Die Snapshots sind bereits da. Die Mounts sind bereits da. Container starten und ausprobieren.
Siehe auch — /platform/control-plane für Snapshot- und Kopier-/Sync-APIs, /kit/files für Cloud-Backends, /kit/sqlite für SQLite.