bootAM HORIZONT — BALD
⚓ idle harbor
Aktiviere eine Option und die microVM deiner App wird in einen Snapshot pausiert wenn der Verkehr stoppt. Während sie schläft, zahlst du nur für den Speicher der geparkten VM — keinen Cent Rechenleistung. Die nächste Anfrage weckt sie in ~150–300 ms.
🧮 was es wirklich spart
Snapshot-Speicher kostet 0,05 €/GB-Monat — derselbe Tarif wie ein Backup. Ein typischer microVM-Snapshot hat etwa die Größe seiner RAM-Zuteilung.
Compute wird pro Sekunde im Wachzustand abgerechnet, Snapshot-Speicher pro Sekunde im Schlaf. Keine Rundung, keine Mindestbeträge.
🗺️ aktivieren
Im Portal gibt es einen Ein-Klick-Schalter für jeden Service. Das Idle-Fenster ist von 1 Minute bis 24 Stunden konfigurierbar — kürzer für Webhooks, die sofort reagieren sollen, länger für Services, bei denen das erste Aufwachen eine kurze Verzögerung verträgt.
⚙️ was passiert, Schritt für Schritt
💡 gemacht für
Nebenprojekte & Demos
Dein Portfolio bekommt drei Besucher pro Woche. Immer-an sind 2 €/Monat; im Harbor kostet ein 512-MB-Snapshot etwa 0,05 €/Monat — dieselbe App, ein Bruchteil der Rechnung.
Webhooks & Integrationen
Ein Empfänger, der feuert, wenn Stripe, GitHub oder n8n ihn aufruft. 23 von 24 Stunden im Schlaf, wach sobald ein Payload ankommt — der Sender merkt die 300 ms nicht.
Staging- & Preview-Umgebungen
Zehn offene PRs heißt zehn Preview-Instanzen. Immer-an sind 20 €+/Monat für Umgebungen, die nach 17 Uhr niemand ansieht. Im Harbor schläft jede, wenn der Reviewer den Tab schließt.
Interne Tools
Das Admin-Dashboard, der Report-Generator, das Wiki, das sonntags niemand liest. Tools, die du Stunden pro Woche nutzt, sollten nicht Stunden pro Monat kosten.
Funktionsartige Dienste
Eine API, die auf Anfrage Bilder umwandelt oder PDFs rendert, verhält sich wie eine Funktion — ohne Umschreiben für eine FaaS-Runtime. Deploy denselben Container und lass Harbor auf fast null skalieren.
Bots & Assistenten
Chatbots und KI-Agenten, die auf Erwähnungen reagieren, schlafen zwischen Gesprächen. Wake-on-Request hält das Tempo; die Wallet behält ihre Münzen.
Persönliche Dev-Umgebungen
Deine Cloud-Devbox mit all deinen Tools. Aktiv beim Coden, schlafend sonst. Kein Zahlen mehr für untätige Rechenleistung zwischen Abendsession und Morgen-Standup.
Geplante Batch-Jobs
Ein Dienst, der um 03:00 Reports rechnet und den Rest des Tages idle ist. Park ihn zwischen Läufen; ein Cron-Wecksignal (oder ein simpler HTTP-Call) bringt ihn genau dorthin zurück, wo er aufhörte.
Worker & Prozessoren
Ein HTTP-getriggerter Worker, der die Aufgabe erledigt — ein Video transkodieren, ein Bild skalieren — und dann bis zum nächsten schläft. Der Dispatcher weckt ihn auf Abruf, du zahlst nur die Sekunden des Rechnens.
Edge-artige Request-Handler
Ein HTTP-Handler, der sich wie eine Serverless-Funktion verhält — eine Anfrage rein, eine Antwort raus — aber in einer vollen Linux-microVM ohne Beschränkungen läuft und deinen exakten Prozess wiederherstellt, keinen leeren Container.
🔬 unter der Haube
Für die Neugierigen: Idle Harbor nutzt Firecracker snapshot/restore — dieselbe Technologie, die AWS für Lambda-Cold-Starts verwendet, nur dass der Snapshot hier deinen laufenden Prozess bewahrt statt einer vorinitialisierten, leeren VM. Der Snapshot erfasst den vollständigen Speicherzustand: Heap, Stack, offene File-Deskriptoren, alles, was dein Prozess gerade in Arbeit hatte.
- Verschlüsselt im Ruhezustand. Die Snapshot-Datei ist LUKS-verschlüsselt unter einem Schlüssel pro Dienst, der in OpenBao liegt — dieselbe Haltung wie bei deinen Volumes und Backups. Nicht einmal wir können sie im Ruhezustand lesen.
- Uhr beim Aufwachen resynchronisiert. Die Zeit ist gesprungen, während dein Prozess eingefroren war. Wir resynchronisieren die Gast-Uhr, bevor der Prozess weiterläuft, damit TLS-Caches, Rate-Limiter und alles andere Zeitabhängige korrekt anknüpft.
- RNG neu geseedet. Einen RNG-Zustand nach einem Snapshot-Restore zu wiederholen wäre ein Sicherheitsproblem. Wir seeden den Entropie-Pool des Gasts neu, bevor dein Code wieder läuft.
- TCP-Verbindungen. Vor-Snapshot-Verbindungen sind tot, sobald die VM aufwacht — das Idle-Fenster garantiert, dass kein Aufrufer wartet. Neue Verbindungen werden nach dem Aufwachen normal aufgebaut. Wenn du auf persistente ausgehende Verbindungen angewiesen bist (Database-Pools, Queue-Consumer), sollte dein App-Code beim Start ohnehin neu verbinden; Idle Harbor macht das explizit.
- Node-Mobilität. Ist der ursprüngliche Node voll, wenn du aufwachen musst, wird der Snapshot über das interne VLAN auf einen Node mit freier Kapazität übertragen. Gleiche Region, gleiches Latenzprofil — du merkst es nicht.
- Volumes bleiben angehängt. Hat dein Dienst LUKS-verschlüsselte Volumes, werden sie vor dem Snapshot sauber unmountet und beim Aufwachen neu geöffnet. Kein Datenverlust, keine Journal-Korruption.
⚖️ wann nicht zu verwenden
Idle Harbor ist nicht für Immer-an-Workloads:
- Langlebige WebSocket-Verbindungen. Clients trennen sich, sobald die VM schläft. Nutze ein Immer-an-Boot für Echtzeit-Apps.
- Queue-Consumer. Ein Consumer, der durch Nachrichten schläft, ist kaputt. Halte ihn immer-an oder nutze ein geplantes Wecksignal.
- Apps mit internem Cron. Plant deine App eigene Hintergrundarbeit, verschläft sie den Plan. Externalisiere den Trigger (ein Cron-HTTP-Call) und es klappt.
- Latenzkritische Pfade. Die erste Anfrage nach dem Schlaf dauert ~150–300 ms länger. Unsichtbar für Menschen; ein Problem für Zahlungsabwickler oder Health-Checks mit engem SLA.
Harbor ist eine Option, die du pro Dienst aktivierst, nie Standard. Die meisten Teams lassen ihre Prod-App immer-an und parken den Rest.