Product

Scaling

Stackap scales an app by running several copies of it, from one to eight, on the same server behind a load balancer that sends each request to the least busy copy.

What it does

Scaling is a single call that sets the number of copies: PUT /v1/projects/:slug/scale with a number from 1 to 8. New copies start and pass their health check before any traffic reaches them, and a deploy requires every copy to be healthy before it counts as live.

Requests are spread across copies by least-connections, and if one copy fails, the load balancer stops sending to it and carries on with the rest. A copy was killed in a test and no request failed.

The reason this helps is mundane. A Node process uses one core, so one copy of a busy app leaves most of a four-core machine idle. Running more copies puts the idle cores to work.

How it works

Measured on one 4-CPU server serving a real site's pages, with 256 connections and no errors:

At three copies the server's load average peaked at 4.6 on four cores, so that is roughly where one machine tops out for that kind of page. A total cap on copies across all projects, set by the operator, stops one project from using the whole machine.

Early-access scope

• Scaling is for the platform operator only, because it spends capacity every project shares. A tenant cannot change its own count.
• It is horizontal across cores on one machine. Spreading an app over several servers is not built.
• There is no autoscaling. Nothing adds or removes copies in response to load.
• Per-copy state is not shared: an app must keep sessions and caches in the database, not in memory, and Next.js's incremental cache is per server.
• The throughput figures are for static-heavy pages from one test. Your app's numbers depend on its work per request.

Questions

Last updated 2026-10-03.