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
POURÉquipes de devs
POURFondateurs solo
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURFondateurs solo
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURFondateurs solo
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
TYPEDébloqué
ÉTAPEFlotte
DIFFICULTÉModéré
MÉTIERSaaS multi-tenant
POURÉquipes de devs
POURFondateurs solo
SERVICESConteneurs
SERVICESSnapshots
SERVICESExec
POURQUOI HOODYÉconomie des conteneurs
POURQUOI HOODYIsolation bare-metal
use-cases / per-customer-sandboxes-fleet-scale / hero
CONTAINERS · SAAS MULTI-TENANT · ÉCHELLE FLOTTE
Sandboxes par client à l'échelle de la flotte
Huit cents conteneurs isolés sur trois serveurs bare-metal. Chaque client reçoit son propre filesystem, sa propre URL, son propre namespace kernel — une facture serveur à tarif fixe, pas de compteur par tenant. L'architecture honnête n'est plus celle qui coûte cher.
fleet.containers.hoody.com
https://fleet.containers.hoody.com/tenantsactif
TENANTS812
SERVEURS3
TOTAL / MOISflat rate
TENANTS · ACTIVITÉ 24H47 sur 812 affichés
CHAUDACTIFTIÈDEINACTIF
server-eu-1
FRANKFURT28747% UTIL
server-us-1
NEW YORK30452% UTIL
server-ap-1
SINGAPORE22138% UTIL
PAR TENANT / MOISper server812 COMPTES ACTIFS · MOYENNÉ
AILLEURSper tenantFARGATE / NAMESPACE / POD DÉDIÉ
tableau de bord ops flotte · 812 tenants sur 3 nœuds bare-metal · une facture à tarif fixe, pas de compteur par tenant
use-cases / per-customer-sandboxes-fleet-scale / mechanism
Comment un signup devient un des 812 sandboxes
votre webhook de billing tape un script Hoody Exec. Le script copie un conteneur client frais depuis le snapshot template, le nouveau tenant atterrit sur sa propre URL, et le tableau de bord flotte s'incrémente d'un. Trois appels HTTP, pas d'orchestrateur.
01 · WEBHOOK
Stripe appelle votre endpoint exec
POST /webhooks/signup
Un isolate V8 serverless. L'URL du webhook est juste un fichier TypeScript dans scripts/1/. Pas d'Express, pas de config serveur, pas de conteneur à lui.
02 · COPY
Le script clone le template client
POST /api/v1/containers/$TEMPLATE/copy
BTRFS copy-on-write — chaque nouveau conteneur ne consomme que le delta depuis le template sur le serveur loué. Les règles firewall et réseau clonent avec le snapshot. Atterrit sur le serveur de la flotte qui a de la marge.
03 · ROUTE
Nouvelle URL renvoyée à l'utilisateur
https://$PROJECT-$CID-...containers.hoody.com
L'endpoint authorize signé émet un conteneur_claim d'une heure. votre app redirige le client dans son propre sandbox. Temps total de signup : sous les soixante secondes.
Tout le pipeline tient en trois appels HTTP. Pas d'opérateur Kubernetes, pas de YAML namespace, pas d'admin cluster. La flotte ajoute des tenants comme une hash table ajoute des entrées — sauf que chaque entrée est un vrai conteneur Linux.
use-cases / per-customer-sandboxes-fleet-scale / economics
Le calcul qui rend l'isolation à l'échelle flotte peu chère
Leur modèle de facturation facture par tenant. Hoody facture par serveur. Une fois que l'unité de facturation passe de tenant à machine, le chiffre par tenant rétrécit à mesure que vous ajoutez de la densité — et la courbe s'aplatit à mesure que vous grandissez.
GRAND LIVRE FLOTTE · 812 TENANTS
# trois nœuds bare-metal, prix marketplace3 flat-rate servers · one monthly bill# moyenné sur eu-1, us-1, ap-1812 tenants (287 + 304 + 221)# le coût-par-tenant s'effondrebill ÷ 812 = cost shrinks as density grows
Ajouter les cent prochains tenants ne change pas la facture — ça change le diviseur. KSM dédoublonne les pages mémoire identiques entre conteneurs ; BTRFS copy-on-write garde les octets de l'image de base partagés sur le serveur. Chaque nouveau conteneur n'utilise que le delta depuis le template ; la facturation reste sur le serveur à tarif fixe.
PAR TENANT · AUTRES STACKS
- AWS FARGATE PAR TENANTvCPU + mémoire facturés par tâche, même inactif$8–25
- K8S NAMESPACE PAR TENANTSurcoût cluster amorti sur les namespaces$3–10
- POD TENANT DÉDIÉRAM + CPU réservés, payés chaud ou froid$5–15
- HOODY · CONTAINER PAR TENANTun prix serveur ÷ densité tenant — borné par la machine, pas par le comptetarif fixe
Le pricing serveur Hoody est marketplace-driven et varie selon la région, la spec et le vendeur. La flotte d'exemple utilise trois nœuds ; les serveurs marketplace démarrent à $1/mo et varient selon la région, la spec et la durée ; les estimations concurrentes sont des fourchettes illustratives issues du pricing public pour du compute par-tenant comparable. La densité suppose des charges SaaS typiques — des tenants inactifs la majeure partie de la journée. Les bases lourdes ou les charges IA demandent plus de marge par container.
use-cases / per-customer-sandboxes-fleet-scale / powers
Ce que conteneur-par-tenant débloque à ce prix
Une fois que l'isolation est peu chère, l'architecture cesse de faire des compromis. Les fonctionnalités que votre CFO bloquait deviennent des défauts.
ONBOARDING
Chaque nouveau client est à un `cp`
Webhook Stripe → Hoody Exec → POST /containers/$TEMPLATE/copy. Le nouveau tenant boote depuis le même snapshot que les autres. Baseline identique, futur isolé. Pas de colonnes tenant_id à passer, pas de ligne partagée à oublier.
OFFBOARDING
RGPD delete en un appel HTTP
DELETE /api/v1/containers/$CID. Le filesystem part, la SQLite part, les jobs cron partent, le journal d'audit part — parce qu'ils vivaient tous au même endroit. Pas de "DELETE … WHERE tenant_id … plus 12 autres tables que vous avez oubliées."
RAYON D'IMPACT
Le bug d'un tenant reste chez ce tenant
Le script en boucle d'un client tape les quotas CPU et RAM de son container. Les 811 autres conteneurs de la flotte ne s'en aperçoivent pas. Pas d'audits ressources partagées, pas de table de lock partagée, pas de connection pool partagé — les namespaces kernel font le travail d'isolation que la couche applicative simulait.
use-cases / per-customer-sandboxes-fleet-scale / punchline
L'isolation par tenant coûtait par tenant. Maintenant elle coûte par serveur.
AVANT3–25 $ / tenantfargate, namespace ou pod dédié
MAINTENANTune facture fixe812 sandboxes, 3 machines bare-metal, pas de compteur par tenant
use-cases / per-customer-sandboxes-fleet-scale / replaces
Ce que ça remplace
L'isolation par tenant a historiquement signifié soit une clause WHERE astucieuse, soit une facture par tenant. Conteneur-par-client à l'échelle flotte déplace les deux :
- AWS Fargate par tenantvCPU + RAM facturés par tâche, chaud ou froid
- Kubernetes par namespaceSurcoût cluster + control plane par tenant
- Multi-tenancy partagée avec filtrage tenant_idUn WHERE oublié et les données client fuient
- Surcoût Postgres row-level securityPolitique sur chaque table, audit sur chaque requête
- Pods tenant dédiésCompute réservé payé qu'il soit utilisé ou non
use-cases / per-customer-sandboxes-fleet-scale / cta
Huit cents tenants isolés sur les serveurs que votre laptop remplace. L'architecture honnête est enfin l'abordable.
use-cases / per-customer-sandboxes-fleet-scale / related