bootAAN DE HORIZON — BINNENKORT
⚓ idle harbor
Zet één optie aan en de microVM van je app wordt opgeslagen als snapshot wanneer het verkeer stopt. Terwijl hij slaapt betaal je alleen voor de opslag van de geparkeerde VM — geen cent rekenkracht. Het volgende verzoek wekt hem in ~150–300 ms.
🧮 wat het echt bespaart
Snapshot-opslag kost €0,05/GB-maand — hetzelfde tarief als een back-up. Een typische microVM-snapshot is ongeveer zo groot als zijn RAM-toewijzing.
Rekenkracht wordt per seconde gefactureerd terwijl hij wakker is, snapshot-opslag per seconde terwijl hij slaapt. Geen afronding, geen minimum.
🗺️ aanzetten
Het portaal heeft een één-klik-schakelaar op elke service. Het idle-venster is instelbaar van 1 minuut tot 24 uur — korter voor webhooks die direct moeten voelen, langer voor services waar de eerste wake een korte vertraging aankan.
⚙️ wat er gebeurt, stap voor stap
💡 gemaakt voor
Zijprojecten & demo's
Je portfoliostuk krijgt drie bezoekers per week. Altijd-aan is €2/maand; in de harbor kost een 512 MB-snapshot zo'n €0,05/maand — dezelfde app, een fractie van de rekening.
Webhooks & integraties
Een ontvanger die afgaat als Stripe, GitHub of n8n belt. 23 van de 24 uur in slaap, wakker zodra een payload binnenkomt — de verzender merkt de 300 ms niet.
Staging- & preview-omgevingen
Tien open PR's betekent tien preview-instances. Altijd-aan is €20+/maand voor omgevingen waar na 17 uur niemand naar kijkt. In de harbor slaapt elke omgeving zodra de reviewer het tabblad sluit.
Interne tools
Het admin-dashboard, de rapportgenerator, de wiki die niemand op zondag leest. Tools die je uren-per-week gebruikt zouden geen uren-per-maand mogen kosten.
Functie-achtige services
Een API die op verzoek beelden omzet of PDF's rendert gedraagt zich als een functie — zonder herschrijven voor een FaaS-runtime. Deploy dezelfde container en laat harbor naar bijna-nul schalen.
Bots & assistenten
Chatbots en AI-agenten die op mentions reageren slapen tussen gesprekken. Wake-on-request houdt het gesprekstempo; de wallet houdt zijn muntjes.
Persoonlijke dev-omgevingen
Je cloud-devbox met al je tools geïnstalleerd. Actief terwijl je codeert, in slaap als je dat niet doet. Niet meer betalen voor inactieve rekenkracht tussen je avondsessie en de ochtendstandup.
Geplande batchjobs
Een service die om 03:00 rapporten verwerkt en de rest van de dag idle is. Park hem tussen runs; een cron-wektrigger (of een simpele HTTP-call) brengt hem terug precies waar hij stopte.
Workers & processors
Een HTTP-getriggerde worker die de klus klaart — een video transcoderen, een beeld verkleinen — en dan slaapt tot de volgende. De dispatcher wekt hem op verzoek, dus je betaalt alleen de seconden dat hij rekent.
Edge-achtige request-handlers
Een HTTP-handler die zich gedraagt als een serverless functie — één verzoek erin, één antwoord eruit — maar draait in een volledige Linux-microVM zonder runtime-beperkingen, en herstelt je exacte proces, niet een lege container.
🔬 onder de motorkap
Voor de nieuwsgierigen: Idle Harbor gebruikt Firecracker snapshot/restore — dezelfde technologie die AWS gebruikt voor Lambda-cold-starts, behalve dat de snapshot hier je draaiende proces bewaart in plaats van een vooraf geïnitialiseerde lege VM. De snapshot legt de volledige geheugentoestand vast: heap, stack, open file descriptors, alles wat je proces onderweg had.
- Versleuteld in rust. Het snapshot-bestand is LUKS-versleuteld onder een sleutel per service, opgeslagen in OpenBao — dezelfde aanpak als bij je volumes en back-ups. Zelfs wij kunnen het in rust niet lezen.
- Klok hersynct bij het ontwaken. De tijd sprong vooruit terwijl je proces bevroren was. We hersynchroniseren de gastklok voordat het proces verdergaat, zodat TLS-caches, rate limiters en al het andere dat tijdgevoelig is correct verder loopt.
- RNG opnieuw geseed. Een RNG-toestand opnieuw afspelen na een snapshot-restore zou een beveiligingsprobleem zijn. We seeden de entropy-pool van de gast opnieuw voordat je code weer draait.
- TCP-verbindingen. Verbindingen van vóór de snapshot zijn dood tegen de tijd dat de VM ontwaakt — het idle-venster garandeert dat er geen beller wacht. Nieuwe verbindingen komen na het ontwaken normaal tot stand. Vertrouw je op blijvende uitgaande verbindingen (database-pools, queue-consumers), dan zou je app-code bij het opstarten sowieso opnieuw moeten verbinden; Idle Harbor maakt dat expliciet.
- Node-mobiliteit. Is de oorspronkelijke node vol wanneer je moet ontwaken, dan wordt de snapshot over het interne VLAN overgedragen naar een node met vrije capaciteit. Zelfde regio, zelfde latencyprofiel — je merkt er niets van.
- Volumes blijven aangekoppeld. Heeft je service LUKS-versleutelde volumes, dan worden ze netjes ontkoppeld vóór de snapshot en heropend bij het ontwaken. Geen dataverlies, geen journal-corruptie.
⚖️ wanneer níét te gebruiken
Idle Harbor is niet voor altijd-aan-workloads:
- Langlevende WebSocket-verbindingen. Clients verbreken zodra de VM slaapt. Gebruik een altijd-aan-boot voor realtime apps.
- Queue-consumers. Een consumer die door berichten heen slaapt is kapot. Houd hem altijd-aan, of gebruik een geplande-wektrigger.
- Apps met in-process cronjobs. Plant je app zelf achtergrondwerk, dan slaapt hij door het schema heen. Externaliseer de trigger (een cron-HTTP-call) en het werkt prima.
- Latency-kritieke paden. Het eerste verzoek na een slaap duurt ~150–300 ms langer. Onzichtbaar voor menselijke verzoeken; een probleem voor betaalverwerkers of strakke-SLA-healthchecks.
Harbor is een optie die je per service aanzet, nooit standaard. De meeste teams draaien hun productie-app altijd-aan en parkeren de rest.