Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaEquipos de desarrolloParaDevOps e infraServiciosContainersServiciosSnapshotsPor qué HoodyEconomía de contenedoresPor qué HoodyViaje temporal de snapshots
TipoDesbloqueadoEtapaProducciónDificultadModeradoTrabajoOptimizar costesParaEquipos de desarrolloParaDevOps e infraServiciosContainersServiciosSnapshotsPor qué HoodyEconomía de contenedoresPor qué HoodyViaje temporal de snapshots
use-cases / kill-the-staging-tax / hero
CONTENEDORES · SNAPSHOTS · COSTE
Acaba con el impuesto del servidor de staging
La mayoría de los equipos paga por producción y luego paga otra vez por un stack de staging que se parece más o menos a producción. En Hoody, staging es un snapshot del contenedor de producción — ramificado en el mismo bare metal cuando alguien lo necesita, congelado de vuelta a disco cuando no.
billing.containers.hoody.com
https://billing.containers.hoody.com/staging-cost-auditauditoría · ahorrado
ANTES · STACK DUPLICADOlo que solías pagar
- EC2 prod m5.large70 $us-east-1 · 24×70,096 $/h · × 730 h
- EC2 staging m5.large70 $us-east-1 · 24×7 inactivo0,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 $alejándose de prod0,380 $/h · × 730 h
TOTAL MENSUAL702 $ / mes
DESPUÉS · SNAPSHOT DE PRODlo que pagas ahora
- contenedor prod49 $Hoody bare-metal · 24×70,067 $/h
- staging-from-snapshot0 $ramificado bajo demanda · ~12 h/semsolo delta
- sin segunda caja · sin segunda BD · sin drift
TOTAL MENSUAL49 $ / mes
DELTA MENSUAL
−653 $93% ahorrado
# snapshot de prod, luego ramifica staging desde él bajo demandacurl -X POST api/v1/containers/$PROD/snapshotscurl -X POST api/v1/containers/$PROD/copy -d '{"source_snapshot":"prod-baseline"}'
COPY-ON-WRITEbase compartida · solo se pagan los deltas
una lectura real de la columna que la mayoría de los equipos ya tiene pero no audita
use-cases / kill-the-staging-tax / mechanism
Tres llamadas. Un snapshot. Sin stack duplicado.
Los snapshots son baratos en Hoody porque la capa de almacenamiento es copy-on-write. La imagen base se referencia, no se copia. Staging comparte las páginas de producción hasta que algo diverge — entonces solo se paga por el delta.
01
PASO 01Toma un snapshot de prod
POST /containers/$PROD/snapshots con un alias. La imagen base sigue referenciada; solo los metadatos son nuevos. La llamada devuelve un nombre de snapshot en menos de un segundo.
02
PASO 02Ramifica staging desde él
POST /containers/$PROD/copy con source_snapshot=prod-baseline. Un nuevo contenedor arranca en el mismo hardware, compartiendo páginas con prod. Las escrituras van a un delta — staging solo se factura por lo que cambia.
03
PASO 03Congela cuando esté inactivo
Detén el contenedor de staging cuando QA termine. El disco persiste, RAM y CPU caen a cero. Restaura en 5–15 segundos cuando aterrice el siguiente ticket. El drift es imposible porque cada rama empieza desde un estado de prod conocido.
shell · contra la API de Hoody Containers
POST · snapshot + copy# 1. snapshot de producción — ponle alias para que los humanos lo encuentrencurl -X POST https://api.hoody.com/api/v1/containers/$PROD/snapshots \ -H 'Authorization: Bearer $TOKEN' \ -d '{"alias":"prod-baseline","expiry":30}'# 2. ramifica staging desde ese snapshot exactocurl -X POST https://api.hoody.com/api/v1/containers/$PROD/copy \ -d '{"target_project_id":"$STAGING","source_snapshot":"prod-baseline"}'→ 200 OK · el contenedor de staging arranca en 5–15 s, pagando solo el delta
Los snapshots pueden llevar caducidad en días; la limpieza es automática. Las copias pueden elegir un target_project_id y target_server_id distintos, así que QA puede vivir en otra región o subcuenta sin cambiar la receta.
use-cases / kill-the-staging-tax / powers
Qué desbloquea quitar el duplicado
Cuando staging es una rama en lugar de un alquiler paralelo, varias molestias recurrentes dejan de existir. La factura es solo la más visible.
PRESUPUESTO
Un stack, no tres
Producción, staging y QA solían ser tres alquileres que facturabas por separado. Ahora son un contenedor más dos ramas baratas que despiertan cuando se necesitan. El entorno marginal cuesta un delta, no un duplicado.
FIDELIDAD
El drift se vuelve imposible
Cada rama de staging arranca desde un snapshot de producción real — misma imagen de OS, mismos paquetes, misma forma de datos, mismas variables de entorno. La clase de bug 'funciona en staging, rompe en prod' queda cerrada por construcción.
VELOCIDAD
Restaura en segundos, no en horas
PATCH al contenedor contra un snapshot anterior para revertir un mal deploy, o ramifica una copia fresca de QA desde el backup de anoche. Sin rsync, sin DB dump, sin un trabajo de aprovisionamiento de 90 minutos — solo un nombre de snapshot.
use-cases / kill-the-staging-tax / ledger
El ledger mensual, con el duplicado eliminado
Misma carga de trabajo — producción, staging, QA — contada de dos formas. Una vez como tres alquileres completos, otra vez como un contenedor con dos ramas de snapshot.
ANTES · STACK DUPLICADO702 $ / mes
Dos instancias EC2 m5.large a 0,096 $/h (730 horas), más dos RDS db.t3.medium Multi-AZ a 0,380 $/h. Staging inactivo la mayor parte de la semana; al medidor le da igual.
DELTA · LO QUE SE PAGAsolo delta
Staging se ramifica desde un snapshot de prod. Las páginas compartidas se referencian, no se duplican. Solo se facturan los bytes que una corrida de QA escribe realmente — normalmente unos cientos de MB en lugar de 100 GB.
DESPUÉS · UN CONTENEDOR49 $ / mes
Un contenedor de Hoody maneja prod 24×7. Staging y QA despiertan desde un snapshot cuando el trabajo los necesita y se congelan en disco cuando no. Una factura, tres entornos, sin drift.
Los precios de AWS usan tarifas públicas on-demand para EC2 m5.large y RDS db.t3.medium Multi-AZ en us-east-1 a principios de 2026. Los precios de entrada bare-metal de Hoody comienzan en $29/mes y varían según especificación, región y duración del alquiler; snapshots y almacenamiento están incluidos en el precio del servidor. Los números mostrados son una comparación representativa, no una cotización.
use-cases / kill-the-staging-tax / punchline
Staging solía ser un duplicado de producción. Ahora es un snapshot de él.
ANTES · DOS ALQUILERES, UN PROPÓSITOalquila prod, alquila staging, sincroniza los dos a manodos EC2s · dos RDSs · dos monitores · una copia que se desvía
DESPUÉS · UN CONTENEDOR, MUCHAS VISTASsnapshot $PROD → copy con source_snapshotbase compartida · ramas solo-delta · sin drift por construcción
use-cases / kill-the-staging-tax / replaces
A qué sustituye esto
Las formas estándar en que los equipos pagan el impuesto de staging. Cada una te factura un entorno que está inactivo la mayor parte de la semana o se desvía de prod para cuando lo necesitas.
- Duplicados de staging en AWS EC2Segunda VM facturada 730 h/mes para 12 h de uso
- dynos paralelos de staging en HerokuFactura por dyno + por add-on, inactivo la mayoría de los días
- múltiples VPS por capa de entornoCoste lineal en entornos — tres cajas, tres facturas
- herramientas custom de detección de driftTooling para encontrar la brecha entre staging y prod
- riesgo "no tenemos staging"El bug se envía porque ramificar prod era demasiado caro
- réplicas de staging en RDSSegunda base de datos para mantener sincronizada, en el medidor 24×7
use-cases / kill-the-staging-tax / cta
Deja de alquilar un entorno que se desvía. Ramifica uno que no puede.
use-cases / kill-the-staging-tax / related
Lee los otros
