bootON THE HORIZON — COMING SOON
⚓ idle harbor
Flip one option and your app's microVM is suspended to a snapshot when traffic stops. While it sleeps you pay only for the storage of the parked VM — not a cent of compute. The next request wakes it in under a second.
🧮 what it actually saves
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.
🗺️ enabling it
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.
⚙️ what happens, step by step
💡 made for
Side projects & demos
Your portfolio piece gets three visitors a week. With a dinghy always-on that's €2/month. Harbored, a 512 MB snapshot costs about €0.05/month — the same app, a fraction of the bill.
Webhooks & integrations
A receiver that fires when Stripe, GitHub, or n8n calls. Asleep 23 hours out of 24, awake the moment a payload arrives — the sender never notices the 300 ms.
Staging & preview environments
Ten open PRs means ten preview instances. Always-on, that's €20+/month for environments nobody looks at after 5 pm. Harbored, each one sleeps when the reviewer closes the tab.
Internal tools
The admin dashboard, the report generator, the wiki nobody reads on Sunday. Tools used hours-per-week shouldn't bill hours-per-month.
Function-style services
An API that transforms images or renders PDFs on demand behaves like a function — without rewriting for a FaaS runtime. Deploy the same container, let harbor do the scale-to-almost-zero.
Bots & assistants
Chat bots and AI agents that respond to mentions sleep between conversations. Wake-on-request keeps the conversational pace; the wallet keeps its coins.
Personal dev environments
Your cloud dev box with all your tools installed. Active while you're coding, asleep while you're not. No more paying for eight hours of idle compute between your evening session and the morning standup.
Scheduled batch jobs
A service that crunches reports at 03:00 and idles the rest of the day. Harbor it between runs; a cron wake signal (or a simple HTTP call from a scheduler) brings it back exactly where it left off.
Workers & processors
An HTTP-triggered worker that receives a job — transcode a video, resize an image, run a data pipeline — does the work, and sleeps until the next one. Unlike a polling queue consumer, the job dispatcher wakes the worker on demand. You pay only for the seconds it's actually crunching.
Edge-style request handlers
An HTTP handler that behaves like a serverless function — one request in, one response out — but runs in a full Linux microVM with no runtime restrictions. No FaaS API to rewrite for, no cold-boot penalty beyond the first warm-up: the snapshot restores your exact process, not a blank container.
🔬 under the hood
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.
⚖️ when not to use it
Idle Harbor is not for always-on workloads:
- Long-lived WebSocket connections. Clients would disconnect the moment the VM sleeps. Use an always-on boat for real-time apps.
- Queue consumers. A consumer sleeping through messages is a broken consumer. Keep it always-on or use a proper scheduled-wake signal instead.
- Apps with in-process cron jobs. If your app schedules its own background work, it will sleep through the schedule. Externalise the trigger (a cron HTTP call) and it works fine.
- Latency-critical paths. The first request after a sleep takes ~150–300 ms longer than normal. That's invisible for human-initiated requests; it's a problem for payment processors or health checks with tight SLAs.
Harbor is an option you enable per service, never a default. Most teams run their production app always-on and harbor everything else.