Compare Cloud Run functions

This guide compares the latest and original Google Cloud choices for deployingfunctions. This page helps those who previously created functions with theCloud Functions API and are transitioning to theCloud Run Admin API. This page describes key differences in several areas,such as concepts, configuration, deployment, and triggers and retries.

Comparison

There are two versions of Cloud Run functions:

  • Cloud Run functions, is the latest version of functions,deployed as a service on Cloud Run.They can be created in one of the following ways:

    • Cloud Run Admin API(Recommended): Functions created with this API (for example, by usingGoogle Cloud console,gcloud run, the REST API, or Terraform) can be managedexclusively using the Cloud Run Admin API.
    • Cloud Functions v2 API: Functionscreated with this API (for example, by usinggcloud functions, the RESTAPI, or Terraform) can be managed with the Cloud Run Admin API as well asthe Cloud Functions v2 API. When using this API, you specify thetrigger when deploying your function. Learn how todetach a v2 API function sothat it can be managed exclusively using theCloud Run Admin API.

  • Cloud Run functions (1st gen),formerly known as Cloud Functions (1st gen), is the original version offunctions with limited event triggers, runtimes, and configurability. Learnhow toupgrade your 1st gen functions to Cloud Run.

By deploying functions directly onto Cloud Run, your functionsare automatically built as containers and deployed as a Cloud Runservice.

Concepts

The following table summarizes the conceptual differences for functions.

Cloud Run functionsCloud Run functions (1st gen)
Former product nameCloud Functions (2nd gen)Cloud Functions (1st gen)
Resource modelA function is a Cloud Run service that is deployed from source codeA function is deployed from source code
Types of functions terminology
  • HTTP functions
  • CloudEvents functions, also referred to as event-driven functions, are supported in all language runtimes.
  • HTTP functions
  • Only Ruby, .NET, and PHP runtimes support CloudEvents. For Node.js, Go, Python, and Java, create event-driven functions using Background functions.
Assigned HTTPS URLrun.app

Functions created with the Cloud Functions v2 API also have acloudfunctions.net endpoint.		cloudfunctions.net
Image registryArtifact Registry onlyArtifact Registry or Container Registry (deprecated)
IAM roles for deployment
Internal infrastructureCloud RunGoogle internal
Pricing modelCloud Run pricingCloud Run functions (1st gen) pricing

Configuration

Cloud Run builds functions into containers and deploys them asservices. When you deploy a function to Cloud Run, you havecomplete access and control over the function's behavior. For example, you canenable Direct VPC, configure GPUs, use volume mounts, and more.

The following table summarizes the configuration differences for functions:

Cloud Run functionsCloud Run functions (1st gen)
Request timeout
  • Up to 60 minutes for HTTP-triggered functions
  • Up to 9 minutes for event-driven functions created with the Cloud Functions v2 API
  • Up to 9 minutes
Instance sizeUp to 16 GiB RAM with 4 vCPUUp to 8 GB RAM with 2 vCPU
ConcurrencyUp to 1000 concurrent requests per function instance1 concurrent request per function instance
Traffic splittingSupportedNot supported

Deployment

Since August 2024, you can use Cloud Run to deploy and managefunctions created with the Cloud Functions v2 API. As a result of this change:

  • Function metadata such as runtime ID and build configurations are storedin the Cloud Run service definition.
  • You can safely edit your function using the Cloud Run Admin API.
  • You can rely on the Cloud Run service definition as the source oftruth for your function.

However, note that functions created with the Cloud Run Admin API cannot bemodified with the Cloud Functions API.

The following table summarizes the differences in how you create, deploy, edit,and manage functions:

Cloud Run functionsCloud Run functions (1st gen)
Google Cloud consoleCloud RunCloud Run functions (1st gen)
Cloud SDK
REST API
  • run.googleapis.com (v1 and v2) for functions created with the Cloud Run Admin API or the Cloud Functions API.
Terraform

Triggers and retries

The following table compares triggers and retries for functions:

Cloud Run functionsCloud Run functions (1st gen)
Trigger and invoke a functionFor function created with the Cloud Run Admin API, youspecify triggers as part of deploying the function in the Google Cloud console or after deploying the function when using the gcloud CLI.

For functions created with the Cloud Functions v2 API, you specify triggers as part of function deployment.		You specify triggers as part of function deployment.
Event typesSupport for any event type supported by Eventarc, including 90+ event sources through Cloud Audit Logs.Direct support for events from 7 sources.
RetriesFor functions created with the Cloud Run Admin API, update theretry policy in Eventarc and configuredead-letter topic in Pub/Sub.

For functions created with the Cloud Functions v2 API, you specify retries as part of function deployment with the--retry flag.		You specify retries as part of function deployment with the--retry flag.

Detach your function

Functions created using theCloud Functions v2 API(for example, by usinggcloud functions, the REST API, or Terraform) can bedetached from its existing API environment. After you detach a function, you canonly manage it using theCloud Run Admin API. You mightwant to do this if your workloads need to stay within therun.googleapis.com API boundary forAssured Workloads, or to ensurethat your workloads use theCloud Run SKU.SeeManage functions to learn more.

What's next

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-18 UTC.