Un servidor. Contenedores ilimitados. Costo marginal $0.
La unidad fundamental del costo de infraestructura cambia de por-entorno a por-servidor. Una vez pagado el servidor, crear otro contenedor es gratis. Experimentos, entornos de rama, demos desechables, aislamiento por cliente — todo se vuelve el default en lugar de algo presupuestado.
Bare metal · densidad KSM · dedup BTRFS · 100% utilización de recursos · aislamiento físico incluido
De facturación por entorno a capacidad por servidor.
El modelo VPS trata cada entorno como un costo recurrente. El modelo bare-metal-más-contenedores trata el servidor como una decisión única de capacidad. Una vez que dejas de pagar por entorno, dejas de pensar en entornos.
VPS — facturación por entorno
- —Dev, staging, prod = tres líneas de factura
- —Entorno de rama = conversación de presupuesto
- —Sandbox personal = pagas incluso inactivo
- —Trabajo con clientes = un VPS por cliente, cada mes
Hoody — capacidad por servidor
- —Un alquiler de servidor cubre todos los entornos que quepan
- —Entorno de rama = una llamada a la API, gratis
- —Sandbox personal = arranca, usa, descarta
- —Trabajo con clientes = un contenedor por cliente en el mismo servidor
Un ejemplo concreto trabajado.
El doc 100x Foundation describe a un fundador en solitario con 12 productos SaaS a 3–5 contenedores por producto. Aquí está el mismo cálculo lado a lado. Los números exactos dependen del proveedor de servidor y la carga de trabajo — esto es la forma, no la hoja de precios.
| Line item | Traditional VPS | Hoody |
|---|---|---|
| Costo del servidor | $40/contenedor × 60 = $2.400/mes | $100/mes servidor bare metal |
| Añadir el contenedor #61 | +$40/mes cada mes para siempre | +$0 si entra en la capacidad del servidor |
| Contenedores inactivos | Precio completo igualmente | ~0 bytes vía KSM + dedup BTRFS |
| Hardware dedicado | Tier enterprise, ~$200–1000/mes | Incluido — el servidor ES el hardware |
Los costos son ilustrativos y dependen del proveedor de servidor, la carga de trabajo y cuánta densidad comparten realmente tus contenedores. La forma económica — costo marginal cero, capacidad compartida, inactivo es gratis — se mantiene entre proveedores.
Cuando los contenedores son gratis, los experimentos se vuelven el default.
La infraestructura tradicional hace que experimentar sea una decisión consciente con un costo de presupuesto asociado. Hoody hace que experimentar sea el camino de menor resistencia. Esto cambia silenciosamente cómo trabajan desarrolladores y agentes.
Entornos por rama
Cada rama git tiene un contenedor. Diez ramas abiertas = diez contenedores = misma factura que una rama.
Prueba de hipótesis en paralelo
Un agente IA probando 10 enfoques diferentes crea 10 contenedores. El que gana se conserva; los demás van a DELETE.
Staging que coincide exactamente con prod
No una aproximación. Misma imagen, misma config, misma fuente de snapshot — a costo cero adicional.
Demos de clientes bajo demanda
Arranca un contenedor demo para una llamada de ventas. Elimínalo después. Sin línea en la factura mensual.
El 100% del servidor que pagaste. Sin vecinos ruidosos. Sin impuesto por inactividad.
En VPS tradicional, pagas por recursos dedicados que la mayor parte del tiempo están inactivos. En una máquina bare metal compartida con KSM + dedup BTRFS, tus contenedores compiten solo por los recursos que realmente necesitan. Utilización completa disponible cuando la carga lo requiere; nada desperdiciado cuando no.
CPU: todos los núcleos, todos los contenedores
El scheduler de Linux da toda la máquina al contenedor que la necesite. Sin límite de vCPU por contenedor.
RAM: deduplicada vía KSM
Páginas comunes compartidas entre contenedores. 60 contenedores pueden usar menos RAM que 10 instancias VPS.
Disco: deduplicado vía BTRFS
Misma imagen base entre contenedores = bloques compartidos. El almacenamiento crece con la divergencia, no con el número de contenedores.
Red: sin cuota por contenedor
El ancho de banda de tu servidor es tu pool. Asígnalo según dicte tu carga de trabajo.
Bare metal es el baseline, no el tier enterprise.
En un VPS de nube pública, eres un tenant en un hypervisor compartido con extraños. Los ataques de canal lateral (Spectre, Meltdown) existen por ese compartir. En Hoody, el servidor es tuyo. Sin hypervisor compartido; sin superficie de ataque clase-Spectre de otros clientes por encima de ti.
Sin hypervisor compartido
Tus contenedores comparten el host entre sí — aislados vía LXC + Firecracker. Nunca comparten un host con extraños.
Aislamiento de cumplimiento incluido
Residencia de datos de clientes, aislamiento adyacente a HIPAA, reducción de scope PCI — todo se deriva de la propiedad del servidor.
Tú controlas el hardware
Alquila de OVH, Hetzner, Equinix, tu propia colo. Hoody corre sus contenedores en el metal que elijas.
Cuándo este modelo no sale rentable.
Honesto sobre los casos donde la economía no se invierte. El modelo por servidor brilla cuando puedes aprovechar la densidad. No brilla para cargas de trabajo que quieren un único contenedor gigante aislado.
Cargas de trabajo de un-contenedor-masivo
Si necesitas un único contenedor con decenas de CPUs y cientos de GB de RAM, de todos modos estás pagando por hardware exclusivo. El VPS en ese tier puede ser competitivo.
Tráfico muy pico
Un contenedor corriendo al 100% de CPU constantemente no deja densidad para los vecinos. El cálculo basado en densidad asume cierta diversidad en la carga de trabajo.
Requisitos de cero-ops
Si no puedes gestionar un servidor bare metal en absoluto, incluso con las herramientas de Hoody, Kubernetes gestionado o Fly.io encajará mejor. Algunos equipos quieren cero decisiones de hardware nunca.
Requisitos de latencia edge
¿Necesitas 20 POPs globales para una carga CDN? Alquila 20 servidores Hoody, o usa un proveedor especializado en edge. Una caja bare metal es un punto geográfico.
Deja de pagar por entornos. Paga por capacidad una vez.
Alquila un servidor. Crea todos los contenedores que vayas a usar. La factura deja de crecer con tu flujo de trabajo.
Ver también — /platform/control-plane para APIs de wallet y alquiler de servidores, /methods/efficiency-security para detalles de KSM + BTRFS.