Scaling

A service can run more than one instance. Every instance is an identical copy of your app, and traffic is spread across them automatically — more instances means more concurrent requests handled, and one instance failing doesn’t take the service down.

You’ll find this on your service’s Scaling tab.

Manual scaling

Set minimum instances to the number you want running. That’s it — save, and the change rolls out.

• The minimum can’t go below 1: a service always has at least one instance.
• The maximum is the ceiling autoscaling may grow to. With autoscaling off it just sits there; set it once and forget it.
• Instances are added and removed by a normal deploy, so the change goes live the same way any other deploy does — health-checked, with no downtime.

Autoscaling

Turn on Autoscaling and Helicarrier adjusts the instance count for you, between your minimum and maximum, to hold a target utilisation.

Pick a target for CPU, memory, or both:

• Set a target to a percentage (e.g. 70) to use that signal.
• Set it to 0 to ignore that signal.
• If both are set, whichever calls for more instances wins — your service is under pressure if either resource is.

The rule is the standard one:

instances = current × (actual utilisation ÷ target utilisation)

So four instances averaging 90% CPU against a 70% target scale to six. Once utilisation is back near target, the count holds.

It won’t thrash

Autoscalers that react to every wobble cost you money and stability, so this one is deliberately damped:

• A deadband. Utilisation within 10% of target counts as on target — no change.
• Fast up, slow down. Scaling up can happen within a minute; scaling down waits five, and only removes one instance at a time. A brief dip in traffic won’t tear down capacity a returning spike needs.
• Your bounds are hard. The count is always clamped to your minimum and maximum. It will never exceed the ceiling you set, whatever the load.

Seeing what it did

Every decision is written to your service’s logs with the reason:

[autoscale] Scaled up to 5 instances (memory 82% vs 70% target).

Scaling deploys also appear in Deployments, with the direction in the trigger — autoscale 3→5 — and the instance count on the row, so you can see at a glance when your service grew or shrank.

Working with multiple instances

Once a service runs more than one instance, the tabs that show per-container detail adapt:

• Logs merge every instance into one stream, in time order, with each line tagged by the instance it came from — [i2] request completed. A single-instance service is untagged, as before.
• Shell asks which instance to open, since each one is a separate container with its own filesystem and processes. A single-instance service opens straight into it.
• Metrics report the average per instance, not the total — three instances at a comfortable 30% CPU read as 30%, not 90% — plus an Instances chart showing how the count changed over time.
• Deployments are fleet-wide: one deploy rolls every instance together, and the entry shows how many (×3). Autoscaling deploys name the move in the trigger, e.g. autoscale 3→5.

What it costs

Each instance is billed. Running three instances of a service costs three times that service’s plan, for as long as three instances run. The Scaling tab shows the multiplier before you save, and autoscaling only ever bills for instances that are actually up — when it scales back down, so does the bill.

Set a maximum you’re comfortable paying for. That ceiling is the spend cap.

What can’t be scaled out

Scaling out means running N copies behind a load balancer, which doesn’t apply to every service type — these have no Scaling tab:

• Cron jobs — each run is a one-shot task.
• Functions — already scale to zero and back on demand, driven by traffic.
• Static sites — served straight from our edge, with no container to duplicate.
• Managed databases — copying the container would not copy the data. (Use a larger plan instead.)

Good defaults

• Minimum 2 for anything you don’t want to go down during a deploy or a crash.
• Target 70% CPU is a sensible starting point — high enough to be economical, low enough to leave headroom for a spike while new instances start.
• Maximum should be the most you’re willing to pay for in a bad hour, not the most your app could theoretically use.