Container scaling — how drain mode works and when containers spin up/down

Understand the autoscaling thresholds, what drain mode does, and how the system gracefully removes containers without dropping user requests.

Scale-up trigger: the 70% CPU threshold

The autoscaler monitors CPU utilisation across all running app containers every 15 seconds. If the average CPU usage across all containers exceeds 70% for two consecutive checks (30 seconds), the autoscaler spins up a new app container. The new container is started, waits for its health check to pass, and is then added to Nginx's upstream pool.

Scale-down trigger: the 40% CPU threshold

If average CPU usage drops below 40% across all containers for five consecutive checks (75 seconds), the autoscaler selects one container to remove. The container with the lowest current active request count is chosen first. A minimum of two containers always remains running regardless of CPU — the system never scales below two.

What drain mode is

Before removing a container, the autoscaler puts it into drain mode. In drain mode:

• Nginx stops routing new requests to the container
• Existing in-flight requests are allowed to complete
• The container continues running and processing its current workload

Drain mode ensures no user request is abruptly terminated when a container is shut down.

How drain mode knows when it is safe to shut down

The draining container exposes an active request counter at /api/health which includes the current in-flight request count. The autoscaler polls this endpoint every 5 seconds. When the count reaches zero (meaning all requests have completed), the autoscaler sends a SIGTERM to the container. The container performs a graceful shutdown and exits.

Viewing scale events in the Admin panel

All scale-up and scale-down events are recorded and visible in Admin > Containers under the "Events" tab. Each event shows the timestamp, which container was added or removed, and the CPU usage that triggered the event. This log is useful for capacity planning and for diagnosing unexpected scaling behaviour.