bootÀ L'HORIZON — BIENTÔT
⚓ idle harbor
Activez une option et la micro-VM de votre app est suspendue dans un instantané quand le trafic cesse. Pendant qu'elle dort, vous ne payez que le stockage de la VM en sommeil — pas un centime de calcul. La requête suivante la réveille en moins d'une seconde.
🧮 ce que ça économise vraiment
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.
🗺️ l'activer
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.
⚙️ ce qui se passe, étape par étape
💡 fait pour
Projets perso & démos
Votre portfolio reçoit trois visiteurs par semaine. En continu c'est 2 €/mois ; en sommeil, un instantané de 512 Mo coûte environ 0,05 €/mois — la même app, une fraction de la facture.
Webhooks & intégrations
Un récepteur qui se déclenche quand Stripe, GitHub ou n8n appelle. Endormi 23 heures sur 24, réveillé dès qu'un payload arrive — l'expéditeur ne remarque pas les 300 ms.
Environnements de staging & preview
Dix PR ouvertes, dix instances de preview. En continu, c'est 20 €+/mois pour des environnements que personne ne regarde après 17 h. En sommeil, chacun s'endort quand le relecteur ferme l'onglet.
Outils internes
Le tableau de bord admin, le générateur de rapports, le wiki que personne ne lit le dimanche. Des outils utilisés des heures par semaine ne devraient pas facturer des heures par mois.
Services de type fonction
Une API qui transforme des images ou rend des PDF à la demande se comporte comme une fonction — sans réécrire pour un runtime FaaS. Déployez le même conteneur et laissez harbor descendre à presque zéro.
Bots & assistants
Les bots et agents IA qui répondent aux mentions dorment entre les conversations. Le réveil à la demande garde le rythme ; le portefeuille garde ses pièces.
Environnements de dev personnels
Votre box de dev cloud avec tous vos outils. Active quand vous codez, endormie sinon. Fini de payer le calcul inactif entre votre session du soir et le standup du matin.
Tâches batch planifiées
Un service qui calcule des rapports à 03:00 et reste inactif le reste du jour. Mettez-le en sommeil entre les exécutions ; un signal cron (ou un simple appel HTTP) le ramène exactement où il s'était arrêté.
Workers & processeurs
Un worker déclenché par HTTP qui fait le travail — transcoder une vidéo, redimensionner une image — puis dort jusqu'au suivant. Le dispatcher le réveille à la demande, vous ne payez que les secondes de calcul.
Gestionnaires de requêtes type edge
Un gestionnaire HTTP qui se comporte comme une fonction serverless — une requête, une réponse — mais tourne dans une vraie micro-VM Linux sans restrictions, restaurant votre processus exact, pas un conteneur vide.
🔬 sous le capot
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.
⚖️ quand ne pas l'utiliser
Idle Harbor n'est pas pour les charges toujours actives :
- Connexions WebSocket de longue durée. Les clients se déconnectent dès que la VM dort. Utilisez un bateau toujours actif pour le temps réel.
- Consommateurs de file. Un consommateur qui dort à travers les messages est cassé. Gardez-le actif, ou utilisez un réveil planifié.
- Apps avec cron en interne. Si votre app planifie son propre travail de fond, elle dort à travers le planning. Externalisez le déclencheur (un appel HTTP cron) et ça marche.
- Chemins critiques en latence. La première requête après un sommeil prend ~150–300 ms de plus. Invisible pour un humain ; un problème pour les processeurs de paiement ou les health-checks à SLA serré.
Harbor est une option que vous activez par service, jamais par défaut. La plupart des équipes laissent leur app de prod toujours active et mettent le reste en sommeil.