Configuration & scaling
These are the deploy-time knobs on a Cloud Run function: how much memory (and therefore CPU) it gets, how long it may run before timing out, how many requests one instance handles at once (concurrency), and how it scales between a minimum and maximum instance count. Every deploy also creates a new revision, which is what lets you split traffic or roll back.
Runtime configuration
| Setting | What it controls | Flag |
|---|---|---|
| Memory | Amount of memory allocated to the function during deployment. The memory you choose corresponds to an amount of allocated CPU. | --memory |
| Function timeout | How long the function may run before it is killed. Set it slightly higher than the function's expected execution time so it does not time out. | --timeout |
| Concurrency | How many concurrent requests one instance handles. By default an instance handles one request at a time. | (via Cloud Run service) |
Enabling concurrency lets an already-warm instance serve additional requests (reducing cold starts and latency), but Cloud Run functions provides no isolation between concurrent requests on the same instance. Your code must be safe to execute concurrently. Set the concurrency value - the maximum concurrent requests per instance - through the function's underlying Cloud Run service.
Scaling
Cloud Run functions scale by creating new instances based on the volume of incoming requests. Each function scales independently, with its own configuration set at deploy time.
| Set | Why | Flag |
|---|---|---|
| Minimum instances | Keep instances warm to avoid cold starts and reduce application latency. | --min-instances |
| Maximum instances | Cap requests to throughput-constrained downstream resources (for example, a database). | --max-instances |
To absorb a traffic spike, more than the maximum instances may be created for a short period. Limits are also set per revision independently, so right after a deploy the limit can be temporarily exceeded: existing requests finish uninterrupted on the previous revision's instances while new requests go to the new revision's instances.
Revisions & traffic splitting
Each deploy automatically creates a new revision of the function and its underlying Cloud Run service. Revisions are immutable - to change a function you must redeploy it, which creates another revision.
By default all traffic routes to the latest revision. Set a custom traffic configuration to split traffic between revisions or roll back to a prior one.