---
cuppy_hub: gcp
cuppy_path: reference/compute/cloud-functions.md
cuppy_section: docs
cuppy_doc: H31B-ZPXB
cuppy_doc_uuid: 1d8ab099-f9fb-41fb-a578-0d76ed89a76f
cuppy_permalink: https://cuppy.io/gcp/d/H31B-ZPXB
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/compute/cloud-functions
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 0a6682dde3c4fd5ed9a120dbab6a7bcd282ecf031206b566fd1b64660f6762dd
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Cloud Run functions, and the 1st gen

## 1. The names, which changed

| Now called | Formerly |
|---|---|
| **Cloud Run functions** | Cloud 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 functions | 1st 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 timeout** | up to **60 minutes** (HTTP); up to **9 minutes** (event-driven) | up to **9 minutes** |
| **function types** | HTTP and CloudEvents, **all runtimes** | HTTP 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.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->