Deploy worker pools to Cloud Run

Preview — Cloud Run worker pools

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

This page shows how to deploy container images to a new Cloud Runworker pool or to a new revision of an existing Cloud Run worker pool.

Worker pools are a Cloud Run resource specifically designed forperforming continuous background work.In contrast to Cloud Run services, worker pools do not have a loadbalanced endpoint/URL and do not support autoscaling.

For an example walkthrough of deploying a new worker pool, seeDeploy a sample worker pool quickstart.

Required roles

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

  • Cloud Run Developer (roles/run.developer) on the Cloud Run worker pool
  • Service Account User (roles/iam.serviceAccountUser) on the identity that your worker pools uses to interact with other Google Cloud services
  • Artifact Registry Reader (roles/artifactregistry.reader) on the Artifact Registry repository of the deployed container image

For a list of IAM roles and permissions that are associated withCloud Run, seeCloud Run IAM rolesandCloud Run IAM permissions.If your Cloud Run worker pool interfaces withGoogle Cloud APIs, such as Cloud Client Libraries, see theservice identity configuration guide.For more information about granting roles, seedeployment permissionsandmanage access.

Supported container registries and images

You can directly use container images stored inArtifact Registry,orDocker Hub.Google recommends the use of Artifact Registry.Docker Hub images arecachedfor up to one hour.

You can use container images from other public or private registries (like JFrogArtifactory, Nexus, or GitHub Container Registry), by setting up anArtifact Registry remote repository.

You should only considerDocker Hub for deploying popular container images such asDocker Official Images orDocker Sponsored OSS images.For higher availability, Google recommends deploying these Docker Hub images using anArtifact Registry remote repository.

Cloud Run does not support container image layers larger than9.9 GBwhen deploying from Docker Hub or an Artifact Registry remote repository with anexternal registry.

Deploy worker pools

You can deploy worker pools in the following ways:

Deploy a new worker pool

You can specify a container image with a tag(for example,us-docker.pkg.dev/my-project/container/my-image:latest) or with an exact digest(for example,us-docker.pkg.dev/my-project/container/my-image@sha256:41f34ab970ee...).

Deploying a worker pool for the first time creates its first revision. Note thatrevisions are immutable. If you deploy from a container image tag, it will beresolved to a digest and the revision will always serve this particular digest.

Follow the instructions, using the Google Cloud console, the Google Cloud CLI,Terraform or REST API:

Console

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

    Go to Cloud Run

  2. SelectWorker pools from the menu, and clickDeploy container todisplay theCreate worker pool form.

    1. In the form, specify the container image.

    2. Enter the worker pool name. Worker pool names must be 49 charactersor less and must be unique per region and project. You can't share thesame name as anexisting service name from your project. Aworker pool name cannot be changed later and is publicly visible.

    3. Select theregion where you want your worker located.The region selector indicatesprice tier and highlightsregions with thelowest carbon impact.

    4. UnderScaling, specify the number of instances for the worker pool.

  3. ClickContainer(s), Volumes, Networking, Security to set other optional settings in theappropriate tabs:

  4. When you are finished configuring your worker pool, clickCreate todeploy the image to Cloud Run and wait for the deployment to finish.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, aCloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To deploy a worker pool container image:

    1. Run the following command:

      gcloud beta run worker-pools deployWORKER_POOL --imageIMAGE_URL

      Replace the following:

      • WORKER_POOL: the name of the worker pool you want todeploy to. If the worker pool does not exist yet, this command creates theworker pool during the deployment. You can omit this parameter entirely,but you will be prompted for the worker pool name if you omit it. Worker pool names must be 49 characters or fewer, use a unique name per region and project, and must not share the same name as anexisting service name from your project.
      • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest. Note that if you don't supply the--imageflag, the deploy command attempts todeploy from source code.
    2. Wait for the deployment to finish. Upon successful completion,Cloud Run displays a success message along with the revision information about the deployed worker pool.

      To deploy to a different location from the one you set using therun/regiongcloud properties, use:

      gcloud beta run worker-pools deployWORKER_POOL --regionREGION

Terraform

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

resource"google_cloud_run_v2_worker_pool""default"{name="WORKER_POOL"location="REGION"launch_stage="BETA"template{containers{image="IMAGE_URL"}}}

Replace the following:

  • WORKER_POOL: the name of the worker pool.
  • REGION: the Google Cloud region—for example,europe-west1.
  • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.

REST API

To deploy a new worker pool, send aPOST HTTP request tothe Cloud Run Admin API worker poolscreate endpoint.

For example, usingcurl:

curl-H"Content-Type: application/json"\-H"Authorization: BearerACCESS_TOKEN"\-XPOST\-d'{"launchStage":"BETA",template: {containers: [{image: "IMAGE_URL"}]}}'\https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/workerPools?workerPoolId=WORKER_POOL

Replace the following:

  • ACCESS_TOKEN: a valid access token for an account thathas theIAM permissions to deploy services.For example, if you are logged into gcloud, you can retrieve anaccess token usinggcloud auth print-access-token.From within a Cloud Run container instance, you can retrievean access token using thecontainer instance metadata server.
  • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • REGION: the Google Cloud region—for example,europe-west1.
  • PROJECT_ID: the Google Cloud project ID.
    • WORKER_POOL: the name of the worker pool.

Cloud Run locations

Cloud Run is regional, which means the infrastructure thatruns your Cloud Run services is located in a specific region and ismanaged by Google to be redundantly available acrossall the zones within that region.

Meeting your latency, availability, or durability requirements are primaryfactors for selecting the region where your Cloud Run services are run.You can generally select the region nearest to your users but you should considerthe location of theother Google Cloudproducts that are used by your Cloud Run service.Using Google Cloud products together across multiple locations can affectyour service's latency as well as cost.

Cloud Run is available in the following regions:

Subject toTier 1 pricing

  • asia-east1 (Taiwan)
  • asia-northeast1 (Tokyo)
  • asia-northeast2 (Osaka)
  • asia-south1 (Mumbai, India)
  • asia-southeast3 (Bangkok)
  • europe-north1 (Finland)leaf iconLow CO2
  • europe-north2 (Stockholm)leaf iconLow CO2
  • europe-southwest1 (Madrid)leaf iconLow CO2
  • europe-west1 (Belgium)leaf iconLow CO2
  • europe-west4 (Netherlands)leaf iconLow CO2
  • europe-west8 (Milan)
  • europe-west9 (Paris)leaf iconLow CO2
  • me-west1 (Tel Aviv)
  • northamerica-south1 (Mexico)
  • us-central1 (Iowa)leaf iconLow CO2
  • us-east1 (South Carolina)
  • us-east4 (Northern Virginia)
  • us-east5 (Columbus)
  • us-south1 (Dallas)leaf iconLow CO2
  • us-west1 (Oregon)leaf iconLow CO2

Subject toTier 2 pricing

  • africa-south1 (Johannesburg)
  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seoul, South Korea)
  • asia-southeast1 (Singapore)
  • asia-southeast2 (Jakarta)
  • asia-south2 (Delhi, India)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Warsaw, Poland)
  • europe-west10 (Berlin)
  • europe-west12 (Turin)
  • europe-west2 (London, UK)leaf iconLow CO2
  • europe-west3 (Frankfurt, Germany)
  • europe-west6 (Zurich, Switzerland)leaf iconLow CO2
  • me-central1 (Doha)
  • me-central2 (Dammam)
  • northamerica-northeast1 (Montreal)leaf iconLow CO2
  • northamerica-northeast2 (Toronto)leaf iconLow CO2
  • southamerica-east1 (Sao Paulo, Brazil)leaf iconLow CO2
  • southamerica-west1 (Santiago, Chile)leaf iconLow CO2
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

If you already created a Cloud Run service, you can view theregion in the Cloud Run dashboard in theGoogle Cloud console.

Deploy a new revision of an existing worker pool

Note that changing configuration settings for a worker pool results in thecreation of a new revision, even if there is no change to the container image.Each revision created is immutable.

The container image is imported by Cloud Run when deployed.Cloud Run keeps this copy of the container image as long as it is usedby a revision.

Follow these instructions, using Google Cloud console, the Google Cloud CLI, Terraform,or REST API:

Console

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

    Go to Cloud Run

  2. SelectWorker pools from the menu, select the worker pool to update,then clickEdit and deploy new revision to display theDeploy worker pool revision form.

    1. If needed, specify the URL to the new container image to be deployed.

    2. Configure the containeras needed.

    3. If needed, update the number of instances for the worker pool.

  3. If needed, clickContainer(s), Volumes, Networking, Security to set other optional settings in theappropriate tabs:

  4. When you finish updating your worker pool, clickDeploy.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, aCloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To deploy a container image:

    1. Run the command:

      gcloud beta run worker-pools deployWORKER_POOL --imageIMAGE_URL

      Replace the following:

      • WORKER_POOL: the name of the worker pool you want todeploy to. If the worker pool does not exist yet, this command creates theworker pool during the deployment. You can omit this parameter entirely,but you will be prompted for the worker pool name if you omit it. Worker pool names must be 49 characters or fewer, use a unique name per region and project, and must not share the same name as anexisting service name from your project.
      • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest. Note that if you don't supply the--imageflag, the deploy command attempts todeploy from source code.

      The revision suffix is assigned automatically for new revisions. If youwant to supply your own revision suffix, use the gcloud CLIparameter--revision-suffix.

    2. Wait for the deployment to finish. Upon successful completion,Cloud Run displays a success message along with the revision information about the deployed worker pool.

YAML

  1. Download the worker poolYAML configuration:

    gcloudbetarunworker-poolsdescribeWORKER_POOL--formatexport>workerpool.yaml
  2. Make a change to the configuration file.

  3. Update the worker pool using the following command:

    gcloudbetarunworker-poolsreplaceworkerpool.yaml

Terraform

Make sure you have set up Terraform as described in theDeploying a new worker pool example.

  1. Make a change to the configuration file.

  2. Apply the Terraform configuration:

    terraform apply

    Confirm you want to apply the actions described by enteringyes.

REST API

To deploy a new worker pool, send aPATCH HTTP request tothe Cloud Run Admin APIworker pools endpoint.

To create a new revision from the template even if the system doesn'tdetect any changes from the previously deployed revision, set the queryparameterforceNewRevision totrue.

For example, usingcurl:

curl-H"Content-Type: application/json"\-H"Authorization: BearerACCESS_TOKEN"\-XPATCH\-d'{"launchStage":"BETA",template: {containers: [{image: "IMAGE_URL"}]}}'\https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/workerPools/WORKER_POOL>?forceNewRevision=true

Replace the following:

  • ACCESS_TOKEN: a valid access token for an account thathas theIAM permissions to deploy services.For example, if you are logged into gcloud, you can retrieve anaccess token usinggcloud auth print-access-token.From within a Cloud Run container instance, you can retrievean access token using thecontainer instance metadata server.
  • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • REGION: the Google Cloud region—for example,europe-west1.
  • PROJECT_ID: the Google Cloud project ID.
  • WORKER_POOL: the name of the worker pool you are deploying to.

Deploy images from other Google Cloud projects

To deploy images from other Google Cloud projects, you or youradministrator must grant the required IAM roles to the deployer account and the Cloud Run service agent.

For the required roles for the deployer account, seerequired roles.

To grant the Cloud Run service agent the required roles, see thefollowing instructions:

  1. In the Google Cloud console, open the project for yourCloud Run worker pool.

    Go to the IAM page

  2. SelectInclude Google-provided role grants.

  3. Copy the email of the Cloud Runservice agent.It has the suffix@serverless-robot-prod.iam.gserviceaccount.com

  4. Open the project that owns the container registry you want to use.

    Go to the IAM page

  5. ClickAdd to add a new principal.

  6. In theNew principals field, paste in the email of the service accountthat you copied earlier.

  7. In theSelect a role drop-down menu, if you are using Container Registry,select the roleStorage -> Storage Object Viewer. If you are usingArtifact Registry, select the roleArtifact Registry -> Artifact Registry Reader.

  8. Deploy the container image to the project thatcontains your Cloud Run worker pool.

    Note: For stronger security,grant access to only the Cloud Storagebucket or Artifact Registry repository that contains your container images.

Deploying images from other registries

To deploy public or private container images that are not stored in Artifact Registryor Docker Hub,set upan Artifact Registryremote repository.

Artifact Registry remote repositories allow you to:

  • Deploy any public container image, for example, GitHub Container Registry (ghcr.io).
  • Deploy container images from private repositories that require authentication, for example,JFrog Artifactory or Nexus.

If using anArtifact Registry remote repository is not an option, you can temporarily pull and push container images to Artifact Registry by deploying them to Cloud Run usingdocker push. Cloud Run imports the container image during deployment, and afterwards, you candelete the image from Artifact Registry.

Deploy multiple containers (sidecars) to a worker pool

In a Cloud Run deployment with sidecars, there is one main worker poolcontainer and one or moresidecar containers. The sidecars can communicatewith each other and with the worker pool container using a localhost port. Thelocalhost port varies depending on the containers you are using.

You can deploy up to 10 containers per instance including the worker poolcontainer. All containers within an instance share the same network namespaceand can also share files using an in-memory shared volume.

You can require all deployments to use a specific sidecar by creatingcustom organization policies.

Deploy a service with sidecar containers

Follow these instructions, using the Google Cloud CLI, YAML, or Terraform to deploymultiple containers to a Cloud Run worker pool:

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, aCloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. To deploy multiple containers to a worker pool, run the following command:

    gcloudbetarunworker-poolsdeployWORKER_POOL\--containerWORKER_POOL_CONTAINER_NAME\--image='WORKER_POOL_IMAGE'\--containerSIDECAR_CONTAINER_NAME\--image='SIDECAR_IMAGE'

    Replace the following:

    • WORKER_POOL: the name of the worker pool you aredeploying to. If you omit this parameter, you will beprompted for the worker pool name.
    • WORKER_POOL_CONTAINER_NAME: a name for the worker poolcontainer.
    • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.
    • SIDECAR_CONTAINER_NAME: a name for the sidecarcontainer—for examplesidecar.
    • SIDECAR_IMAGE: a reference to the sidecar container image.

    To configure each container in the deploy command, supply eachcontainer's configuration after thecontainer parameters, for example:

    gcloudbetarunworker-poolsdeployWORKER_POOL\--containerCONTAINER_1_NAME\--image='WORKER_POOL_IMAGE'\--set-env-vars=KEY=VALUE\--containerSIDECAR_CONTAINER_NAME\--image='SIDECAR_IMAGE'\--set-env-vars=KEY_N=VALUE_N
    Important: When you use the--container flag, you must specify all non-container-level flags before the container-level flags, otherwise the deploy command fails with an error message to that effect.
  3. Wait for the deployment to finish. Upon successful completion,Cloud Run displays a success message.

YAML

  1. If you are creating a new worker pool, skip this step.If you are updating an existing worker pool, download itsYAML configuration:

    gcloudbetarunworker-poolsdescribeWORKER_POOL--formatexport>workerpool.yaml
  2. The following example contains the YAML configuration:

    apiVersion:run.googleapis.com/v1kind:WorkerPoolmetadata:name:WORKER_POOLannotations:run.googleapis.com/launch-stage:BETAspec:template:spec:containers:-name:CONTAINER_NAMEimage:IMAGE_URLcontainers:-name:SIDECAR_CONTAINER_NAMEimage:SIDECAR_IMAGE_URL

    Replace the following:

    • WORKER_POOL: the name of your Cloud Run worker pool.
    • CONTAINER_NAME: a name for the worker pool container.
    • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest
    • SIDECAR_CONTAINER_NAME: a name for the sidecar container—forexample,sidecar.
    • SIDECAR_CONTAINER_IMAGE: a reference to the sidecar containerimage.
  3. Create or update the worker pool using the following command:

    gcloudbetarunworker-poolsreplaceworkerpool.yaml

Terraform

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

resource"google_cloud_run_v2_worker_pool""default"{name="WORKER_POOL"location="REGION"launch_stage="BETA"template{containers{name="CONTAINER_NAME"image="IMAGE_URL"}containers{name="SIDECAR_CONTAINER_NAME"image="SIDECAR_IMAGE_URL"}}}

Replace the following:

  • WORKER_POOL: the name of the worker pool.
  • REGION: the Google Cloud region—for example,europe-west1.
  • CONTAINER_NAME: the name of the container.
  • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.
  • SIDECAR_CONTAINER_NAME: the name of the sidecar container.
  • SIDECAR_IMAGE_URL: a reference to the sidecar container image.

Notable features available to deployments with sidecars

You can specify thecontainer start up order within a deployment with multiple containers, ifyou have dependencies that require some containers to start up before othercontainers in the deployment.

If you have containers that depend on other containers, you must usehealthchecks in your deployment. When you use healthchecks, Cloud Run follows the container startup order, verifying the health of each container before starting the next container. Without healthchecks, Cloud Run tries to start all containers, even if the containers they depend on are not running yet or failed to start.

Multiple containers within a single instance can access a sharedin-memory volume, which is accessible to each container using mount points that you create.

What's next

After you deploy a new worker pool, you can do the following:

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.