Skip to main content

Scaling options

Scaling options control how many containers your environment keeps warm, when it adds more containers, and whether an eligible Connect environment can park at zero containers after it becomes idle.

Quave ONE has two related features in the dashboard Scaling options modal:

  • Autoscaling warm containers: keeps at least one warm container running and adjusts the warm replica count based on CPU and memory utilization.
  • Scale to zero: for eligible Connect/BYOP accounts, parks an idle environment at zero containers and wakes it back to the configured warm scale when traffic arrives.

Prerequisites​

  • Your account must have Autoscaling enabled. Contact support to enable this feature.
  • Autoscaling is available for application environments only. It is not available for database environments or environments with local persistent volumes.
  • Scale to zero is shown only when all of these are true:
    • the account is a Connect/BYOP account;
    • account Autoscaling is enabled;
    • the environment uses ingress traffic and is not a TCP app, Database, Function, or Job.

Direct accounts may use Autoscaling when it is enabled for the account, but Scale to zero is a Connect/BYOP-only option.

How to Configure​

  1. Navigate to your app environment
  2. In the Containers section, click Scaling options
  3. Configure the options available for your account and environment
  4. Apply changes

Autoscaling warm containers​

Autoscaling automatically adjusts the number of warm containers running your application based on CPU and memory utilization. This helps your app handle traffic spikes without manual intervention and scale down during quiet periods.

SettingDefaultDescription
Immediate DesiredCurrent containersThe warm container count to apply immediately when the configuration is deployed.
Min Replicas1Minimum number of warm containers. Autoscaling will never scale below this number.
Max Replicas3Maximum number of warm containers (or current container count if higher).
CPU Target70%Target CPU utilization percentage across containers.
Memory Target(optional)Target memory utilization percentage.
Scale Up Window0sStabilization window before scaling up. Default is immediate.
Scale Down Window300sStabilization window before scaling down (5 minutes by default).
Increment Step1Number of containers to add when scaling up.
Decrement Step1Number of containers to remove when scaling down.

Note: You must configure at least one metric target (CPU or Memory) for Autoscaling to work.

How It Works​

When Autoscaling is enabled:

  1. The system monitors CPU and/or memory utilization across your containers
  2. If utilization exceeds the target percentage, new containers are added (up to Max Replicas)
  3. If utilization drops below the target, containers are removed (down to Min Replicas)
  4. Stabilization windows prevent rapid scaling changes (flapping)

Stabilization Windows​

Stabilization windows add a delay before scaling actions take effect. This prevents the system from rapidly scaling up and down in response to brief spikes.

  • Scale Up Window (default: 0s) -- by default, scale-up is immediate to handle traffic spikes quickly
  • Scale Down Window (default: 300s / 5 minutes) -- a 5-minute delay before scaling down, preventing premature removal of containers after a brief dip in usage

Manual Scaling​

When Autoscaling is enabled, the manual container count controls are disabled. You can still set an immediate desired count through the Autoscaling configuration, but ongoing scaling is managed automatically.

Scale to zero​

Scale to zero is a Connect/BYOP option that can automatically park an eligible idle environment at zero containers. While parked, the environment is not billed for warm container runtime. The configured warm scale is preserved and is used again when the environment wakes.

Scale to zero is separate from Autoscaling:

  • Autoscaling decides the warm range, such as desired 1, minimum 1, maximum 5.
  • Scale to zero adds a cold idle state below that warm range. It does not make 0 a valid warm minimum replica count.

Scale-to-zero settings​

SettingDefaultDescription
Wake on demand after idleOffEnables automatic parking after the idle window and request-triggered wake-up.
Idle window60 minutesThe ingress-idle period before Quave ONE parks the environment. Allowed range: 1 to 10080 minutes (7 days).
Wake timeout hint45 secondsHow long Quave ONE advertises or waits for wake-up before the request should retry. Allowed range: 1 to 120 seconds.
Wake behaviorRetry responseChoose how first traffic behaves while the environment is cold: retry response or blocking wake.

Wake-up behavior modes​

When traffic arrives for a parked environment, Quave ONE triggers a wake-up back to the configured warm scale. The Wake behavior setting has two modes for the first cold request:

  • Retry response is the default and safest mode. Quave ONE returns a branded startup page or JSON response with Retry-After while the app starts. Browser users see a Quave ONE page that retries automatically; API clients should retry after the advertised interval.
  • Blocking wake is optional. Quave ONE waits up to the configured wake timeout and then tries to deliver supported HTTP requests to the internal app service after it becomes ready. This is best for clients that already tolerate a slower first request and need Cloud Run-like behavior.

Blocking wake is best-effort and is intended for regular HTTP requests that can wait while the environment starts. It preserves method, path, query string, cookies, auth/content headers, request body, host, and forwarded client metadata where safe.

For now, Blocking wake has these limits:

  • GET/HEAD requests and small non-streaming request bodies up to 1 MiB are the supported request shapes.
  • First-cold SSE response streaming is supported after a successful blocking wake. Streaming or unbounded request bodies, WebSocket/gRPC upgrades, other connection upgrades, and oversized request bodies are not blocked.
  • Wake failures, pool pause, and wake timeouts also do not keep the request waiting forever.

When one of those limits is hit, Quave ONE falls back to the Retry response startup page or JSON response with Retry-After.

Scale activity logs include scale-to-zero park, wake request, wake completion, and blocking proxy outcomes such as success, timeout, fallback, or failure.

Scale-to-zero decisions keep Prometheus failures fail-closed while still parking environments that simply had no traffic. Quave ONE parks an environment when ingress metrics return numeric samples showing zero requests for the full idle window, and scale-to-zero also treats a successful empty request-rate series as zero traffic. If Prometheus errors, times out, or returns malformed data, the environment is not parked.

Common combinations​

AutoscalingScale to zeroResult
OffOffFixed warm container count.
OnOffWarm containers scale between Min and Max based on CPU or memory.
OffOnThe environment parks after the idle window and wakes to the fixed warm container count.
OnOnThe environment parks after the idle window and wakes to the Autoscaling warm policy.

Best Practices​

  1. Start with defaults -- the default settings work well for most applications. Monitor your app before tuning.
  2. Use scale-down stabilization -- keep the default 5-minute scale-down window to prevent flapping. Increase it if your traffic is very spiky.
  3. Set Max Replicas thoughtfully -- consider your account limits and budget when setting the maximum. Autoscaling can increase costs during sustained traffic.
  4. Monitor after enabling -- use Metrics dashboards to observe how Autoscaling responds to your traffic patterns.
  5. Consider memory targets for memory-intensive apps -- if your app is memory-bound rather than CPU-bound, add a memory target in addition to (or instead of) CPU.
  6. Use Scale to zero for Connect environments that can tolerate cold starts -- it is ideal for development, internal tools, and low-traffic customer environments, but not for latency-sensitive production paths that must always serve the first request immediately.

API and MCP Access​

You can configure scaling options programmatically: