Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Containers·Snapshots
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeKostenoptimierungFürDev TeamsFürDevOps & InfraServicesContainersServicesSnapshotsWarum HoodyContainer-ÖkonomieWarum HoodySnapshot-Zeitreisen
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeKostenoptimierungFürDev TeamsFürDevOps & InfraServicesContainersServicesSnapshotsWarum HoodyContainer-ÖkonomieWarum HoodySnapshot-Zeitreisen
use-cases / kill-the-staging-tax / hero
CONTAINERS · SNAPSHOTS · COST
Schluss mit der Staging-Server-Steuer
Die meisten Teams zahlen für Production und dann nochmal für einen Staging-Stack, der ungefähr wie Production aussieht. Auf Hoody ist Staging ein Snapshot des Production-Containers — auf demselben Bare Metal abgezweigt, wenn jemand ihn braucht, zurück auf die Disk eingefroren, wenn nicht.
billing.containers.hoody.com
https://billing.containers.hoody.com/staging-cost-auditaudit · gespart
VORHER · DUPLIZIERTER STACKwas du früher bezahlt hast
- prod EC2 m5.large70 $us-east-1 · 24×70,096 $/Std · × 730 h
- staging EC2 m5.large70 $us-east-1 · 24×7 idle0,096 $/Std · × 730 h
- RDS prod (db.t3.medium)281 $Multi-AZ · 100 GB gp30,380 $/Std · × 730 h
- RDS staging (db.t3.medium)281 $driftet von prod weg0,380 $/Std · × 730 h
MONATSSUMME702 $ / Monat
NACHHER · SNAPSHOT VON PRODwas du jetzt zahlst
- prod-Container49 $Hoody Bare-Metal · 24×70,067 $/Std
- staging-from-snapshot0 $on demand abgezweigt · ~12 h/Wonur Delta
- keine zweite Box · keine zweite DB · kein Drift
MONATSSUMME49 $ / Monat
MONATLICHES DELTA
−653 $93 % gespart
# prod snapshotten, dann staging on demand davon abzweigencurl -X POST api/v1/containers/$PROD/snapshotscurl -X POST api/v1/containers/$PROD/copy -d '{"source_snapshot":"prod-baseline"}'
COPY-ON-WRITEgeteilte Base · nur Deltas bezahlt
ein tatsächliches Lesen der Spalte, die die meisten Teams schon haben, aber nicht auditieren
use-cases / kill-the-staging-tax / mechanism
Drei Calls. Ein Snapshot. Kein Duplikat-Stack.
Snapshots sind auf Hoody günstig, weil der Storage-Layer Copy-on-Write ist. Das Base-Image wird referenziert, nicht kopiert. Staging teilt sich die Pages mit Production, bis etwas auseinanderläuft — dann wird nur das Delta bezahlt.
01
STEP 01Snapshot von prod machen
POST /containers/$PROD/snapshots mit einem Alias. Das Base-Image bleibt referenziert; nur die Metadaten sind neu. Der Call liefert innerhalb einer Sekunde einen Snapshot-Namen zurück.
02
STEP 02Staging davon abzweigen
POST /containers/$PROD/copy mit source_snapshot=prod-baseline. Ein neuer Container startet auf derselben Hardware und teilt sich Pages mit prod. Schreibvorgänge gehen in ein Delta — Staging wird nur für das berechnet, was es ändert.
03
STEP 03Einfrieren, wenn idle
Stoppe den Staging-Container, wenn QA fertig ist. Disk bleibt erhalten, RAM und CPU fallen auf null. In 5–15 Sekunden wieder hoch, sobald das nächste Ticket reinkommt. Drift ist unmöglich, weil jeder Branch von einem bekannten Prod-Stand startet.
shell · gegen die Hoody Containers API
POST · snapshot + copy# 1. Production snapshotten — Alias geben, damit Menschen es findencurl -X POST https://api.hoody.com/api/v1/containers/$PROD/snapshots \ -H 'Authorization: Bearer $TOKEN' \ -d '{"alias":"prod-baseline","expiry":30}'# 2. Staging von genau diesem Snapshot abzweigencurl -X POST https://api.hoody.com/api/v1/containers/$PROD/copy \ -d '{"target_project_id":"$STAGING","source_snapshot":"prod-baseline"}'→ 200 OK · Staging-Container startet in 5–15 s, zahlt nur das Delta
Snapshots können eine Expiry in Tagen tragen; Cleanup ist automatisch. Copies können eine andere target_project_id und target_server_id wählen, sodass QA in einer separaten Region oder Sub-Account leben kann, ohne das Rezept zu ändern.
use-cases / kill-the-staging-tax / powers
Was das Wegfallen des Duplikats freischaltet
Wenn Staging ein Branch statt einer parallelen Miete ist, hören mehrere wiederkehrende Plagen auf zu existieren. Die Rechnung ist nur die sichtbarste davon.
BUDGET
Ein Stack, nicht drei
Production, Staging und QA waren früher drei Mieten, die du separat abgerechnet hast. Jetzt sind sie ein Container plus zwei günstige Branches, die aufwachen, wenn nötig. Die marginale Umgebung kostet ein Delta, kein Duplikat.
FIDELITÄT
Drift wird unmöglich
Jeder Staging-Branch startet von einem echten Production-Snapshot — dasselbe OS-Image, dieselben Pakete, dieselbe Datenform, dieselben Env-Vars. Die Bug-Klasse „läuft auf Staging, bricht auf Prod“ ist by design geschlossen.
TEMPO
In Sekunden wiederherstellen, nicht in Stunden
PATCHe den Container gegen einen älteren Snapshot, um einen schlechten Deploy zurückzudrehen, oder zweige eine frische QA-Kopie vom Backup von letzter Nacht ab. Kein rsync, kein DB-Dump, kein 90-Minuten-Provision-Job — nur ein Snapshot-Name.
use-cases / kill-the-staging-tax / ledger
Das Monats-Ledger, mit entferntem Duplikat
Derselbe Workload — Production, Staging, QA — auf zwei Arten gerechnet. Einmal als drei volle Mieten, einmal als ein Container mit zwei Snapshot-Branches.
VORHER · DUPLIKAT-STACK702 $ / Monat
Zwei EC2 m5.large für 0,096 $/Std (730 Stunden), plus zwei db.t3.medium Multi-AZ RDS-Instanzen für 0,380 $/Std. Staging die meiste Zeit der Woche idle; den Zähler stört das nicht.
DELTA · WAS BEZAHLT WIRDnur Delta
Staging zweigt von einem Prod-Snapshot ab. Geteilte Pages werden referenziert, nicht dupliziert. Nur die Bytes, die ein QA-Run wirklich schreibt, werden abgerechnet — meist ein paar hundert MB statt 100 GB.
NACHHER · EIN CONTAINER49 $ / Monat
Ein Hoody Container fährt prod 24×7. Staging und QA wachen aus einem Snapshot auf, wenn Arbeit sie braucht, und frieren zurück auf die Disk, wenn nicht. Eine Rechnung, drei Umgebungen, kein Drift.
AWS-Preise nutzen die öffentlichen On-Demand-Raten für us-east-1 EC2 m5.large und RDS db.t3.medium Multi-AZ Stand Anfang 2026. Der Hoody-Container-Preis ist illustrativ und hängt vom Underlying-Server ab (Marketplace-Preise ab 20 $/Monat aufwärts); Snapshot-Storage wird nach Delta-Größe abgerechnet. Die gezeigten Zahlen sind ein repräsentativer Vergleich, kein Angebot.
use-cases / kill-the-staging-tax / punchline
Staging war früher ein Duplikat von Production. Jetzt ist es ein Snapshot davon.
VORHER · ZWEI MIETEN, EIN ZWECKprod mieten, staging mieten, beide per Hand syncenzwei EC2s · zwei RDSs · zwei Monitore · eine driftende Kopie
NACHHER · EIN CONTAINER, VIELE ANSICHTENsnapshot $PROD → copy mit source_snapshotgeteilte Base · Delta-only-Branches · driftfrei by design
use-cases / kill-the-staging-tax / replaces
Was das ersetzt
Die Standardwege, wie Teams die Staging-Steuer zahlen. Jeder rechnet dir eine Umgebung ab, die die meiste Woche idle ist oder bis zu dem Zeitpunkt, an dem du sie brauchst, von prod weggedriftet ist.
- AWS-EC2-Staging-DuplikateZweite VM, abgerechnet 730 h/Monat für 12 h Nutzung
- parallele Heroku-Staging-DynosPro-Dyno- + pro-Add-on-Rechnung, die meiste Zeit idle
- mehrere VPS für Env-LayerLineare Kosten in Umgebungen — drei Boxen, drei Rechnungen
- Custom Drift-Detection-ToolsTooling, um die Lücke zwischen Staging und Prod zu finden
- „wir haben kein Staging“-RisikoDer Bug shippt, weil prod abzuzweigen zu teuer war
- RDS-Staging-ReplicasZweite Datenbank, die in Sync gehalten werden muss, 24×7 auf dem Zähler
use-cases / kill-the-staging-tax / cta
Hör auf, eine Umgebung zu mieten, die driftet. Zweige eine ab, die es nicht kann.
use-cases / kill-the-staging-tax / related
Lies die anderen
