Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
Conteneurs·Snapshots
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURFondateurs solo
POURÉquipes de devs
POURAgences
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
SERVICESFiles
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYVoyage temporel par snapshot
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURFondateurs solo
POURÉquipes de devs
POURAgences
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
SERVICESFiles
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYVoyage temporel par snapshot
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURFondateurs solo
POURÉquipes de devs
POURAgences
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
SERVICESFiles
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYVoyage temporel par snapshot
SECTEURSaaS
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURFondateurs solo
POURÉquipes de devs
POURAgences
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
SERVICESFiles
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
POURQUOI HOODYVoyage temporel par snapshot
SECTEURSaaS
use-cases / one-sandbox-per-customer / hero
CONTAINERS · SAAS MULTI-TENANT
Un sandbox par client, automatiquement
Quand un client s'inscrit, un appel API provisionne son environnement isolé. Pas de colonnes tenant_id, pas de YAML namespace — juste un POST qui renvoie une URL conteneur en quelques secondes.
WEBHOOK SIGNUP → SPAWN CONTAINER
VOTRE HANDLER WEBHOOK
POST# déclenché par Stripe checkout.session.completed
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
}
RÉPONSE API HOODY
201 Created{
"id": "ctr_a9f3e2b1c7d04500",
"status": "provisioning",
"name": "sbx-usr-7xk9",
"url": "https://proj-ctr_a9f3...containers.hoody.com"
}
Quand un user s'inscrit, voilà ce qui se passe.
use-cases / one-sandbox-per-customer / trigger
Ce que cet unique appel API provisionne
Chaque POST sur /api/v1/projects/{id}/containers démarre un environnement isolé. Un appel, un tenant, une URL renvoyée à votre app.
01 · WEBHOOK
Le signup déclenche le POST conteneur
votre webhook Stripe (ou n'importe quel billing) tape un script Hoody Exec. Pas d'Express, pas de config serveur — juste un fichier dans scripts/.
02 · ISOLATION
Namespaces Linux, pas une clause WHERE
Le nouveau conteneur a son propre filesystem, sa propre SQLite, son propre ramdisk. Le tenant A ne peut littéralement pas voir les données du tenant B.
03 · URL
Une URL unique vers votre app
La réponse inclut une URL container. votre app redirige le user dans son propre sandbox dans la même fenêtre de déploiement.
04 · FIREWALL
Règles réseau par tenant clonées
Les règles réseau et firewall du conteneur sont copiées depuis votre template. Chaque nouveau tenant démarre depuis la même baseline de sécurité.
05 · IDLE
Coût zéro à vide
Stop le conteneur et il ne coûte rien. BTRFS ne garde que le delta depuis votre template — le disque reste peu cher même à l'échelle.
06 · OFFBOARD
DELETE conteneur = oublier le tenant
Un appel DELETE retire le conteneur et toutes ses données. L'offboarding RGPD n'est pas un script, c'est un seul appel HTTP.
Tout le flux est un handler webhook. Pas d'opérateur Kubernetes, pas de YAML namespace, pas d'admin cluster. Trois appels HTTP : webhook in, conteneur out, URL au user.
use-cases / one-sandbox-per-customer / compare
Multi-tenancy partagée vs conteneur-par-client
Les choix traditionnels étaient une colonne sur chaque table ou une flotte de VMs hors budget. Hoody est une troisième forme : des conteneurs assez peu chers pour en donner un à chaque client.
DIMENSION
DB PARTAGÉE · TENANT_ID
HOODY · CONTAINER PAR CLIENT
- ISOLATIONWHERE tenant_id = $1 — et vous êtespères que chaque requête s'en souvientNamespaces Linux. Le tenant A ne peut littéralement pas voir le filesystem du tenant B.
- SURFACE DE FUITEchaque JOIN, chaque hook ORM, chaque script de reportingla frontière du container. Un seul artefact à auditer, pas 200 sites de requête.
- CONFIG PAR TENANTtable de feature flags, fragile, à moitié testée en devéditez l'environnement d'un container. Les 399 autres ne changent pas.
- RESSOURCES PARTAGÉESun client lourd peut bloquer la DB partagéequotas CPU et disque par conteneur ; la charge d'un tenant reste dans sa boîte.
- OFFBOARDINGDELETE … WHERE tenant_id … plus 12 autres tables que vous avez oubliéesDELETE le container. Leurs données partent avec. RGPD en un appel HTTP.
- COÛT À VIDEchaque ligne coûte du stockage même quand le client dortstop le conteneur — zéro CPU, zéro RAM. BTRFS ne garde que le delta.
- pas de colonnes tenant_id
- pas d'audits row-level security
- pas de YAML namespace
- supprimer = oublier
use-cases / one-sandbox-per-customer / punchline
La multi-tenancy cesse d'être un problème d'architecture. Elle devient une commande `cp`.
ONBOARDING
POST /containers/$TEMPLATE/copyOFFBOARDING
DELETE /containers/$CIDTWEAK PAR TENANT
PATCH /containers/$CID [ env_vars ]- isolation niveau namespace
- RGPD delete en un appel
- un conteneur par compte
use-cases / one-sandbox-per-customer / replaces
Ce que ça remplace
L'isolation par tenant a historiquement signifié soit un WHERE astucieux, soit un cluster cher. Conteneur-par-client déplace les contournements habituels :
- Multi-tenancy partagée (colonne tenant_id)Une mauvaise requête expose tout le monde
- Middleware d'isolation tenant maisonUn garde fait main que vous maintenez à vie
- Politiques row-level security PostgresLa bonne réponse, coûteuse à auditer par table
- Namespace Kubernetes par tenantSurcoût niveau cluster, équipe ops requise
- Schémas / databases par clientMultiplicateur de migration, douleur du connection-pool
- Lignes de metering Stripe dans une table partagéeTracking d'usage collé sur la même boîte partagée
use-cases / one-sandbox-per-customer / cta
Les clients inactifs ne coûtent rien. Les actifs scalent à la demande. Le tout tourne sur $49 de bare-metal jusqu'à des centaines d'utilisateurs payants.
use-cases / one-sandbox-per-customer / related