Google Cloud Run

Pathrule2 Rules • 2 Memories • 1 Skill

Cloud Run runs stateless containers behind managed request routing, but each instance may handle concurrent requests, scale to zero, start from a fresh filesystem, and terminate after a bounded lifecycle while revisions can split traffic. This pattern constrains request-scoped state and background work while recording concurrency, scaling, identity, and revision ownership decisions and providing a rollout verification procedure. It differs from Lambda and Vercel by focusing on container revisions, per-instance concurrency, request-bound CPU and lifecycle, service identity, and managed traffic splitting.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

verify-cloud-run-revision

src/

Keep request state local and shared clients concurrency-safe

Finish required work before the request ends or move it to a durable job

infra/

cloud-run/

Concurrency and instance count form one dependency budget

A revision is immutable configuration plus image

Rules

Keep request state local and shared clients concurrency-safe/srchighstrictAssume several requests can execute in one container and make every mutable global cache bounded, keyed, and safe for concurrent use.

1	A container instance can serve more than one request at a time. Module globals and singleton objects therefore persist across users and can be read or mutated concurrently.
2
3	- Store actor, tenant, locale, payload, and transaction state in request-local values or explicit context.
4	- Reuse network clients only when their libraries support concurrent use and their connection pools fit maximum instance concurrency.
5	- Do not cache authorization decisions or user data globally without identity keys, expiry, invalidation, and memory bounds.
6	- Load-test the configured concurrency with realistic CPU, memory, database, and outbound-call behavior before increasing it.
7
8	See /infra/cloud-run for the adjacent decision or procedure that completes this constraint.

Finish required work before the request ends or move it to a durable job/srchighstrictDo not rely on detached background tasks after returning a response; enqueue durable work or use a Cloud Run job for bounded batch execution.

1	The platform owns instance lifetime and request-linked resource allocation. Work started after the response can be paused or terminated without completion evidence.
2
3	- Await work required for the response and honor request cancellation and deadline through downstream calls.
4	- For asynchronous effects, write a durable command or outbox before returning and process it through a retryable service or queue.
5	- Use Cloud Run jobs for finite batch work with explicit input, idempotency, completion, and retry semantics rather than inventing a never-ending HTTP process.
6	- Keep temporary files within instance limits and copy durable results to an external store before reporting success.
7
8	See /ops/runbooks for the adjacent decision or procedure that completes this constraint.

Memories

Concurrency and instance count form one dependency budget/infra/cloud-runChoose per-instance concurrency, minimum and maximum instances, and client pools together from measured service and downstream capacity.

1	A service configured for many concurrent requests per instance may use fewer containers but more simultaneous database or API operations in each process. Maximum instances multiplies that demand.
2
3	- Measure CPU, memory, latency, connection use, and blocking behavior across increasing per-instance concurrency.
4	- Multiply the chosen concurrency and client pool limits by maximum instances and deployment overlap against downstream capacity.
5	- Use minimum instances only for justified latency or availability goals and include their steady cost in the service decision.
6	- Cap maximum instances where databases, third-party APIs, subnet connectors, or quotas are the binding constraint and apply application backpressure too.
7
8	See /src for the rule or workflow that puts this decision into practice.

A revision is immutable configuration plus image/infra/cloud-runDeploy image digest, command, resources, concurrency, timeout, identity, network, secrets, and environment as one reviewable revision.

1	Changing configuration creates behavior as surely as changing code. Mutable image tags or console edits make rollback and traffic comparison unreliable.
2
3	- Reference an immutable image and preserve source revision, build provenance, and schema compatibility with the release.
4	- Version CPU, memory, concurrency, timeout, execution environment, service account, ingress, egress, environment, and secret references in infrastructure code.
5	- Grant the runtime service account only application permissions and keep deployer permissions outside the container.
6	- Compare live revision configuration and image identity with the intended release before moving all traffic.
7
8	See /ops/runbooks for the rule or workflow that puts this decision into practice.

Skills

verify-cloud-run-revision/rootTest a Cloud Run revision under concurrency, cold start, termination, dependency failure, traffic split, and rollback.

1	---
2	name: verify-cloud-run-revision
3	description: Deploy or revise a Google Cloud Run service safely.
4	---
5
6	# Verify Cloud Run Revision
7
8	Run this procedure when the affected surface changes, before the result is promoted to production. Record evidence for every step instead of accepting a plausible-looking result.
9
10	1. Resolve the immutable image and effective revision configuration, including identity, ingress, egress, secrets, resources, concurrency, timeout, and scaling.
11	2. Send a small traffic share and verify cold start, readiness, authentication, required network access, denied permissions, and structured logs.
12	3. Load the revision to configured concurrency while watching latency, CPU, memory, instances, database pools, outbound limits, and request cancellations.
13	4. Terminate instances and fail dependencies during requests and queued work; confirm required effects are durable and temporary filesystem loss is harmless.
14	5. Increase traffic only while acceptance signals hold, and route back to the prior revision immediately if errors, latency, or capacity regress.
15
16	## Exit criteria
17
18	The change is complete only when the expected behavior, failure behavior, and rollback path have all been exercised with representative data. Preserve the evidence with the change so the next operator can repeat the same checks.

Why this pattern

AI agents often keep mutable request state globally, start work after returning a response, rely on the writable filesystem for durability, or scale instances beyond database capacity.

Built for Platform teams operating containerized HTTP services and jobs on Google Cloud Run.

Keeps your assistant from:

Leaking one request's state into another concurrent request
Losing background work after the response completes
Treating ephemeral filesystem data as durable
Overwhelming dependencies as instances and concurrency multiply

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25