Scalingo Container Autoscaling: Paying for Peak Traffic Only During the Peak

Your app idles at two containers for twenty-three hours a day, then a newsletter goes out and response times triple. The classic fix is to provision for the worst case and eat the cost. Scalingo's container autoscaling offers a different trade: let the platform add and remove web containers for you, and pay for the extra capacity only while you actually need it.

The thesis of this post is simple: autoscaling on Scalingo is a genuinely useful cost/latency lever for stateless web workloads, but it only works if you understand what it scales (containers), what it doesn't (your database), and what it can't fix (your code).

What the autoscaler actually does

Scalingo runs your application as containers, grouped by process type — typically a web type that serves HTTP traffic. Autoscaling is configured per container type. You set a minimum and maximum container count, a container size, and a target for a performance metric (commonly CPU usage or requests per minute per container). The platform then watches that metric and adjusts the container count to keep it near the target, staying within your bounds.

Two properties matter here. First, scaling is horizontal: it changes how many containers run, not how big they are. Second, it requires no redeploy — containers are added or removed while the app keeps serving traffic. Because Scalingo bills per container per minute, a container that exists for eleven minutes of a traffic spike costs eleven minutes, not a month of overprovisioning.

A worked example: the newsletter spike

Imagine a marketing site and API on a single web process. Baseline traffic fits comfortably on two M-size containers, but campaigns cause short bursts of 5–10x traffic.

A reasonable starting configuration:

• Container type: web, size M
• Minimum: 2 containers (baseline plus redundancy)
• Maximum: 10 containers (a hard cost ceiling)
• Target: roughly 70% CPU per container

You can set this from the Scalingo dashboard under your app's container configuration, or via the CLI/API. To check the current state from your machine (with the Scalingo CLI installed and authenticated):

scalingo --app my-app autoscale

This reads configuration only, so it's safe to run anytime. When the newsletter lands, per-container CPU climbs past the target. The autoscaler adds containers — say from 2 up to 7 — spreading requests across more workers and keeping latency acceptable. After the campaign traffic decays, CPU drops and the count drifts back toward the minimum. Your bill reflects a few hours of extra containers instead of a permanent fleet of ten.

The maximum bound deserves emphasis: it is your budget guardrail. Set it to a number you can afford to run continuously, because a misconfigured target or a retry storm can pin you at the ceiling.

Verifying it behaves as expected

Don't enable autoscaling on production and hope. Create a test app, apply the configuration, and confirm it persisted with the CLI command above or the dashboard. Then generate synthetic load with a tool like hey or k6 against a non-production endpoint:

hey -z 5m -c 50 https://my-test-app.osc-fr1.scalingo.io/

Watch the metrics view in the dashboard. You should see per-container CPU rise, then the container count increase, then — after you stop the load — a scale-down. Note that scaling is not instantaneous: platforms typically apply cooldown or stabilization windows so the count doesn't flap up and down with every minor blip. The exact metrics offered, default thresholds, and cooldown behavior are platform- and version-dependent, so check Scalingo's current documentation and changelog rather than trusting any specific numbers — including the ones in this post, which are illustrative starting points, not universal facts.

The trade-offs you can't configure away

Only the stateless tier scales. Autoscaling adjusts web containers. Your PostgreSQL or MySQL addon does not autoscale. Ten web containers hammering a database sized for two is a classic self-inflicted outage: the spike you scaled to absorb just moves the bottleneck to connection limits, lock contention, or slow queries. Before raising your maximum container count, check what that concurrency does to your database connection pool and capacity.

It can't fix application bugs. A memory leak, an N+1 query, or an unbounded background queue will consume any number of containers you throw at it — you'll just pay more while the app still degrades. Autoscaling absorbs demand variability; it does not absorb inefficiency.

Your app must be horizontally safe. Anything stored in local memory or on the local filesystem — sessions, caches, uploaded files — breaks or behaves inconsistently when the container count changes. Use an external session store and object storage before you scale out.

Closing: a decision rule

Enable autoscaling when your traffic is spiky and your web tier is stateless, with a maximum count your budget and your database can both survive. Then verify it under synthetic load before the real spike arrives. If your monitoring shows the database, not the web tier, saturating first during peaks, spend your effort there instead — more web containers would only make it worse.