Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Containers·Snapshots
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourÉquipes de devPourDevOps & infraServicesContainersServicesSnapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyVoyage dans le temps par snapshots
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourÉquipes de devPourDevOps & infraServicesContainersServicesSnapshotsPourquoi HoodyÉconomie des conteneursPourquoi HoodyVoyage dans le temps par snapshots
use-cases / kill-the-staging-tax / hero
CONTENEURS · SNAPSHOTS · COÛT
Supprimez la taxe du serveur de staging
La plupart des équipes paient pour la production, puis paient encore pour une stack de staging qui ressemble à peu près à 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 ce n'est plus le cas.
billing.containers.hoody.com
https://billing.containers.hoody.com/staging-cost-auditaudit · économisés
AVANT · STACK DUPLIQUÉEce que vous payiez avant
- prod EC2 m5.large70 $us-east-1 · 24×70,096 $/h · × 730 h
- staging EC2 m5.large70 $us-east-1 · 24×7 inactif0,096 $/h · × 730 h
- RDS prod (db.t3.medium)281 $Multi-AZ · 100 GB gp30,380 $/h · × 730 h
- RDS staging (db.t3.medium)281 $qui dérive de la prod0,380 $/h · × 730 h
TOTAL MENSUEL702 $ / mois
APRÈS · SNAPSHOT DE LA PRODce que vous payez maintenant
- conteneur prod49 $Hoody bare-metal · 24×70,067 $/h
- staging-from-snapshot0 $branché à la demande · ~12 h/semdelta uniquement
- pas de seconde machine · pas de seconde BD · pas de dérive
TOTAL MENSUEL49 $ / mois
DELTA MENSUEL
−653 $93 % économisés
# snapshot prod, puis branche staging à la demandecurl -X POST api/v1/containers/$PROD/snapshotscurl -X POST api/v1/containers/$PROD/copy -d '{"source_snapshot":"prod-baseline"}'
COPY-ON-WRITEbase partagée · seuls les deltas sont payés
une lecture réelle de la colonne que la plupart des équipes ont déjà mais n'auditent pas
use-cases / kill-the-staging-tax / mechanism
Trois appels. Un snapshot. Pas de stack en double.
Les snapshots sont bon marché 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é.
01
ÉTAPE 01Prendre un snapshot de la prod
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.
02
ÉTAPE 02Brancher le staging dessus
POST /containers/$PROD/copy avec source_snapshot=prod-baseline. Un nouveau conteneur démarre sur le même matériel, en partageant les pages avec la prod. Les écritures vont dans un delta — le staging n'est facturé que pour ce qu'il modifie.
03
ÉTAPE 03Geler quand inactif
Arrêtez le conteneur de staging quand la QA a fini. Le disque persiste, RAM et CPU tombent à zéro. Restauration en 5–15 secondes quand le prochain ticket arrive. La dérive est impossible parce que chaque branche part d'un état prod connu.
shell · contre l'API Hoody Containers
POST · snapshot + copy# 1. snapshot de la production — alias pour que les humains s'y retrouventcurl -X POST https://api.hoody.com/api/v1/containers/$PROD/snapshots \ -H 'Authorization: Bearer $TOKEN' \ -d '{"alias":"prod-baseline","expiry":30}'# 2. branche staging à partir de ce snapshot exactcurl -X POST https://api.hoody.com/api/v1/containers/$PROD/copy \ -d '{"target_project_id":"$STAGING","source_snapshot":"prod-baseline"}'→ 200 OK · le conteneur staging démarre en 5–15 s, ne paie que le delta
Les snapshots peuvent porter une expiration en jours ; le nettoyage est automatique. Les copies peuvent choisir un target_project_id et un target_server_id différents, donc la QA peut vivre dans une région ou un sous-compte séparé sans changer la recette.
use-cases / kill-the-staging-tax / powers
Ce que débloque la suppression du duplicata
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.
BUDGET
Une stack, pas trois
Production, staging et QA étaient autrefois trois locations facturées séparément. Maintenant, c'est un conteneur plus deux branches bon marché qui se réveillent au besoin. L'environnement marginal coûte un delta, pas un duplicata.
FIDÉLITÉ
La dérive devient impossible
Chaque branche de staging part d'un vrai snapshot de production — même image OS, mêmes paquets, même forme de données, mêmes variables d'environnement. La classe de bug « ça marche en staging, ça casse en prod » est éliminée par construction.
VITESSE
Restauration en secondes, pas en heures
PATCH le conteneur contre un snapshot plus ancien pour annuler un mauvais déploiement, ou branchez une copie QA fraîche depuis la sauvegarde de la nuit. Pas de rsync, pas de dump de BD, pas de provisioning de 90 minutes — juste un nom de snapshot.
use-cases / kill-the-staging-tax / ledger
Le grand livre mensuel, avec le duplicata supprimé
Même charge de travail — production, staging, QA — comptée de deux manières. Une fois comme trois locations complètes, une fois comme un conteneur avec deux branches snapshot.
AVANT · STACK EN DOUBLE702 $ / mois
Deux instances EC2 m5.large à 0,096 $/h (730 heures), plus deux instances RDS db.t3.medium Multi-AZ à 0,380 $/h. Staging inactif la majeure partie de la semaine ; le compteur s'en moque.
DELTA · CE QUI EST PAYÉdelta uniquement
Le staging part d'un snapshot de prod. Les pages partagées sont référencées, pas dupliquées. Seuls les octets qu'un run de QA écrit réellement sont facturés — généralement quelques centaines de Mo au lieu de 100 Go.
APRÈS · UN CONTENEUR49 $ / mois
Un conteneur Hoody gère la prod 24×7. Staging et QA se réveillent depuis un snapshot quand le travail le demande, regelent sur disque quand ce n'est plus le cas. Une facture, trois environnements, pas de 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 prix du conteneur Hoody est illustratif et dépend du serveur sous-jacent (tarifié par le marketplace à partir de 20 $/mois) ; le stockage des snapshots est facturé à la taille du delta. Les chiffres montrés sont une comparaison représentative, pas un devis.
use-cases / kill-the-staging-tax / punchline
Le staging était autrefois un duplicata de la production. Maintenant, c'est un snapshot.
AVANT · DEUX LOCATIONS, UN MÊME BUTlouer la prod, louer le staging, synchroniser les deux à la maindeux EC2 · deux RDS · deux monitorings · une copie qui dérive
APRÈS · UN CONTENEUR, PLUSIEURS VUESsnapshot $PROD → copy avec source_snapshotbase partagée · branches au delta seul · sans dérive par construction
use-cases / kill-the-staging-tax / replaces
Ce que cela remplace
Les manières standards dont les équipes paient la taxe du staging. Chacune vous facture un environnement inactif la majeure partie de la semaine ou qui dérive de la prod le moment venu.
- Duplicatas AWS EC2 stagingSeconde VM facturée 730 h/mois pour 12 h d'usage
- dynos parallèles Heroku stagingFacture par dyno + par add-on, inactive la plupart des jours
- plusieurs VPS pour les couches d'envCoût linéaire en environnements — trois machines, trois factures
- outils custom de détection de dériveOutillage pour trouver l'écart entre staging et prod
- le risque « on n'a pas de staging »Le bug part en prod parce que brancher la prod coûtait trop cher
- réplicas RDS stagingSeconde base de données à garder en sync, sur le compteur 24×7
use-cases / kill-the-staging-tax / cta
Arrêtez de louer un environnement qui dérive. Branchez-en un qui ne peut pas.
use-cases / kill-the-staging-tax / related
Découvrez les autres
