Autoscaling

Run a service on more than one instance, and let HostStack add and remove instances as CPU, memory or request rate rise and fall. You set the floor, the ceiling and the thresholds.

How it works

Every 30 seconds, HostStack reads each autoscaled service's CPU and memory — averaged across its running instances — and its requests per second at the edge. It compares them with your thresholds and, after a sustained run of readings on one side, adds or removes one instance.

A new instance is a copy of the running container, added to the service's load balancer as soon as it starts; scaling does not rebuild or redeploy. Removing an instance takes it out of the load balancer first and waits 30 seconds for in-flight requests before stopping it. The newest instance goes first.

Autoscaling is on for any service whose maximum is more than one instance. With a maximum of one, the service runs exactly one instance.

Turn on autoscaling

In the dashboard, open the service's Settings, then Size & Scaling. In the Autoscaling card, set Max Instances above 1, adjust the thresholds, and click Save Scaling Settings. Changes apply to the running service straight away — no redeploy.

# Between 2 and 5 instances
hoststack services scale svc_... 2:5

# Thresholds
hoststack services update svc_... \
  --scale-cpu-threshold 70 \
  --scale-memory-threshold 85

await hs.services.updateConfig(teamId, 'svc_...', {
  minInstances: 2,
  maxInstances: 5,
  scaleCpuThreshold: 70,
  scaleMemoryThreshold: 85,
  scaleRequestsPerSecThreshold: 200, // null turns request-rate scaling off
});

Autoscale my "web" service between 2 and 5 instances,
and scale up when it passes 200 requests per second.

hoststack services scale takes min:max, or a single number for a fixed count. The CLI has no flag for the request-rate threshold; set that in the dashboard, the SDK or through MCP.

Settings

minInstances

0–50

Dashboard: Min Instances (1–50). The autoscaler never goes below it, and HostStack brings the service up to it after each deploy.

Default: 1

maxInstances

1–50

Dashboard: Max Instances. More than 1 turns autoscaling on. The autoscaler never goes above it.

Default: 1

scaleCpuThreshold

percent, 10–100

Dashboard: CPU Threshold (%). See the warning below about sizes with less than one vCPU.

Default: 80

scaleMemoryThreshold

percent, 10–100

Dashboard: Memory Threshold (%). Memory in use as a share of the instance's limit, not counting reclaimable file cache — the same figure docker stats shows.

Default: 80

scaleRequestsPerSecThreshold

1–10000 | null

Dashboard: Requests/sec Threshold, where 0 turns it off. Requests per second across all of the service's instances, counted at HostStack's edge. Workers and private services receive no edge traffic, so this signal never fires for them.

Default: null (off)

When it scales

Direction	Condition	Sustained for
Up	Any signal is above its threshold: CPU, memory, or (when set) requests per second.	4 readings in a row — about 2 minutes
Down	Every signal is below half its threshold: CPU and memory, and requests per second when set.	10 readings in a row — about 5 minutes

A reading in between — above half a threshold but not above it — resets both counts, and so does a reading on the opposite side. A short burst therefore never adds up to a scale event. Each event moves the count by one instance, so going from 2 to 5 under sustained load takes at least three rounds of four readings.

Seeing what it did

Every scale event is recorded in the activity log as service.scale_up or service.scale_down, with the new instance count and the readings that triggered it — for example CPU: 85.2%, Memory: 40.1%. The service page shows the current count live.

Cost

Each instance costs the service size's monthly price, so a service at three instances costs three times as much while it runs at three. Changes in instance count are picked up by billing within the hour and prorated. Your maximum sets the most a service can cost — see Billing.

A team that hasn't paid an invoice yet has a spending cap, and a maximum that would take a service past it is refused when you save.

Before you scale out

Keep state out of the instance. Requests are spread across instances, so sessions, uploads and caches that live in one instance's memory or /tmp are missing on the others. Put them in a database, Redis or object storage.
Services with a volume. A volume can't be shared safely by two instances. HostStack won't add instances to reach a minimum on a service with a volume attached, but it does not stop the autoscaler if you set a maximum above 1 — that is your call. See Persistent volumes.
Steady load? Set the minimum and maximum to the same number for a fixed instance count and a fixed bill.

Next steps

Was this page helpful?