Rollback. Ramifica. Comparte. El modelo de estado detrás de cada contenedor.
Cinco primitivos de filesystem y una capa copy-on-write de BTRFS hacen que el estado del contenedor sobreviva, viaje en el tiempo y se mueva entre servidores — sin salir de 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)
El mapa del filesystem.
Cada ruta tiene una historia diferente de persistencia y concurrencia. Elegir la correcta es todo el modelo mental. Los detalles completos en las secciones de abajo.
/hoody/storage
Directorio persistente por contenedor. Sobrevive reinicios; los snapshots lo capturan. Un directorio ext4 normal — sin FUSE, sin seguridad de concurrencia más allá de lo que tu app provea.
/hoody/databases
Montaje FUSE. Muchos procesos, muchos contenedores (mismo servidor) pueden escribir en SQLite de forma concurrente y segura — sin 'database is locked'. Solo cambia la ruta: mueve el archivo de /app/data.db a /hoody/databases/data.db. A nivel de host — no replicado entre servidores.
/ramdisk
tmpfs respaldado en RAM a 10–20 GB/s, latencia <1µs. Límite del 50% de la memoria del contenedor, asignación bajo demanda (0 bytes usados cuando está vacío). Persiste entre reinicios del contenedor, se borra al reiniciar el host. Tu uso compite con la memoria de la aplicación.
/hoody/shares
Montajes de directorios entre contenedores vía la API de Storage Shares. Solo lectura o lectura-escritura, 1-a-1 o para todo el proyecto. Los shares entre servidores usan NFS automático — sin configuración de montaje. El ciclo de vida (aceptar / rechazar / montar / revocar) vive en /platform/control-plane.
/ (ext4)
Filesystem Linux estándar en todo lo demás. POSIX, ext4, semántica completa. Se comporta como cualquier VPS fuera de las rutas /hoody/*.
BTRFS por debajo de todo
Capa copy-on-write bajo las rutas respaldadas en disco. Snapshots a nivel de bloque, deduplicación entre contenedores. Creación instantánea, restauración eficiente en espacio. (No /ramdisk — ese es tmpfs en RAM.)
Copy-on-write, a nivel de bloque, instantáneo.
BTRFS almacena solo los bloques que cambiaron desde el punto de snapshot. Crear un snapshot añade un marcador, no datos. El costo escala con cuánto cambia realmente un contenedor — no con cuántos snapshots o contenedores comparten la misma imagen base.
t0 — snapshot A
El filesystem del contenedor tiene los bloques a, b, c. El snapshot A hace referencia a los tres.
t1 — el bloque b cambia
Escritura-modificación copia b a b'. El b original sigue siendo referenciado por el snapshot A. El contenedor ahora ve a, b', c.
t2 — snapshot B
El snapshot B captura a, b', c. A y B comparten a y c. Solo b/b' diverge. Almacenamiento total: 4 bloques, no 6.
En ejecución o detenido — el estado del contenedor determina el tipo de snapshot.
Toma un snapshot mientras está en ejecución y obtienes los procesos, la memoria, el historial del terminal, las pestañas del navegador y las conexiones de red junto con el filesystem. Tómalo mientras está detenido y obtienes solo el filesystem. La llamada a la API es la misma; el tipo es automático.
En ejecución → con estado
El estado completo de la máquina, congelado.
- +Filesystem (todo en / incluyendo /hoody/*)
- +Procesos en ejecución (PIDs, relaciones padre-hijo)
- +Memoria + volcado de RAM
- +Historial del terminal y sesiones abiertas
- +Pestañas del navegador y contenido activo en display
- +Estado de conexión a la base de datos
- +Conexiones de red (sockets, TCP establecidos)
- +Archivos abiertos (tablas fd)
- +Variables de entorno
Detenido → sin estado
Solo filesystem. Restaurar = arranque limpio desde ese FS.
- ·Solo filesystem
- ·Sin procesos — la restauración levanta un contenedor frío
- ·Sin memoria — no hay volcado de RAM en el snapshot
- ·Sin estado de red — las conexiones deben restablecerse
— Restaurar es destructivo: sobreescribe el estado activo actual. Si quieres conservar el presente, haz primero un snapshot de él y luego restaura el objetivo.
Deja que el agente pruebe. Conserva el botón de deshacer.
Los LLMs que tocan middleware de auth, migraciones de base de datos o refactorizaciones amplias se benefician más del patrón snapshot-antes-de-ejecutar. Económico de tomar. Rápido de restaurar. Una llamada a la API en cada dirección.
Sin snapshots
- 1.El agente refactoriza tu middleware de auth. Los primeros tests pasan.
- 2.Haces merge y despliegas. Todo parece bien durante días.
- 3.Las sesiones empiezan a caerse silenciosamente en producción.
- 4.Hacer bisect de los commits recientes del agente lleva horas — el cambio está enterrado en un diff grande.
- 5.Rollback significa revertir cada PR del agente mergeado a mano y redesplegar.
Con snapshots de Hoody
- 1.Toma un snapshot del contenedor antes de que corra el agente. Dale un alias como pre-auth-refactor.
- 2.Deja que el agente trabaje. Edita archivos, reinicia servicios, corre tests.
- 3.Algo parece mal en producción una semana después.
- 4.PATCH /snapshots/pre-auth-refactor — el contenedor se restaura al estado pre-agente en 5–15s.
- 5.Con el servicio restaurado desde el snapshot, puedes tomar un nuevo snapshot del estado roto para investigación offline.
El patrón de red de seguridad es la razón por la que todo flujo de trabajo asistido por IA — generación de código, refactorización de infraestructura, migraciones de base de datos — debería correr dentro de un contenedor con snapshot. El snapshot es económico; el costo de descubrir un cambio de IA malo no lo es.
El flujo de trabajo es un grafo de commits para máquinas enteras.
Haz un snapshot antes de un cambio arriesgado. Itera. Si el resultado es bueno, sigue adelante — el snapshot es económico y expirable. Si se rompe, una llamada PATCH devuelve el contenedor exactamente a donde estaba — RAM, procesos, archivos abiertos y todo.
t0 — baseline
POST /snapshots — etiquetado v1.4.0-pre
t1 — trabajo arriesgado
Agente de IA refactoriza, migraciones corren, servicios reinician
t2 — algo se rompió
Los tests fallan. Hay que volver atrás.
t3 — restaurar
PATCH /snapshots/v1.4.0-pre — restauración en 5–15s
t4 — idéntico a t0
RAM, procesos, FS coinciden con t0. Cero deriva.
PATCH /api/v1/containers/ID/snapshots/v1.4.0-preCuando el SSD es el cuello de botella, /ramdisk es la respuesta.
La mitad de la memoria del contenedor, accesible como /ramdisk, asignada bajo demanda. Está disponible cuando la usas, desaparece cuando no. Persiste entre reinicios del contenedor. Se borra al reiniciar el host.
⚠ El uso de /ramdisk cuenta contra la memoria del contenedor. Si el contenedor tiene 4 GB y /ramdisk ocupa 3 GB, la aplicación tiene 1 GB para trabajar. Monitorea con `free -h` y limita con un diseño cuidadoso.
Cinco estrategias de snapshot que los equipos usan realmente.
Elige una y tu disciplina de estado se convierte en una decisión de una línea, no en un documento de política. La mayoría de los equipos usa dos o tres de estas en paralelo.
1 · Seguridad pre-operación
Snapshot antes de cualquier cosa destructiva: migraciones, generación de código con IA, respuesta a incidentes, hotfixes manuales.
2 · Hitos versionados
Alias de snapshots en puntos de release — v1.4.0, v1.5.0-rc. Expiración semanas después. Rollback instantáneo a cualquier versión con nombre.
3 · Automatizado diario
Cron-snapshot con auto-expiración = historial autopodado. Siete días de ayeres, treinta días de últimos meses.
4 · Ramificación estilo Git
Snapshot + copia de contenedor = una línea de tiempo alternativa en un proyecto o servidor diferente. Prueba un camino arriesgado en la copia. Si funciona, reconstruye el baseline ahí; la sincronización es unidireccional, así que la copia es donde vive la nueva verdad.
5 · Plantillas de imagen dorada
Siembra un snapshot, copia-desde-snapshot para cada nuevo contenedor de desarrollo. El onboarding se convierte en una llamada POST.
Bonus · Preservación forense
Cuando producción está comprometida: toma un snapshot del estado comprometido para investigación, restaura producción desde un snapshot anterior limpio, haz diff de los dos offline. Respuesta a incidentes sin perder evidencia.
Lo que de otro modo tendrías que juntar tú.
Rollback, captura con estado, SQLite seguro ante concurrencia, shares entre contenedores, espacio de trabajo respaldado en RAM — cada uno tiene una respuesta tradicional. Aquí está la comparación honesta.
| Aspecto | Hoody Data & State | Stack tradicional |
|---|---|---|
| Hacer rollback de una máquina completa | PATCH /containers/ID/snapshots/NAME | Tarball + redespliegue manual + rezar |
| Capturar estado de memoria en ejecución | Stateful snapshot (automatic) | Suspensión VMware + herramientas personalizadas |
| Share de directorio entre contenedores | /hoody/shares + Shares API | Correr servidor NFS o SMB tú mismo |
| Escrituras SQLite concurrentes | /hoody/databases (FUSE mount) | Reescribir tu capa de datos en Postgres |
| Espacio de trabajo respaldado en RAM | /ramdisk (ceiling 50% memory) | tmpfs + ulimits cuidadosos |
| Deduplicación de almacenamiento entre contenedores similares | BTRFS copy-on-write (built in) | rsync --link-dest, política manual |
| Replicación de estado entre servidores | POST /containers/ID/copy + /sync | Bucles rsync DIY + reinicio de servicio |
Si ya tienes un sistema de snapshots de VM gestionado para una carga de trabajo específica, quédate con él para esa carga. El modelo de estado de Hoody gana su lugar cuando el primitivo que quieres es realmente el viaje en el tiempo a nivel de contenedor.
Tu estado ya es un grafo de commits. Aprende a usarlo.
El filesystem ya está ahí. Los snapshots ya están ahí. Los montajes ya están ahí. Arranca un contenedor y todo el modelo de estado está en vivo.
Ver también — /platform/control-plane para las APIs de snapshot y copia/sync, /kit/files para backends cloud, /kit/sqlite para SQLite como HTTP.