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

Before you begin

Familiarize yourself with Cloud Run functions and source deploymentconcepts from theCloud Run deployment options and resource modelguide.

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 thenautomatically builds your code into a container image and pushes that image toan Artifact Registryimage registry.Cloud Run functions accesses this image when it needs to run thecontainer to execute your function.

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

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

• If you deployed your function using use theCloud Run Admin API, thefollowing occurs:

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

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

  2. The source code is submitted to Cloud Build, whereGoogle Cloud's buildpacks and the Functions Framework create a containerimage. Note that the Cloud Build service account builds the containerimage. Cloud Run defaults to using thee2-standard-2 machine typeprovided by Cloud Build.

  3. Your container image is then uploaded to Artifact Registry through an auto-createdbucket calledREGION-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 theCloud Functions API (v2), thefollowing occurs:

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

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

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

  2. The source code is submitted to Cloud Build, whereGoogle Cloud's buildpacks and the Functions Framework create a containerimage. Note that the Cloud Build service account builds the containerimage. Cloud Run defaults to using thee2-standard-2 machine typeprovided by Cloud Build.

  3. Your container image is then uploaded to Artifact Registry through an auto-createdbucket calledREGION-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 thedifferent types of functions andyour options fortriggering functions.
• If you previously created functions with the Cloud Functions API, see theCloud Run functions comparison guideto learn about the differences between the two versions ofCloud Run functions.