Cloud Run functions and the 1st gen — the renaming, the four capability differences, and which to write today

The product was renamed and re-platformed. What the current names are, that modern functions deploy as a Cloud Run service while 1st gen runs on Google internal infrastructure, and the four differences that decide a design: per-instance concurrency, event sources through Eventarc, request timeout, and function types.

markdownreferencev1H31B-ZPXBstage: designtrust: officialfamily: computeservice: cloud-functionsinterface: anycloud run functionscloud functions 1st gen2nd genconcurrencyEventarccloud audit logsrequest timeoutCloudEventsbackground functionsupgrade to Cloud Run

Created 21 Oct 2026 · Modified 23 Oct 2026 · 1 version

Cloud Run functions, and the 1st gen

1. The names, which changed

Now calledFormerly
Cloud Run functionsCloud Functions 2nd gen
Cloud Run functions (1st gen)Cloud Functions 1st gen

An agent answering from memory will say "Cloud Functions" and "2nd gen". Both are old names. The vendor's own migration pointer is "Learn how to upgrade your 1st gen functions to Cloud Run" — the direction of travel is onto Cloud Run, not onto a newer Functions.

2. The platform difference underneath

Modern functions deploy "as a Cloud Run service". 1st gen runs on "Google internal" infrastructure.

That one line explains most of the rest: a modern function inherits Cloud Run's resource model — immutable revisions, a stable load-balanced URL, Cloud Run's scaling and its configuration surface (reference/compute/cloud-run.md). A 1st gen function inherits none of it.

3. The four differences that decide a design

Cloud Run functions1st gen
concurrency"Up to 1000 concurrent requests per function instance"a single concurrent request per instance
event sources"Support for any event type supported by Eventarc, including 90+ event sources through Cloud Audit Logs"only 7 direct event sources
request timeoutup to 60 minutes (HTTP); up to 9 minutes (event-driven)up to 9 minutes
function typesHTTP and CloudEvents, all runtimesHTTP and Background/CloudEvents, limited runtime support

The concurrency row is the one that changes a bill. One request per instance means instance count tracks request count; up to 1000 per instance means it does not. A 1st gen workload moved across unchanged can need an order of magnitude fewer instances — and conversely, code that was safe because it only ever saw one request at a time is not safe at concurrency 1000. Shared mutable state in a function body is a correctness bug on the modern platform and was invisible on the old one. Check for it before you migrate, not after.

The event-sources row is the one that changes what is possible. Seven direct sources against anything Eventarc supports, including 90-plus sources through Cloud Audit Logs, is the difference between "there is no trigger for that" and "there is". See reference/messaging/eventarc.md.

4. Which to write

Cloud Run functions. There is no reason in the comparison page to start a new 1st gen function, and the documented path for existing ones is an upgrade.

For a design that is already containerised, consider skipping functions altogether and deploying a Cloud Run service: the modern function is one, and the service gives you the full configuration surface.

5. What is not stated here

No memory, instance-count or quota values. Timeouts are given because the page states them as capability maxima, and the concurrency figure because it is stated verbatim as a capability. Everything else adjustable is a live read (reference/overview/quotas-and-limits-model.md).

Next: reference/compute/errors.md, and guides/parity/compute.md for AWS Lambda and Azure Functions — including the concurrency model, which differs on all three.

Read this document as markdown — the same bytes an agent receives.