Cloud Run functions overview

This guide provides an introductory overview of how other Google Cloud services are involved in the Cloud Run functions deployment process.

Before you begin

Familiarize yourself with Cloud Run functions and source deployment concepts from the Cloud Run deployment options and resource model guide.

Architecture overview

When you deploy your function's source code to Cloud Run functions, that source code is stored in a Cloud Storage bucket. Cloud Build then automatically builds your code into a container image and pushes that image to an Artifact Registry image registry. Cloud Run functions accesses this image when it needs to run the container to execute your function.

In the following diagram, the Cloud Run functions box represents a function that is deployed in Cloud Run, using either the Cloud Run Admin API or the Cloud Functions API. Typically, newer functions are deployed using the Cloud Run Admin API, and older functions are deployed using the Cloud Functions API.

Depending on which API is used when deploying a function, the following occurs:

• If you deployed your function using use the Cloud Run Admin API, the following occurs:

  1. Your source code is uploaded to a Cloud Storage bucket that has no retention period.

     1. If you're using default encryption, the name of the bucket is autogenerated and named run-sources-PROJECT_ID-REGION.
     2. If you're protecting your data with Customer-managed encryption keys (CMEK), the bucket name is not autogenerated, and you must provide a bucket name.

  2. The source code is submitted to Cloud Build, where Google Cloud's buildpacks and the Functions Framework create a container image. Note that the Cloud Build service account builds the container image. Cloud Run defaults to using the e2-standard-2 machine type provided by Cloud Build.

  3. Your container image is then uploaded to Artifact Registry through an auto-created bucket called REGION-docker.pkg.dev/PROJECT_ID/cloud-run-source-deploy.

  4. The image is deployed to Cloud Run as a service.

  5. You can trigger or invoke the function with Eventarc, Pub/Sub, or other HTTP triggers.

• If you deployed your function using use the Cloud Functions API (v2), the following occurs:

  1. Your source code is uploaded to a Cloud Storage bucket that has no retention period.

     The name of the bucket is autogenerated and follows this format:

     1. If you're using default encryption, this bucket is named gcf-v2-sources-PROJECT_NUMBER-REGION.
     2. If you're protecting your data with CMEK, the bucket is named gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH.

  2. The source code is submitted to Cloud Build, where Google Cloud's buildpacks and the Functions Framework create a container image. Note that the Cloud Build service account builds the container image. Cloud Run defaults to using the e2-standard-2 machine type provided by Cloud Build.

  3. Your container image is then uploaded to Artifact Registry through an auto-created bucket called REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts.

  4. The image is deployed to Cloud Run as a service.

  5. You can trigger or invoke the function with Eventarc, Pub/Sub, or other HTTP triggers.

What's next

• Learn about the different types of functions and your options for triggering functions.
• If you previously created functions with the Cloud Functions API, see the Cloud Run functions comparison guide to learn about the differences between the two versions of Cloud Run functions.