bootEN EL HORIZONTE — PRÓXIMAMENTE
⚓ idle harbor
Activa una opción y la microVM de tu app queda suspendida en una instantánea cuando el tráfico cesa. Mientras duerme, solo pagas el almacenamiento de la VM aparcada — ni un céntimo de cómputo. La siguiente petición la despierta en menos de un segundo.
🧮 lo que de verdad ahorra
Snapshot storage costs €0.10/GB-month — the same rate as a volume. A typical microVM snapshot is about the size of its RAM allocation.
Compute is billed per second while awake, snapshot storage per second while asleep. No rounding, no minimums.
🗺️ activarlo
The portal has a one-click toggle on every service. The idle window is configurable from 1 minute to 24 hours — shorter for webhooks that should feel instant, longer for services where the first wake can afford a brief delay.
⚙️ qué pasa, paso a paso
💡 hecho para
Proyectos personales y demos
Tu portfolio recibe tres visitas por semana. Siempre activo son 2 €/mes; en harbor, una instantánea de 512 MB cuesta unos 0,05 €/mes — la misma app, una fracción de la factura.
Webhooks e integraciones
Un receptor que se dispara cuando llaman Stripe, GitHub o n8n. Dormido 23 de 24 horas, despierto en cuanto llega un payload — el emisor no nota los 300 ms.
Entornos de staging y preview
Diez PR abiertas son diez instancias de preview. Siempre activo son 20 €+/mes por entornos que nadie mira después de las 17 h. En harbor, cada uno duerme cuando el revisor cierra la pestaña.
Herramientas internas
El panel de admin, el generador de informes, el wiki que nadie lee el domingo. Las herramientas usadas horas por semana no deberían facturar horas por mes.
Servicios tipo función
Una API que transforma imágenes o renderiza PDF bajo demanda se comporta como una función — sin reescribir para un runtime FaaS. Despliega el mismo contenedor y deja que harbor escale a casi cero.
Bots y asistentes
Los bots y agentes de IA que responden a menciones duermen entre conversaciones. El despertar bajo demanda mantiene el ritmo; el monedero conserva sus monedas.
Entornos de desarrollo personales
Tu box de desarrollo en la nube con todas tus herramientas. Activo mientras programas, dormido cuando no. Se acabó pagar cómputo inactivo entre tu sesión de la tarde y el standup de la mañana.
Trabajos por lotes programados
Un servicio que procesa informes a las 03:00 y está inactivo el resto del día. Apárcalo entre ejecuciones; una señal cron (o una simple llamada HTTP) lo devuelve justo donde lo dejó.
Workers y procesadores
Un worker disparado por HTTP que hace el trabajo — transcodificar un vídeo, redimensionar una imagen — y duerme hasta el siguiente. El despachador lo despierta bajo demanda, solo pagas los segundos de cómputo.
Manejadores de peticiones tipo edge
Un manejador HTTP que se comporta como una función serverless — una petición, una respuesta — pero corre en una microVM Linux completa sin restricciones, restaurando tu proceso exacto, no un contenedor vacío.
🔬 bajo el capó
For the curious: Idle Harbor uses Firecracker snapshot/restore — the same technology AWS uses for Lambda cold starts, except here the snapshot preserves your running process rather than a pre-initialized blank VM. The snapshot captures the full memory state: heap, stack, open file descriptors, everything your process had in flight.
- Encrypted at rest. The snapshot file is LUKS-encrypted under a per-service key stored in OpenBao — the same posture as your volumes and backups. Not even we can read it at rest.
- Clock resynced on wake. Time jumped while your process was frozen. We resync the guest clock before the process continues, so TLS caches, rate limiters, and anything else time-sensitive picks up correctly.
- RNG reseeded. Replaying an RNG state after a snapshot restore would be a security problem. We reseed the guest's entropy pool before your code runs again.
- TCP connections. Pre-snapshot connections are dead by the time the VM wakes — the idle window guarantees no caller is waiting. New connections establish normally after wake. If you rely on persistent outbound connections (database pools, queue consumers), your app code should reconnect on startup anyway; Idle Harbor makes it explicit.
- Node mobility. If the original node is full when you need to wake, the snapshot is transferred over the internal VLAN to a node with free capacity. Same region, same latency profile — you won't notice.
- Volumes stay attached. If your service has LUKS-encrypted volumes, they're properly unmounted before the snapshot and re-opened on wake. No data loss, no journal corruption.
⚖️ cuándo no usarlo
Idle Harbor no es para cargas siempre activas:
- Conexiones WebSocket de larga duración. Los clientes se desconectan en cuanto la VM duerme. Usa un barco siempre activo para apps en tiempo real.
- Consumidores de cola. Un consumidor que duerme entre mensajes está roto. Mantenlo siempre activo o usa un despertar programado.
- Apps con cron interno. Si tu app programa su propio trabajo en segundo plano, dormirá durante el horario. Externaliza el disparador (una llamada HTTP cron) y funciona.
- Rutas críticas en latencia. La primera petición tras dormir tarda ~150–300 ms más. Invisible para humanos; un problema para procesadores de pago o health-checks con SLA ajustado.
Harbor es una opción que activas por servicio, nunca por defecto. La mayoría de los equipos dejan su app de producción siempre activa y aparcan el resto.