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 ~150–300 ms.
🧮 ce que ça économise vraiment
Le stockage d'instantané coûte 0,05 €/Go-mois — le même tarif qu'une sauvegarde. Un instantané de microVM typique fait environ la taille de son allocation de RAM.
Le calcul est facturé à la seconde en éveil, le stockage d'instantané à la seconde en sommeil. Pas d'arrondi, pas de minimum.
🗺️ l'activer
Le portail propose un interrupteur en un clic sur chaque service. La fenêtre d'inactivité est configurable de 1 minute à 24 heures — plus courte pour les webhooks qui doivent paraître instantanés, plus longue pour les services dont le premier réveil peut tolérer un léger délai.
⚙️ 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
Pour les curieux : Idle Harbor utilise Firecracker snapshot/restore — la même technologie qu'AWS utilise pour les démarrages à froid de Lambda, sauf qu'ici l'instantané préserve votre processus en cours d'exécution plutôt qu'une VM vierge pré-initialisée. L'instantané capture l'état mémoire complet : heap, stack, descripteurs de fichiers ouverts, tout ce que votre processus avait en cours.
- Chiffré au repos. Le fichier d'instantané est chiffré en LUKS sous une clé par service stockée dans OpenBao — la même posture que vos volumes et sauvegardes. Même nous ne pouvons pas le lire au repos.
- Horloge resynchronisée au réveil. Le temps a sauté pendant que votre processus était gelé. Nous resynchronisons l'horloge du guest avant que le processus reprenne, pour que les caches TLS, les rate limiters et tout ce qui est sensible au temps repartent correctement.
- RNG réensemencé. Rejouer un état du RNG après une restauration d'instantané poserait un problème de sécurité. Nous réensemençons le pool d'entropy du guest avant que votre code ne tourne à nouveau.
- Connexions TCP. Les connexions d'avant l'instantané sont mortes au moment où la VM se réveille — la fenêtre d'inactivité garantit qu'aucun appelant n'attend. Les nouvelles connexions s'établissent normalement après le réveil. Si vous dépendez de connexions sortantes persistantes (pools de base de données, consommateurs de file), votre code applicatif devrait de toute façon se reconnecter au démarrage ; Idle Harbor le rend explicite.
- Mobilité entre nodes. Si le node d'origine est plein au moment où vous devez réveiller, l'instantané est transféré sur le VLAN interne vers un node ayant de la capacité libre. Même région, même profil de latence — vous ne le remarquerez pas.
- Les volumes restent attachés. Si votre service a des volumes chiffrés en LUKS, ils sont proprement démontés avant l'instantané et rouverts au réveil. Aucune perte de données, aucune corruption de journal.
⚖️ 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.