Scaling & Idle Harbor

Run as many copies of a service as you need, let bootload scale them with load, or drop anchor entirely and pay nothing while it sleeps. Because billing is per-second, scaling down is the same as saving money — a service at zero replicas costs nothing to run.

Manual scaling

Set the number of replicas yourself:

bootload scale <service> --replicas 3

Replicas are horizontal copies of the same image behind one route; traffic is balanced across the healthy ones.

Drop anchor (scale to zero)

bootload scale <service> --replicas 0

This stops every replica — no compute billing while it's anchored. Storage (volumes, images) is still kept and still metered; only the running cost stops. Scale it back up with --replicas 1 when you need it.

Horizontal autoscaling

Let bootload add and remove replicas to hold a target CPU level:

bootload scale <service> --min 1 --max 5 --target-cpu 70

bootload keeps replicas between min and max, adding capacity when average CPU rises above the target and removing it when load falls. --target-cpu is what switches autoscaling on; --replicas switches it back to manual.

Vertical memory autoscaling

For a workload whose memory needs grow, cap the out-of-memory ladder instead of guessing a fixed size:

bootload scale <service> --autoscale-memory max=2048

bootload steps the replica's memory up the ladder as it approaches its limit, up to the cap you set (in MB). max=0 turns it off.

Idle Harbor — sleep when idle, wake on demand ⚓

For request-driven services that sit quiet between bursts, Idle Harbor scales them to zero when idle and wakes them on the next request — so you pay for compute only while traffic is actually arriving.

bootload idle-harbor <service> on
bootload idle-harbor <service> on --idle-after 300
bootload idle-harbor <service> off

After a period with no traffic (default 900 seconds, or whatever you set with --idle-after), the service sleeps. The next incoming request wakes it — the first request after a sleep waits for the cold start, then it's warm again.

While sleeping, bootload keeps a snapshot so the wake is fast; that snapshot is billed as storage at €0.05 per GB-month — far less than running idle compute. Idle Harbor suits HTTP apps, internal tools, and bursty workloads; a service that must never miss a beat should stay at a fixed replica count instead.

Wake ahead of time — on a schedule or by webhook

Idle Harbor wakes a suspended service on the first request, which means that first visitor waits for the boot. If you know when traffic arrives, or another system knows, wake it early.

On a schedule (cron). Weekdays at 08:00 Brussels time, for example:

bootload wake schedule api --cron "0 8 * * 1-5" --tz Europe/Brussels

Cron is the usual 5 fields (minute, hour, day, month, weekday), evaluated in the timezone you give. The service is awake, and billed, from each fire until its idle window passes again, so * * * * * keeps it permanently on — use the idle window for that instead.

By webhook. Create a URL that wakes the service when something POSTs to it, a CI run finishing, a queue filling, your own scheduler:

bootload wake webhook api

You get a URL and a secret (shown once). The simplest call is curl -X POST "<url>?token=<secret>"; for a signed call send X-Bootload-Signature: t=<unix>,v1=<hex hmac-sha256(secret, "<unix>." + body)> (rejected after 5 minutes, so a captured request can't be replayed). The webhook answers 202 at once; add ?wait=1 to block until the service is healthy, handy right before you send the real traffic. Each URL is rate-limited to one wake per 30 seconds.

Right now. bootload wake api, or the "wake now" button on the service page. Waking never scales: a service you scaled to zero stays at zero and reports no_replica.

Manage triggers with bootload wake list|rm|rotate-secret|fires, from the scheduled-wake panel on the service page, or through the MCP tools services_wake and wake_triggers_*. This also works for services with no public route at all, an internal worker that nothing ever "visits".