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 ~150–300 ms.
🧮 lo que de verdad ahorra
El almacenamiento de instantáneas cuesta 0,05 €/GB-mes — la misma tarifa que una copia de seguridad. Una instantánea típica de microVM ocupa más o menos lo que su asignación de RAM.
El cómputo se factura por segundo mientras está despierta, y el almacenamiento de la instantánea por segundo mientras duerme. Sin redondeos, sin mínimos.
🗺️ activarlo
El portal tiene un interruptor de un clic en cada servicio. La ventana de inactividad es configurable de 1 minuto a 24 horas — más corta para webhooks que deben sentirse instantáneos, más larga para servicios donde el primer despertar puede tolerar un breve retraso.
⚙️ 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 máquina de desarrollo en la nube con todas tus herramientas. Activa mientras programas, dormida 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ó
Para los curiosos: Idle Harbor usa Firecracker snapshot/restore — la misma tecnología que AWS usa para los arranques en frío de Lambda, salvo que aquí la instantánea preserva tu proceso en ejecución en lugar de una VM en blanco preinicializada. La instantánea captura el estado completo de memoria: heap, stack, descriptores de archivo abiertos, todo lo que tu proceso tenía en curso.
- Cifrado en reposo. El archivo de instantánea está cifrado con LUKS bajo una clave por servicio guardada en OpenBao — la misma postura que tus volúmenes y backups. Ni siquiera nosotros podemos leerlo en reposo.
- Reloj resincronizado al despertar. El tiempo saltó mientras tu proceso estaba congelado. Resincronizamos el reloj del guest antes de que el proceso continúe, para que las cachés de TLS, los limitadores de tasa y cualquier otra cosa sensible al tiempo lo retomen correctamente.
- RNG vuelto a sembrar. Repetir un estado de RNG tras restaurar una instantánea sería un problema de seguridad. Volvemos a sembrar el pool de entropía del guest antes de que tu código se ejecute de nuevo.
- Conexiones TCP. Las conexiones previas a la instantánea están muertas cuando la VM despierta — la ventana de inactividad garantiza que ningún cliente está esperando. Las conexiones nuevas se establecen con normalidad tras despertar. Si dependes de conexiones salientes persistentes (pools de base de datos, consumidores de cola), el código de tu app debería reconectar al arrancar de todos modos; Idle Harbor lo hace explícito.
- Movilidad entre nodos. Si el nodo original está lleno cuando necesitas despertar, la instantánea se transfiere por la VLAN interna a un nodo con capacidad libre. Misma región, mismo perfil de latencia — no lo notarás.
- Los volumes siguen adjuntos. Si tu servicio tiene volúmenes cifrados con LUKS, se desmontan correctamente antes de la instantánea y se reabren al despertar. Sin pérdida de datos, sin corrupción del journal.
⚖️ 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.