Rollback. Branche. Partage. Le modèle d'état sous chaque container.
Cinq primitives filesystem et une couche copy-on-write BTRFS font survivre l'état d'un conteneur, lui font traverser le temps et migrer entre serveurs — sans jamais quitter HTTP.
/hoody/storage · /hoody/databases · /ramdisk · /hoody/shares · snapshots BTRFS
/ ├── hoody/ │ ├── storage/ ← persistent, per-container │ ├── databases/ ← concurrent-safe SQLite (FUSE) │ └── shares/ ← inter-container directory mounts ├── ramdisk/ ← RAM-backed, up to 50% of host memory └── ... ← standard Linux FS (ext4, POSIX)
La carte du filesystem.
Chaque chemin a une histoire de persistance et de concurrence différente. Choisir le bon, c'est tout le modèle mental. Les explorations détaillées sont dans les sections ci-dessous.
/hoody/storage
Répertoire persistant par container. Survit aux redémarrages ; les snapshots le capturent. Un répertoire ext4 normal — pas de FUSE, pas de sécurité de concurrence au-delà de ce que votre app fournit.
/hoody/databases
Montage FUSE. Plusieurs processus, plusieurs conteneurs (même serveur) peuvent écrire SQLite en concurrent-safe — pas de "database is locked". Changement de chemin uniquement : déplace le fichier de /app/data.db vers /hoody/databases/data.db. Au niveau host — pas répliqué inter-serveur.
/ramdisk
tmpfs adossé à la RAM à 10–20 GB/s, <1µs de latence. Plafond à 50% de la mémoire du conteneur, allocation à la demande (0 octet utilisé quand vide). Persiste à travers le redémarrage du conteneur, vidé au reboot de l'host. votre usage entre en concurrence avec la mémoire applicative.
/hoody/shares
Montages de répertoires inter-conteneurs via l'API Storage Shares. Lecture seule ou lecture-écriture, 1-à-1 ou à l'échelle du projet. Les partages inter-serveurs utilisent NFS automatique — pas de setup de montage. Le lifecycle (accept / reject / mount / revoke) vit sur /platform/control-plane.
/ (ext4)
Filesystem Linux standard partout ailleurs. POSIX, ext4, sémantique complète. Se comporte comme n'importe quel VPS en dehors des chemins /hoody/*.
BTRFS sous tout ça
Couche copy-on-write sous les chemins adossés au disque. Snapshots au niveau bloc, déduplication entre conteneurs. Création instantanée, restauration efficace en espace. (Sauf /ramdisk — c'est tmpfs en RAM.)
Copy-on-write, au niveau bloc, instantané.
BTRFS ne stocke que les blocs qui ont changé depuis le point de snapshot. Créer un snapshot ajoute un marqueur, pas des données. Le coût scale avec ce qu'un conteneur change réellement — pas avec le nombre de snapshots ou de conteneurs sur la même image de base.
t0 — snapshot A
Le filesystem du conteneur a les blocs a, b, c. Le snapshot A référence les trois.
t1 — le bloc b change
L'écriture-modification copie b vers b'. Le b original reste référencé par le snapshot A. Le conteneur voit maintenant a, b', c.
t2 — snapshot B
Le snapshot B capture a, b', c. A et B partagent a et c. Seul b/b' diverge. Stockage total : 4 blocs, pas 6.
En cours d'exécution ou stoppé — l'état du conteneur choisit le type de snapshot.
Prenez un snapshot pendant que ça tourne et vous obtenez les processus, la mémoire, l'historique du terminal, les onglets navigateur et les connexions réseau en plus du filesystem. Prenez-en un en stoppé et vous obtenez uniquement le filesystem. L'appel API est le même ; le type est automatique.
Snapshot → filesystem uniquement
Tout sur le disque, rien en mémoire.
- +Filesystem — tout ce qui est écrit sur le disque dans / y compris /hoody/*
- +Chaque fichier, paquet et dépendance installée sur le disque
- +Bases de données et données d'application déjà écrites sur le disque
- +La restauration rétablit le disque ; le conteneur redémarre à neuf à partir de celui-ci — les processus ne reprennent pas
- +Le champ stateful est toujours à false — c'est ce qui rend les snapshots rapides, légers et fiables
Pause/reprise → RAM gelée
L'opération distincte pour les cas où la mémoire doit survivre.
- ·POST /api/v1/containers/ID/pause — the pause lifecycle operation
- ·L'état du conteneur est gelé en RAM, suspendu sur place
- ·L'opération de reprise relance les processus en pleine exécution
- ·Pas un snapshot — elle ne crée aucun point de restauration sur le disque
— La restauration est destructive : elle écrase l'état live actuel. Si vous voulez garder le présent, snapshotez-le d'abord, puis restaurez la cible.
Laissez l'agent essayer. Gardez le bouton undo.
Les LLM qui touchent au middleware d'auth, aux migrations de base, ou à des refactorings larges bénéficient le plus du pattern snapshot-avant-exécution. Pas cher à prendre. Rapide à restaurer. Un appel API dans chaque sens.
Sans snapshots
- 1.L'agent refactore votre middleware d'auth. Les premiers smoke tests passent.
- 2.vous merge et déploies. Tout a l'air bien pendant des jours.
- 3.Les sessions commencent à tomber silencieusement en production.
- 4.Bisecter les commits récents de l'agent prend des heures — le changement est enterré dans un large diff.
- 5.Le rollback signifie revert chaque PR d'agent mergée à la main et redéployer.
Avec les snapshots Hoody
- 1.Snapshot le conteneur avant que l'agent ne tourne. Donne-lui un alias comme pre-auth-refactor.
- 2.Laissez l'agent travailler. Il édite des fichiers, redémarre des services, lance des smoke tests.
- 3.Quelque chose a l'air faux en production une semaine plus tard.
- 4.PATCH /snapshots/pre-auth-refactor — le conteneur est restauré à l'état pré-agent en 5–15s.
- 5.Une fois le service restauré depuis le snapshot, vous pouvez prendre un nouveau snapshot de l'état cassé pour investigation hors ligne.
Le pattern filet de sécurité explique pourquoi chaque workflow assisté par AI — génération de code, refactoring d'infra, migrations de base — devrait tourner dans un conteneur snapshotté. Le snapshot est pas cher ; le coût de découverte d'un mauvais changement AI ne l'est pas.
Le workflow est un graphe de commits pour des machines entières.
Snapshot avant un changement risqué. Itérez. Si le résultat est bon, continuez — le snapshot est pas cher et expirable. Si ça casse, un seul appel PATCH remet le conteneur exactement où il était — RAM, processus, fichiers ouverts inclus.
t0 — référence
POST /snapshots — taggé v1.4.0-pre
t1 — travail risqué
L'agent AI refactore, les migrations tournent, les services redémarrent
t2 — quelque chose a cassé
Les smoke tests échouent. Besoin de revenir.
t3 — restauration
PATCH /snapshots/v1.4.0-pre — restauration en 5–15s
t4 — identique à t0
RAM, processus, FS — tout matche t0. Zéro dérive.
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preQuand le SSD plafonne, /ramdisk est la réponse.
La moitié de la mémoire du conteneur, joignable comme /ramdisk, allouée à la demande. Là quand vous l'utilises, disparaît quand vous ne l'utilises pas. Persiste à travers les redémarrages de container. Vidé au reboot de l'host.
⚠ L'usage de /ramdisk compte sur la mémoire du container. Si le conteneur a 4 GB et que /ramdisk en occupe 3, l'application a 1 GB pour travailler. Surveille avec `free -h` et plafonne par design.
Cinq stratégies de snapshots que les équipes utilisent vraiment.
Choisissez-en une et votre discipline d'état devient une décision en une ligne, pas un document de politique. La plupart des équipes en font tourner deux ou trois en parallèle.
1 · Sécurité pré-opération
Snapshot avant tout ce qui est destructif : migrations, génération de code AI, réponse à incident, hotfixes manuels.
2 · Jalons versionnés
Snapshots aliasés aux points de release — v1.4.0, v1.5.0-rc. Expiration dans des semaines. Rollback instantané vers n'importe quelle version nommée.
3 · Automatisé quotidien
Snapshot via cron avec auto-expiration = historique auto-élagué. Sept jours d'hier, trente jours du mois dernier.
4 · Branching à la git
Snapshot + copie de conteneur = une timeline alternative sur un projet ou serveur différent. Essayez un chemin risqué sur la copie. Si ça marche, reconstruisez la baseline là-bas ; le sync est unidirectionnel donc la copie devient l'endroit où vit la nouvelle vérité.
5 · Templates golden-image
Sème un snapshot, copy-from-snapshot pour chaque nouveau conteneur dev. L'onboarding devient un POST.
Bonus · Préservation forensique
Quand la production est compromise : snapshot l'état compromis pour investigation, restaurez la production depuis un snapshot antérieur propre, diff les deux hors ligne. Réponse à incident sans perdre les preuves.
Ce que vous assembleriez sinon à la main.
Rollback, capture stateful, SQLite concurrent-safe, partages inter-conteneurs, scratch en RAM — chacun a une réponse traditionnelle. Voici la comparaison honnête côte à côte.
| Préoccupation | Hoody Data & State | Stack traditionnelle |
|---|---|---|
| Rollback d'une machine entière | PATCH /containers/ID/snapshots/NAME | Tarball + redéploiement manuel + prière |
| Capturer l'état mémoire en cours | POST /containers/ID/pause (pause/resume) | Suspend VMware + outillage custom |
| Partage de répertoires inter-conteneurs | /hoody/shares + Shares API | Faire tourner un serveur NFS ou SMB vous-même |
| Écritures SQLite concurrentes | /hoody/databases (FUSE mount) | Réécrire votre couche de données sur Postgres |
| Espace scratch adossé à la RAM | /ramdisk (50% of host memory) | tmpfs + ulimits soigneux |
| Dédup de stockage entre conteneurs similaires | BTRFS copy-on-write (built in) | rsync --link-dest, politique manuelle |
| Réplication d'état inter-serveur | POST /containers/ID/copy + /sync | Boucles rsync DIY + restart de service |
Si vous êtes déjà sur un système de snapshots VM managé pour un workload spécifique, restez là pour ce workload. Le modèle d'état Hoody gagne sa place quand la primitive que vous voulez est vraiment du voyage dans le temps au niveau container.
votre état est déjà un graphe de commits. Apprends à vous en servir.
Le filesystem est déjà là. Les snapshots sont déjà là. Les montages sont déjà là. Lancez un conteneur et tout le modèle d'état est en marche.
Voir aussi — /platform/control-plane pour les APIs snapshot et copy/sync, /kit/files pour les backends cloud, /kit/sqlite pour SQLite en HTTP.