Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoDesbloqueado
EtapaFlota
DificultadModerado
TrabajoSaaS multi-inquilino
ParaFundadores solitarios
ParaEquipos de desarrollo
ParaAgencias
ServiciosContainers
ServiciosSnapshots
ServiciosExec
ServiciosFiles
Por qué HoodyEconomía de contenedores
Por qué HoodyAislamiento bare-metal
Por qué HoodyViaje en el tiempo con snapshots
IndustriaSaaS
TipoDesbloqueado
EtapaFlota
DificultadModerado
TrabajoSaaS multi-inquilino
ParaFundadores solitarios
ParaEquipos de desarrollo
ParaAgencias
ServiciosContainers
ServiciosSnapshots
ServiciosExec
ServiciosFiles
Por qué HoodyEconomía de contenedores
Por qué HoodyAislamiento bare-metal
Por qué HoodyViaje en el tiempo con snapshots
IndustriaSaaS
TipoDesbloqueado
EtapaFlota
DificultadModerado
TrabajoSaaS multi-inquilino
ParaFundadores solitarios
ParaEquipos de desarrollo
ParaAgencias
ServiciosContainers
ServiciosSnapshots
ServiciosExec
ServiciosFiles
Por qué HoodyEconomía de contenedores
Por qué HoodyAislamiento bare-metal
Por qué HoodyViaje en el tiempo con snapshots
IndustriaSaaS
TipoDesbloqueado
EtapaFlota
DificultadModerado
TrabajoSaaS multi-inquilino
ParaFundadores solitarios
ParaEquipos de desarrollo
ParaAgencias
ServiciosContainers
ServiciosSnapshots
ServiciosExec
ServiciosFiles
Por qué HoodyEconomía de contenedores
Por qué HoodyAislamiento bare-metal
Por qué HoodyViaje en el tiempo con snapshots
IndustriaSaaS
use-cases / one-sandbox-per-customer / hero
CONTENEDORES · SAAS MULTI-INQUILINO
Un sandbox por cliente, automáticamente
Deja de dispersar tenant_id por todas las tablas. Cuando un cliente se registra, un script exec copia un contenedor nuevo y le entrega su propia URL, su propio sistema de archivos, su propio SQLite. El aislamiento es el sistema operativo entre ellos, no una cláusula WHERE.
WEBHOOK DE SIGNUP → SPAWN DEL CONTENEDOR
TU WEBHOOK HANDLER
POST# disparado por checkout.session.completed de Stripe
POST /api/v1/projects/{id}/containers
Authorization: Bearer hdy_***
{
"user_id": "usr_7xk9",
"container_image": "ubuntu/24.04",
"name": "sbx-usr-7xk9",
"hoody_kit": true
}
RESPUESTA DE LA API DE HOODY
201 Created{
"id": "ctr_a9f3e2b1c7d04500",
"status": "provisioning",
"name": "sbx-usr-7xk9",
"url": "https://proj-ctr_a9f3...containers.hoody.com"
}
Cuando un usuario se registra, esto es lo que ocurre.
use-cases / one-sandbox-per-customer / trigger
Lo que provisiona esa única llamada API
Cada POST a /api/v1/projects/{id}/containers levanta un entorno aislado. Una llamada, un tenant, una URL devuelta a tu app.
01 · WEBHOOK
El registro dispara el POST del contenedor
Tu webhook de Stripe (o de cualquier facturación) llega a un script de Hoody Exec. Sin Express, sin configurar servidores — solo un archivo en scripts/.
02 · ISOLATION
Namespaces de Linux, no una cláusula WHERE
El nuevo contenedor tiene su propio filesystem, su propio SQLite, su propio ramdisk. El tenant A literalmente no puede ver los datos del tenant B.
03 · URL
Una URL única de vuelta a tu app
La respuesta incluye una URL de contenedor. Tu app redirige al usuario a su propio sandbox dentro de la misma ventana de despliegue.
04 · FIREWALL
Reglas de red por tenant, clonadas
Las reglas de red y firewall del contenedor se copian de tu plantilla. Cada nuevo tenant arranca desde la misma línea base de seguridad.
05 · IDLE
Coste cero en reposo
Detén el contenedor y no cuesta nada. BTRFS guarda solo el delta de tu plantilla — el disco sigue siendo barato incluso a escala.
06 · OFFBOARD
DELETE del contenedor = olvidar al tenant
Una sola llamada DELETE elimina el contenedor y todos sus datos. El offboarding por GDPR no es un script, es una única llamada HTTP.
Todo el flujo es un webhook handler. Sin operadores de Kubernetes, sin YAML de namespaces, sin admin de cluster. Tres llamadas HTTP: webhook in, container out, URL al usuario.
use-cases / one-sandbox-per-customer / compare
Multi-tenancy compartido vs contenedor por cliente
Las opciones tradicionales eran una columna en cada tabla o una flota de VMs que no podías permitirte. Hoody es una tercera forma: contenedores lo bastante baratos como para dar uno a cada cliente.
DIMENSIÓN
BD COMPARTIDA · TENANT_ID
HOODY · CONTENEDOR POR CLIENTE
- AISLAMIENTOWHERE tenant_id = $1 — y esperas que cada query lo recuerdeNamespaces de Linux. El tenant A literalmente no puede ver el filesystem del tenant B.
- SUPERFICIE DE FUGA DE DATOScada JOIN, cada hook ORM, cada script de reportingel límite del contenedor. Un artefacto que auditar, no 200 sitios de queries.
- CONFIG POR TENANTtabla de feature flags, frágil, medio probada en devedita el entorno de un contenedor. Los otros 399 quedan intactos.
- VECINO RUIDOSOun cliente pesado puede bloquear la BD compartidacuotas de CPU y disco por contenedor; la carga de un tenant queda en su caja.
- OFFBOARDINGDELETE … WHERE tenant_id … más otras 12 tablas que olvidasteDELETE el contenedor. Sus datos se van con él. GDPR es una llamada HTTP.
- COSTE EN OCIOSOcada fila cuesta almacenamiento incluso cuando el cliente está dormidopara el contenedor — cero CPU, cero RAM. BTRFS guarda solo el delta.
- sin columnas tenant_id
- sin auditorías de row-level security
- sin YAML de namespace
- borrar = olvidar
use-cases / one-sandbox-per-customer / punchline
La multi-tenancy deja de ser un problema de arquitectura. Se convierte en un comando `cp`.
ALTA
POST /containers/$TEMPLATE/copyBAJA
DELETE /containers/$CIDAJUSTE POR TENANT
PATCH /containers/$CID [ env_vars ]- aislamiento de nivel namespace
- borrado GDPR en una llamada
- un contenedor por cuenta
use-cases / one-sandbox-per-customer / replaces
Qué reemplaza esto
El aislamiento por tenant ha significado históricamente o una cláusula WHERE ingeniosa o un cluster caro. Container-per-customer desplaza los parches habituales:
- Multi-tenancy compartido (columna tenant_id)Una mala query expone a todos
- Middleware de aislamiento por tenant a medidaGuardia hecho a mano que mantienes para siempre
- Políticas de row-level security de PostgresLa respuesta correcta, costosa de auditar por tabla
- Namespace de Kubernetes por tenantSobrecarga a nivel de cluster, equipo de ops requerido
- Schemas / bases de datos por clienteMultiplicador de migraciones, dolor de connection-pool
- Filas de medición de Stripe en tabla compartidaTracking de uso pegado a la misma caja compartida
use-cases / one-sandbox-per-customer / cta
Los clientes ociosos no cuestan nada. Los activos escalan bajo demanda. Toda la cosa corre sobre $49 de bare metal hasta que tienes cientos de usuarios de pago.
use-cases / one-sandbox-per-customer / related