How to Configure Scale to Zero in App Platformprivate

App Platform’s Scale to Zero feature automatically puts unused web service components to sleep after a configurable period of inactivity and wakes them when they receive external traffic. This helps reduce costs for web services with periods of low or no traffic. Scale to Zero is available for web services only.

To request access, contact Support, your account team, or your Customer Success team.

For information on other scaling options in App Platform, see How to Scale Apps in App Platform.

Pricing

When a component is scaled to zero, it’s billed at 10% of the standard price. The 10% pricing doesn’t apply to databases or other resources, which are billed at the standard rate.

When you deploy a new version of a web service with Scale to Zero enabled, it starts with active replicas rather than immediately scaling to zero. This ensures that the new version is healthy and deploys correctly. If the service doesn’t receive traffic, it scales to zero after the configured inactivity period.

Features

• Automatically scales components to zero replicas after a configurable period of inactivity.
• Automatically scales components up when they receive external traffic.
• Lets you configure the inactivity period between 600 seconds and 86,400 seconds (10 minutes to 24 hours).
• Supports only web services that are reachable through the app’s hostname; internal traffic does not prevent inactivity sleep or trigger wake-up.

Feedback and Support

To give us feedback during the private preview, contact your Customer Success Manager or Solutions Architect.

Private preview releases may not be suitable for production workloads. We recommend avoiding sensitive workloads in preview features.

Your use of DigitalOcean services is governed by our terms of service, which cover eligibility, content, use, payments and billing, and warranties. This document is not a contract and all use of DigitalOcean’s services is subject to the terms of service.

How to Configure Scale to Zero

A component’s usage is determined by external traffic. Only services accessible through the app’s hostname are eligible for Scale to Zero. Internal traffic, such as requests between services using service names defined in the app spec, does not prevent a service from entering inactivity sleep or trigger wake-up.

You can configure inactivity sleep (Scale to Zero) in a service’s app spec as shown in the following example:

name: <your_app>
services:
- name: web
  instance_count: 3
  github:
    repo: digitalocean/sample-nodejs
    branch: master
  inactivity_sleep:
    after_seconds: 1800
  health_check:
    http_path: /healthz
    period_seconds: 10

Replace <your_app> with your app’s name.

The inactivity_sleep section supports the following field:

• after_seconds: The number of seconds of inactivity after which the service scales to zero replicas. Valid values are 600-86,400 seconds (10 minutes to 24 hours). Inactivity is measured from the end of the last request.

When a request hits a service that is asleep, it is scaled up to one of the following:

• The configured instance_count (3 in the example above), or
• If autoscaling is enabled, the min_instance_count defined in the autoscaling configuration.

For more information, see How to Update an App’s Spec and the App Spec Reference.

Health Checks

We recommend configuring an HTTP health check to ensure replicas are ready to handle requests. When a sleeping service wakes up, the system forwards requests as soon as it considers a replica healthy, so accurate health checks are essential for consistent behavior.

When Not to Use Scale to Zero

Do not use Scale to Zero for services that are highly sensitive to latency. Waking a service from inactivity sleep introduces a cold start, which typically takes several seconds and may take longer depending on the application.

Factors that can increase wake-up time include:

• Redeploying the app from the container registry.
• Establishing database connections or other external dependencies during startup.

Consider this additional latency when evaluating your app’s user experience. For guidance on reducing cold-start delays, see How to Optimize for Scale to Zero.

How to Optimize for Scale to Zero

To reduce the latency when a service wakes from inactivity sleep, focus on minimizing startup time and container image size.

Optimize Service Startup Time

When a service wakes up, it starts a new instance. The time required to initialize and begin serving requests directly affects user-perceived latency.

Consider the following optimizations:

• Initialize connections to dependencies lazily, and avoid unnecessary network requests during startup.
• Move one-time tasks, such as database migrations, outside of the service startup process.

Optimize Image Size

Whenever possible, deployments use cached images, but this is not guaranteed. Smaller container images reduce startup time and help minimize wake-up latency. Optimize your image to be as small as possible.

Runtime Logs

When a component is scaled to zero, its runtime logs are no longer available. When the component scales back up, a new instance is created and generates a new set of runtime logs.

To retain access to logs generated before the component scaled down, use log forwarding.

Limitations and Known Issues

• Only services accessible through the app’s hostname (services that receive external traffic) are eligible.
• Internal traffic between services does not prevent a service from entering inactivity sleep or trigger wake-up.
• Scale to Zero is not suitable for services that are highly sensitive to latency, as waking a service can take several seconds.
• The inactivity period (after_seconds) must be between 600 seconds (10 minutes) and 86,400 seconds (24 hours).
• When a component is scaled to zero, its runtime logs are no longer available.