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.
La plupart des équipes paient pour la production, puis paient encore pour une stack de staging qui ressemble grosso modo à la production. Sur Hoody, le staging est un snapshot du conteneur de production — branché sur le même bare-metal quand quelqu'un en a besoin, regelé sur disque quand personne ne l'utilise.
une lecture réelle de la colonne que la plupart des équipes ont déjà mais n'auditent pas
Les snapshots sont peu chers sur Hoody parce que la couche de stockage est copy-on-write. L'image de base est référencée, pas copiée. Le staging partage les pages de la production jusqu'à ce que quelque chose diverge — alors seul le delta est payé.
POST /containers/$PROD/snapshots avec un alias. L'image de base reste référencée ; seules les métadonnées sont nouvelles. L'appel renvoie un nom de snapshot en moins d'une seconde.
POST /containers/$PROD/copy avec source_snapshot=prod-baseline. Un nouveau conteneur démarre sur le même hardware, partageant les pages avec prod. Les écritures vont dans un delta — staging n'est facturé que pour ce qu'il modifie.
Stop le conteneur staging quand le QA est fini. Le disque persiste, RAM et CPU tombent à zéro. Restaurez en 5–15 secondes au prochain ticket. La dérive est impossible parce que chaque branche démarre depuis un état prod connu.
Les snapshots peuvent porter une expiration en jours ; le nettoyage est automatique. Les copies peuvent choisir un target_project_id et target_server_id différents, donc le QA peut vivre sur une région ou un sous-compte séparé sans changer la recette.
Quand le staging est une branche au lieu d'une location parallèle, plusieurs nuisances récurrentes cessent d'exister. La facture n'est que la plus visible.
Production, staging et QA étaient trois locations facturées séparément. Maintenant c'est un conteneur plus deux branches peu chères qui se réveillent quand on en a besoin. L'environnement marginal coûte un delta, pas un doublon.
Chaque branche staging démarre depuis un vrai snapshot de prod — même image OS, mêmes paquets, même forme de données, mêmes env vars. La classe de bug 'marche en staging, casse en prod' est fermée par construction.
PATCH le conteneur contre un snapshot plus ancien pour rollback un mauvais déploiement, ou branchez une copie QA fraîche depuis le backup d'hier soir. Pas de rsync, pas de dump DB, pas de provisionnement de 90 minutes — juste un nom de snapshot.
Même charge — production, staging, QA — comptée de deux façons. Une fois comme trois locations complètes, une fois comme un conteneur avec deux branches snapshot.
Deux instances EC2 m5.large à $0.096/hr (730 heures), plus deux instances RDS Multi-AZ db.t3.medium à $0.380/hr. Staging inactif la majeure partie de la semaine ; le compteur s'en moque.
Staging branche depuis un snapshot de prod. Les pages partagées sont référencées, pas dupliquées. Seuls les octets qu'un run QA écrit réellement sont facturés — généralement quelques centaines de MB au lieu de 100 GB.
Un conteneur Hoody gère prod 24×7. Staging et QA se réveillent depuis un snapshot quand le travail les appelle, regèlent sur disque quand non. Une facture, trois environnements, aucune dérive.
Les prix AWS utilisent les tarifs publics on-demand pour us-east-1 EC2 m5.large et RDS db.t3.medium Multi-AZ début 2026. Le tarif d'entrée bare-metal Hoody démarre à $1/mo et varie selon la spec, la région et la durée de location ; les snapshots et le stockage sont inclus dans le prix du serveur. Les chiffres montrés sont une comparaison représentative, pas un devis.
Le staging était un doublon de la production. Maintenant c'est un snapshot.
Les façons standard dont les équipes paient la taxe staging. Chacune vous facture pour un environnement inactif la plupart de la semaine ou qui dérive de prod au moment où vous en avez besoin.
Arrêtez de louer un environnement qui dérive. Branchez-en un qui ne le peut pas.