Rollback. Branchez. Partagez. Le modèle d'état sous chaque conteneur.
Cinq primitives de système de fichiers et une couche BTRFS copy-on-write font survivre l'état du conteneur, voyager dans le temps et se déplacer entre serveurs — sans 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, 50% of container memory └── ... ← standard Linux FS (ext4, POSIX)
La carte du système de fichiers.
Chaque chemin a une histoire différente de persistance et de concurrence. Choisir le bon est tout le modèle mental. Approfondissements complets dans les sections ci-dessous.
/hoody/storage
Répertoire persistant par conteneur. Survit aux redémarrages ; les snapshots le capturent. Un répertoire ext4 classique — 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 simultanément dans SQLite en toute sécurité — pas de 'database is locked'. Changement de chemin seulement : déplacez le fichier de /app/data.db vers /hoody/databases/data.db. Au niveau hôte — pas répliqué inter-serveur.
/ramdisk
tmpfs en RAM à 10 à 20 Go/s, latence <1 µs. Plafond de 50% de la mémoire du conteneur, allocation à la demande (0 octets utilisés quand vide). Persiste à travers les redémarrages du conteneur, effacé au redémarrage de l'hôte. Votre usage rivalise avec la mémoire de l'application.
/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 configuration de montage. Le cycle de vie (accepter / rejeter / monter / révoquer) vit sur /platform/control-plane.
/ (ext4)
Système de fichiers Linux standard partout ailleurs. POSIX, ext4, sémantique complète. Se comporte comme n'importe quel VPS en dehors des chemins /hoody/*.
BTRFS en dessous de tout
Couche copy-on-write sous les chemins sauvegardés sur disque. Snapshots au niveau des blocs, déduplication entre conteneurs. Création instantanée, restauration économe en espace. (Pas /ramdisk — c'est tmpfs en RAM.)
Copy-on-write, au niveau des blocs, 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 évolue avec la quantité de changements réels d'un conteneur — pas avec le nombre de snapshots ou de conteneurs assis sur la même image de base.
t0 — snapshot A
Le système de fichiers du conteneur contient les blocs a, b, c. Le snapshot A référence les trois.
t1 — bloc b change
Écriture-modification copie b vers b'. L'original b 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 arrêté — l'état du conteneur choisit le type de snapshot.
Prenez un snapshot en cours d'exécution et vous obtenez les processus, la mémoire, l'historique du terminal, les onglets du navigateur et les connexions réseau avec le système de fichiers. Prenez-en un à l'arrêt et vous obtenez uniquement le système de fichiers. L'appel API est le même ; le type est automatique.
En cours → avec état
L'état complet de la machine, gelé.
- +Système de fichiers (tout dans / incluant /hoody/*)
- +Processus en cours (PIDs, relations parent)
- +Mémoire + dump RAM
- +Historique du terminal et sessions ouvertes
- +Onglets du navigateur et contenu d'affichage actif
- +État de connexion de base de données
- +Connexions réseau (sockets, TCP établis)
- +Fichiers ouverts (tables fd)
- +Variables d'environnement
Arrêté → sans état
Système de fichiers seulement. Restauration = démarrage à froid depuis ce FS.
- ·Système de fichiers seulement
- ·Pas de processus — la restauration démarre un conteneur à froid
- ·Pas de mémoire — pas de dump RAM dans le snapshot
- ·Pas d'état réseau — les connexions doivent se réétablir
— La restauration est destructrice : elle écrase l'état en direct actuel. Si vous voulez conserver le présent, faites d'abord un snapshot, puis restaurez la cible.
Laissez l'agent essayer. Gardez le bouton d'annulation.
Les LLMs qui touchent au middleware d'auth, aux migrations de bases de données ou aux refactorisations larges bénéficient le plus du pattern snapshot-avant-exécution. Peu coûteux à prendre. Rapide à restaurer. Un appel API dans chaque direction.
Sans snapshots
- 1.L'agent refactorise votre middleware d'auth. Les premiers smoke tests passent.
- 2.Vous mergez et déployez. Tout semble bien pendant des jours.
- 3.Les sessions commencent à tomber silencieusement en production.
- 4.Bisecting les commits récents de l'agent prend des heures — la modification est enfouie dans un grand diff.
- 5.Le rollback signifie reverter manuellement chaque PR agent mergée et redéployer.
Avec les snapshots Hoody
- 1.Faites un snapshot du conteneur avant que l'agent s'exécute. Donnez-lui un alias comme pre-auth-refactor.
- 2.Laissez l'agent travailler. Il modifie des fichiers, redémarre des services, exécute des smoke tests.
- 3.Quelque chose semble anormal en production une semaine plus tard.
- 4.PATCH /snapshots/pre-auth-refactor — le conteneur est restauré à l'état pré-agent en 5 à 15 s.
- 5.Avec le service restauré depuis le snapshot, vous pouvez prendre un nouveau snapshot de l'état cassé pour une investigation hors ligne.
Le pattern filet de sécurité est la raison pour laquelle chaque workflow assisté par IA — génération de code, refactorisation d'infrastructure, migrations de bases de données — devrait s'exécuter dans un conteneur snapshoté. Le snapshot est peu coûteux ; le coût de découverte d'une mauvaise modification IA ne l'est pas.
Le workflow est un graphe de commits pour des machines entières.
Faites un snapshot avant un changement risqué. Itérez. Si le résultat est bon, continuez — le snapshot est peu coûteux et expirable. Si ça casse, un seul appel PATCH remet le conteneur exactement où il était — RAM, processus, fichiers ouverts et tout.
t0 — référence
POST /snapshots — étiqueté v1.4.0-pre
t1 — travail risqué
L'agent IA refactorise, les migrations s'exécutent, les services redémarrent
t2 — quelque chose s'est cassé
Les smoke tests échouent. Il faut revenir en arrière.
t3 — restauration
PATCH /snapshots/v1.4.0-pre — restauration en 5 à 15 s
t4 — identique à t0
RAM, processus, FS correspondent tous à t0. Dérive zéro.
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preQuand le SSD est le goulot d'étranglement, /ramdisk est la réponse.
La moitié de la mémoire du conteneur, accessible en tant que /ramdisk, allouée à la demande. C'est là quand vous l'utilisez, disparaît quand vous ne l'utilisez pas. Persiste à travers les redémarrages du conteneur. Effacé au redémarrage de l'hôte.
⚠ L'utilisation de /ramdisk compte dans la mémoire du conteneur. Si le conteneur a 4 Go et que /ramdisk en contient 3 Go, l'application a 1 Go à disposition. Surveillez avec `free -h` et limitez par une conception soigneuse.
Cinq stratégies de snapshot 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 utilisent deux ou trois en parallèle.
1 · Sécurité pré-opération
Faites un snapshot avant tout ce qui est destructeur : migrations, génération de code IA, réponse aux incidents, correctifs manuels.
2 · Jalons versionnés
Alias des snapshots aux points de release — v1.4.0, v1.5.0-rc. Expiration dans quelques semaines. Rollback instantané vers n'importe quelle version nommée.
3 · Automatisé quotidiennement
Cron-snapshot avec expiration auto = historique auto-élagué. Sept jours d'hier, trente jours du mois dernier.
4 · Branchement style Git
Snapshot + copie de conteneur = une timeline alternative sur un projet ou serveur différent. Essayez un chemin risqué sur la copie. Si ça fonctionne, reconstruisez la référence là ; la sync est unidirectionnelle donc la copie est là où vit la nouvelle vérité.
5 · Templates d'image dorée
Amorcez un snapshot, copie-depuis-snapshot pour chaque nouveau conteneur de dev. L'onboarding devient un seul appel POST.
Bonus · Préservation forensique
Quand la production est compromise : faites un snapshot de l'état compromis pour investigation, restaurez la production depuis un snapshot propre antérieur, comparez les deux hors ligne. Réponse aux incidents sans perdre les preuves.
Ce que vous auriez sinon à assembler.
Rollback, capture avec état, SQLite à accès concurrent sécurisé, partages inter-conteneurs, espace scratch en RAM — chacun a une réponse traditionnelle. Voici la comparaison honnête côte à côte.
| Problématique | Hoody Data & State | Stack traditionnelle |
|---|---|---|
| Revenir en arrière sur une machine entière | PATCH /containers/ID/snapshots/NAME | Tarball + re-déploiement manuel + prier |
| Capturer l'état de la mémoire en cours d'exécution | Stateful snapshot (automatic) | Suspension VMware + outillage personnalisé |
| Partage de répertoire inter-conteneurs | /hoody/shares + Shares API | Gérer soi-même un serveur NFS ou SMB |
| Écritures SQLite concurrentes | /hoody/databases (FUSE mount) | Réécrire votre couche de données sur Postgres |
| Espace scratch en RAM | /ramdisk (ceiling 50% memory) | tmpfs + ulimits soigneuses |
| Déduplication du 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 + redémarrage de service |
Si vous êtes déjà sur un système de snapshot VM géré pour une charge de travail spécifique, restez-y pour cette charge de travail. Le modèle d'état Hoody trouve sa place quand la primitive que vous voulez est réellement le voyage dans le temps au niveau conteneur.
Votre état est déjà un graphe de commits. Apprenez à l'utiliser.
Le système de fichiers 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 direct.
Voir aussi — /platform/control-plane pour les APIs de snapshot et copie/sync, /kit/files pour les backends cloud, /kit/sqlite pour SQLite via HTTP.