Select an execution environment for services

All Cloud Run instances are sandboxed, the sandboxing technology and available features differs depending on the selected execution environment.

The first generation execution environment is based on gVisor and features fast cold start times and emulation of most, but not all operating system calls.

The second generation execution environment is a microVM and provides full Linux compatibility rather than system call emulation. This execution environment provides:

• Faster CPU performance
• Faster network performance, especially in the presence of packet loss
• Full Linux compatibility, including support for all system calls, namespaces, and cgroups
• Network file system support

Although the second generation execution environment generally performs faster under sustained load, it has longer cold start times than first generation for some services.

Both execution environments have the same pricing. See the Cloud Run pricing page for details.

Selecting an execution environment for a Cloud Run service

Cloud Run services by default don't have an execution environment specified, which means Cloud Run selects the execution environment based on the features used. If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.

Cloud Run jobs and worker pools only use the second generation execution environment, and this cannot be changed.

How to choose an execution environment

You should use first generation if any of the following apply:

• Your Cloud Run service has bursty traffic, and needs to scale out fast to many instances, or your service is sensitive to cold start times.
• Your Cloud Run service has infrequent traffic that causes frequent scale out from zero.
• You want to use less than 512 MiB of memory. The second generation execution environment requires at least 512 MiB of memory.

You should use second generation if any of the following apply to your Cloud Run service:

• Your service needs to use NFS, which is only supported by second generation.
• Your service has fairly steady traffic and is tolerant of somewhat slower cold starts.
• Your service has CPU-intensive workloads.
• Your service could benefit from faster network performance.
• Your service uses Direct VPC egress to send traffic to a VPC network and requires the best possible network performance.
• Your service needs to use software that has issues running in first generation due to unimplemented system calls.
• Your service needs Linux cgroup functionality.
• Your service makes use of third-party infrastructure for securing containers.

Required roles

To get the permissions that you need to configure and deploy Cloud Run services, ask your administrator to grant you the following IAM roles:

• Cloud Run Developer (roles/run.developer) on the Cloud Run service
• Service Account User (roles/iam.serviceAccountUser) on the service identity

If you are deploying a service or function from source code, you must also have additional roles granted to you on your project and Cloud Build service account.

For a list of IAM roles and permissions that are associated with Cloud Run, see Cloud Run IAM roles and Cloud Run IAM permissions. If your Cloud Run service interfaces with Google Cloud APIs, such as Cloud Client Libraries, see the service identity configuration guide. For more information about granting roles, see deployment permissions and manage access.

Set and update execution environment

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.

The default for Cloud Run services is unspecified, which means that Cloud Run selects a suitable execution environment. Alternatively, you can specify an execution environment. To use second generation, you must specify at least 512 MiB of memory.

You can set the execution environment using the Google Cloud console, the gcloud command line, 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. Select Services from the Cloud Run navigation menu, and click Deploy container to configure a new service. 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, then click Container(s), Volumes, Networking, Security to expand the service configuration page.

4. Click the Container tab.

   

   • Select the desired execution environment using the option buttons. Keep "Default" to let Cloud Run select a suitable execution environment.

5. Click Create or Deploy.

gcloud

You can update the execution environment for a given service by using the following command:

gcloud run services update SERVICE --execution-environment ENVIRONMENT

Replace SERVICE with the name of your service and ENVIRONMENT with the desired execution environment. Specify the value gen1 for first generation or gen2 for second generation.

You can also set the execution environment during deployment using the command:

gcloud run deploy --image IMAGE_URL --execution-environment ENVIRONMENT

Replace the following:

• IMAGE_URL: 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 follows the format of LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .
• ENVIRONMENT: the desired execution environment. Specify the value gen1 for first generation or gen2 for second generation.

YAML

1. If you are creating a new service, skip this step. If you are updating an existing service, download its YAML configuration:

   gcloud run services describe SERVICE --format export > service.yaml

2. set the run.googleapis.com/execution-environment annotation:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: SERVICE
   spec:
     template:
       metadata:
         annotations:
           run.googleapis.com/execution-environment: ENVIRONMENT

   Replace the following:

   • SERVICE: the name of your Cloud Run service.
   • ENVIRONMENT: the selected execution environment. Specify the value gen1 for first generation or gen2 for second generation.

   Remove the run.googleapis.com/execution-environment annotation for the default behavior.

3. Create or update the service 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.

Add the following to a google_cloud_run_v2_service resource in your Terraform configuration:

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-execution-environment"
  location = "REGION"

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    execution_environment = "ENVIRONMENT"
  }
}

Replace the following:

• REGION: the Google Cloud region. For example, europe-west1.
• ENVIRONMENT: EXECUTION_ENVIRONMENT_GEN1 for first generation, or EXECUTION_ENVIRONMENT_GEN2 for second generation.

View Execution environment settings

To view the current Execution environment settings for your Cloud Run service:

Console

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

   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 Execution environment setting is listed under the Container tab.

gcloud

1. Use the following command:

   gcloud run services describe SERVICE

2. Locate the Execution environment setting in the returned configuration.

Graceful shutdowns

When a Cloud Run instance is shutting down, it receives a SIGTERM signal to enable a 10 second graceful shutdown.

Handling SIGTERM signal

We recommend that your container install a SIGTERM handler, especially if you are using request-based billing.

Handling SIGTERM gives your container a chance to perform any necessary cleanup tasks such as flushing logs before exiting. If your container does not catch SIGTERM, it will still be given 10 seconds to perform these tasks; those 10 seconds are billed.

How to check whether your container handles SIGTERM

To determine whether your container has a SIGTERM handler installed:

1. Start Cloud Shell. You can find Activate Cloud Shell in the header of the documentation page you're on. You may need to authorize it and wait for it to provision. Alternatively, start a standalone session.

2. Run the container locally in Cloud Shell:

   docker run IMAGE_URL

   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 follows the format of LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG .

3. Open another tab in Cloud Shell and get a list of the containers running in the current Cloud Shell session:

   docker container ls

   You need to locate the container ID returned from the command.

4. Using the container ID, send your container a SIGTERM signal

   docker kill -s SIGTERM CONTAINER_ID

5. Return to the tab where you invoked docker run to see whether the container has exited (stopped). If the SIGTERM signal caused your container to exit, your container is handling SIGTERM.

How to handle SIGTERM

If your container does not handle SIGTERM, the simplest way to add a SIGTERM handler is to wrap your service with tini. Doing this makes your service run as a subprocess of tini, which takes on the role of the container init process. Refer to the Docker instructions for instructions.

Alternatively, you can change your application to directly handle SIGTERM.

What's next

• To use Filestore with Cloud Run, refer to Using Filestore with Cloud Run.
• To use Cloud Storage FUSE with Cloud Run, refer to Using Cloud Storage FUSE with Cloud Run.