Minimum instances (services)

This page describes how to enable idle instances for your service using the minimum instances settings.

For Cloud Run services, Cloud Run by default scales in to the number of instances based on the number of incoming requests. However, if your service requires reduced latency, especially when scaling from zero active instances, you can change this default behavior by specifying a minimum number of container instances to be kept warm and ready to serve requests. Refer to General development tips for more details on this optimization.

Cloud Run removes instances that are not serving requests (idle). With minimum instances set, Cloud Run keeps at least the number of minimum instances running, even if they're not serving requests. Active instances above min-instances might become idle, if they are not receiving requests.

For example, if min-instances is 10, and the number of active instances is 0, then the number of idle instances is 10. When the number of active instances increases to 6, then the number of idle instances decreases to 4.

Applying minimum instances at service-level versus revision-level

You can configure minimum instances at the service level or at the revision level. Google recommends that you apply minimum instances at the service level and avoid combining service-level and revision-level minimum instances.

If you apply minimum instances at the revision-level, the settings go into effect upon deployment of the revision. If you apply this feature at the service-level, the setting goes into effect without needing to deploy a new revision.

Tagged revisions and service-level minimum instances

Tagged revisions are started, but do not count toward the service-level minimum instances if they are not part of a traffic split.

Billing

Instances kept running using the minimum instances feature do incur billing costs. Because these charges are very predictable, Google recommends purchasing a Committed use discount.

Minimum instances and always-allocated CPU

You can configure CPU to be always-allocated if you need CPU outside of requests.

Minimum instances restarts

Minimum instances can be restarted at any time.

Revisions and minimum instances

When minimum instances are set at the service level, they are distributed to all revisions that are serving traffic proportionally to the traffic split.

When minimum instances are set at the revision level, minimum instances are started whenever the revision is referenced in a traffic split (even at 0%) or has a traffic tag assigned.

Setting and updating service-level minimum instances

By default, container instances have service-level minimum instances turned off, with a setting of 0. You can change this default using the Google Cloud console, the Google Cloud CLI, or a YAML file:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. If you are configuring a new service, click Create Service . If you are configuring an existing service, click the service to display its detail panel, then click the pen icon next to Min instances at the top right of the detail panel.

  3. Locate the Service autoscaling form:

    image

  4. In the field labelled Minimum number of instances, specify the number of container instances to be kept warm, ready to receive requests.

  5. Click Create for a new service or Deploy for an existing service.

Command line

Update service-min-instances for a given service using the following command:

gcloud beta run services update SERVICE --service-min-instances MIN-VALUE

Replace

  • SERVICE with the name of your service and
  • MIN-VALUE with the number of container instances to be kept warm, ready to receive requests. Specify default to clear any minimum instance setting.

Alternatively, you can set service-min-instances during deployment using the command:

gcloud beta run deploy --image IMAGE_URL --service-min-instances MIN-VALUE

Replace

  • IMAGE_URL with a reference to the container image, for example, us-docker.pkg.dev/cloudrun/container/hello:latest. If you use Artifact Registry, the repository REPO_NAME must already be created. The URL has the shape REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
  • MIN-VALUE with the number of container instances to be kept warm, ready to receive requests. Specify default to clear any minimum instance setting.

YAML

You can download and view existing service configurations using the gcloud run services describe --format export command, which yields cleaned results in YAML format. You can then modify the fields described below and upload the modified YAML using the gcloud run services replace command. Make sure you only modify fields as documented.

  1. To view and download the configuration:

    gcloud run services describe SERVICE --format export > service.yaml
  2. Update the run.googleapis.com/minScale attribute:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: SERVICE
      annotations:
        run.googleapis.com/launch-stage: BETA
        run.googleapis.com/minScale: 'MIN_INSTANCE'

    Replace

    • SERVICE with the name of your Cloud Run service
    • MIN-INSTANCE with the number of instances to be kept warm, ready to receive requests.
  3. Replace the service with its new configuration using the following command:

    gcloud beta run services replace service.yaml

Client libraries

To update service-level minimum instances for your service from code:

REST API

To update service-level minimum instances for a given service, send a PATCH HTTP request to the Cloud Run Admin API service endpoint.

For example, using curl:

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X PATCH \
-d '{ "scaling": { "minInstanceCount": MIN-VALUE }}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=scaling.minInstanceCount

Replace:

  • ACCESS_TOKEN with a valid access token for an account that has the IAM permissions to update a service. For example, if you are logged into gcloud, you can retrieve an access token using gcloud auth print-access-token. From within a Cloud Run container instance, you can retrieve an access token using the container instance metadata server.
  • MIN-VALUE with the number of container instances to be kept warm, ready to receive requests.
  • SERVICE with the name of the service.
  • REGION with the Google Cloud region of the service.
  • PROJECT-ID with the Google Cloud project ID.

View service-level minimum instances

To view the current service-level minimum instances settings for your Cloud Run service:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Click the service you are interested in to open the Service details panel.

  3. The current setting is shown at the upper right of the service details panel, next to Min instances.

Command line

  1. Use the following command:

    gcloud run services describe SERVICE
  2. Locate the value for Service-level Min Instances: in the returned configuration.

Setting and updating revision-level minimum instances

Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it.

By default, container instances have min-instances turned off, with a setting of 0. You can change this default using the Google Cloud console, the Google Cloud CLI, or a YAML file when you create a new service or deploy a new revision:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Click Create Service if you are configuring a new service you are deploying to. If you are configuring an existing service, click the service, then click Edit and deploy new revision.

  3. If you are configuring a new service, fill out the initial service settings page as desired, then click Container(s), volumes, networking, security to expand the service configuration page.

  4. Click the Container tab.

    image

    • In the field labelled Minimum number of instances, specify the desired number of container instances to be kept warm, ready to receive requests.
  5. Click Create or Deploy.

Command line

You can update min-instance of a given service by using the following command:

gcloud run services update SERVICE --min-instances MIN-VALUE

Replace

  • SERVICE with the name of your service and
  • MIN-VALUE with the desired number of container instances to be kept warm, ready to receive requests. Specify default to clear any minimum instance setting.

You can also set min-instance during deployment using the command:

gcloud run deploy --image IMAGE_URL --min-instances MIN-VALUE

Replace

  • IMAGE_URL with a reference to the container image, for example, us-docker.pkg.dev/cloudrun/container/hello:latest. If you use Artifact Registry, the repository REPO_NAME must already be created. The URL has the shape REGION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
  • MIN-VALUE with the desired number of container instances to be kept warm, ready to receive requests. Specify default to clear any minimum instance setting.

YAML

You can download and view existing service configurations using the gcloud run services describe --format export command, which yields cleaned results in YAML format. You can then modify the fields described below and upload the modified YAML using the gcloud run services replace command. Make sure you only modify fields as documented.

  1. To view and download the configuration:

    gcloud run services describe SERVICE --format export > service.yaml
  2. Update the autoscaling.knative.dev/minScale: attribute:

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: SERVICE
    spec:
      template:
        metadata:
          annotations:
            autoscaling.knative.dev/minScale: 'MIN-INSTANCE'
          name: REVISION

    Replace

    • SERVICE with the name of your Cloud Run service
    • MIN-INSTANCE with the desired number of instances to be kept warm, ready to receive requests.
    • REVISION with a new revision name or delete it (if present). If you supply a new revision name, it must meet the following criteria:
      • Starts with SERVICE-
      • Contains only lowercase letters, numbers and -
      • Does not end with a -
      • Does not exceed 63 characters
  3. Replace the service with its new configuration using the following command:

    gcloud run services replace service.yaml

Terraform

To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.

The following google_cloud_run_v2_service resource specifies a minimum number of instances of 1 under template.scaling. Replace 1 with your own minimum number of instances.

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-min-instances"
  location = "us-central1"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    scaling {
      # Min instances
      min_instance_count = 1
    }
  }
}

View revision-level minimum instances settings

To view the current revision-level minimum instances settings for your Cloud Run service:

Console

  1. In the Google Cloud console, go to Cloud Run:

    Go to Cloud Run

  2. Click the service you are interested in to open the Service details page.

  3. Click the Revisions tab.

  4. In the details panel at the right, the revision-level minimum instances setting is listed under the Container tab.

Command line

  1. Use the following command:

    gcloud run services describe SERVICE
  2. Locate the revision-level minimum instances setting in the returned configuration.

Using both service-level and revision-level minimum or maximum instances

The following table shows the behavior if you combine service-level minimum instances and revision-level minimum or maximum instances:

Configuration setting Behavior
Both service level minimum instances and revision-level minimum instances are set. The effective value for the revision is the larger of revision-level minimum instances and service-level minimum instances.
Both service level minimum instances and revision-level maximum instances are set. The effective value for the revision is the smaller of revision-level maximum instances and service level minimum instances.

This holds true even if the revision-level maximum instances prevents the service from reaching the number of instances configured for service level minimum instances.

Using service level minimum instances with traffic splitting

If you use traffic splitting, the service-level minimum instances are divided across the revisions based on the proportion of the traffic split. For example, if the service-level minimum instances = 10, a 50/50 traffic split allocates 5 service-level minimum instances to each revision.

The following table shows sample configuration scenarios:

Sample use case Sample configuration Resulting behavior
No revision-level settings Service-level minimum instances: 10
  • Revision A minimum instances: 0
  • Revision B minimum instance: 0
  • Traffic split: 60/40
Revision A receives 6 instances from service-level minimum instances proportional to the traffic split. Revision B receives 4 instances from service-level minimum instances proportional to the traffic split.
Receiving more than the service-level minimum instances due to revision-level minimum instances Service-level minimum instances: 10
  • Revision A minimum instances: 6
  • Revision B minimum instance: 0
  • Traffic split: 50/50
Revision A receives 6 instances from revision-level minimum instances. Revision B receives 5 instances from service-level minimum instances proportional to the traffic split. This exceeds service-level minimum instances and is intended.
Receiving less than service-level minimum instances due to revision-level maximum instances. Service-level minimum instances: 10
  • Revision A minimum instances: 0
  • Revision A maximum instances: 3
  • Revision B minimum instance: 0
  • Traffic split: 50/50
Revision A receives 3 instances from service-level minimum instances driven by the traffic split, but is limited to its revision level maximum instances.
Revision B receives 5 instances from service-level minimum instances proportional to the traffic split. This results in 8 service-level instances, as 2 are lost due to revision-level maximum instances of revision A.
Service-level minimum instances is greater than the number of revisions in the traffic split and there is a fractional amount of instances proportional to the traffic split Service-level minimum instances: 3 Revision A gets 1 minimum instance and revision B gets 2 minimum instances. Instance count for the service is 3.