Google Cloud Run in 2026: The Complete Guide to Cloud Run Functions
- Gammatek ISPL
- Aug 5
- 5 min read
If you've searched "Google Cloud Run" recently, you've probably noticed the landscape has shifted. What used to be a straightforward choice between Cloud Run and Cloud Functions is now a single, unified platform — and understanding that shift is the key to picking the right serverless option for your next project.
This guide breaks down what Google Cloud Run and Cloud Run functions actually are, what's changed heading into 2026, how pricing works, and how to decide between them.
What Is Google Cloud Run?
Google Cloud Run is Google Cloud's fully managed serverless compute platform. It lets you deploy and run containers on demand without provisioning servers, managing clusters, or worrying about infrastructure scaling. You hand Cloud Run a container image (or your source code, which it builds into one), and it takes care of scaling instances up when traffic arrives and scaling back down to zero when it doesn't.
The core appeal is simple: you pay for what you use, you don't manage VMs or Kubernetes nodes, and your app can scale from zero to a very large number of concurrent requests without manual intervention.
What Are Cloud Run Functions?
Cloud Run functions is Google's Function-as-a-Service (FaaS) offering — small, single-purpose code snippets that run in response to an HTTP request or an event, without you managing any server or container configuration yourself. You write a handler, Google Cloud provisions everything underneath it, and you're billed only for the time your function actually executes, metered down to the nearest 100 milliseconds.
This wasn't always the name. What developers previously knew as Cloud Functions (2nd generation) was folded directly into the Cloud Run product line, giving function-style development the same underlying controls as full Cloud Run services: longer timeouts, configurable concurrency, IAM and Identity-Aware Proxy support, Secret Manager integration, and private networking through VPC. The older Cloud Functions (1st gen) product still exists and is documented separately, but new function-based projects are steered toward Cloud Run functions.
What's New in 2026
A few developments are worth knowing if you're evaluating Cloud Run functions right now:
Cloud Run sandboxes moved into public preview. This gives developers a way to execute untrusted code — including AI-agent-generated code — inside isolated environments within an existing Cloud Run service, without standing up a separate container cluster or a dedicated microVM sandboxing system. It's a direct response to the growing number of applications where an LLM or agent needs to run code it just wrote.
Spend caps entered private preview for Cloud Run and Cloud Run functions (alongside several other Google AI products), letting FinOps and DevOps teams set hard budget ceilings at the project level that pause API traffic once a threshold is hit.
Runtime support keeps expanding. Recent release notes show newer language runtime versions reaching General Availability and Preview status across Node.js, Python, Go, Ruby, and PHP, so it's worth checking the official release notes before you lock in a runtime for a new function.
Broader platform integration. Google's Cloud Next 2026 recap emphasized Cloud Run and Cloud Run functions as building blocks for AI agent workloads, not just traditional web backends — a signal of where the roadmap is heading.
Cloud Run vs. Cloud Run Functions: Which Should You Use?
They're built on the same underlying platform now, so the decision comes down to what you're building rather than which product is "better":
Use Cloud Run Functions When... | Use a Full Cloud Run Service When... |
You have a single-purpose handler triggered by HTTP or an event | You need a full application with multiple routes |
You want Google to build the container for you from source | You need a custom container, runtime, or binary |
Your workload is short, event-driven glue logic | You have longer-running background processes or workers |
You're connecting Google Cloud services together (Eventarc, Pub/Sub, storage triggers) | You're deploying an existing containerized app as-is |
In practice, many teams use both side by side: Cloud Run functions for lightweight triggers and integrations, and full Cloud Run services for the application itself.
How Cloud Run Pricing Works
Both products follow a pay-as-you-go model with no charge while idle, but the mechanics differ slightly:
Cloud Run (services): Billed across CPU (vCPU-seconds), memory (GB-seconds), and request count, rounded to the nearest 100 milliseconds of actual usage. Most accounts get a monthly free allotment of requests, along with a small amount of free outbound data transfer within North America. If you set a minimum number of instances above zero to avoid cold starts, you'll be billed for that idle capacity too.
Cloud Run functions: Priced similarly, based on execution time, invocation count, and provisioned memory/CPU, with outbound network requests billed separately. A free tier applies for experimentation, though a valid billing account is still required. If you deploy from source, remember that the underlying build and image storage (via Cloud Build and Artifact Registry) are billed separately from Cloud Run itself — a detail that catches a lot of new users off guard when their bill doesn't match their Cloud Run usage alone.
A practical cost tip: start with the smallest CPU and memory allocation that meets your latency requirements, and only scale up if profiling shows you need to. Concurrency settings also matter — allowing a single instance to handle multiple simultaneous requests can meaningfully reduce your bill compared to running many single-request instances.
Best Practices for Cloud Run Functions in 2026
Pick the newest stable runtime available for your language — recent GA runtime releases often bring performance and security improvements.
Use Eventarc triggers instead of polling when connecting to other Google Cloud services; it's more efficient and keeps your function truly event-driven.
Set sensible concurrency and minimum instances if your workload is latency-sensitive, but weigh that against the idle-capacity cost.
Isolate untrusted or AI-generated code execution using Cloud Run sandboxes rather than running it directly inside your production function.
Set budget alerts or spend caps where available, especially for projects with unpredictable or AI-agent-driven traffic patterns.
Separate your build costs from your compute costs when estimating spend — Cloud Build and Artifact Registry usage isn't part of the core Cloud Run pricing line.
Frequently Asked Questions
Is Google Cloud Functions the same as Cloud Run functions? Functionally, yes, for anything built on the newer generation. Google folded Cloud Functions (2nd gen) into the Cloud Run platform and renamed it Cloud Run functions, while it still runs on the same event-driven model developers were already used to. The original Cloud Functions (1st gen) product remains available and documented separately.
Does Cloud Run scale to zero? Yes. Both Cloud Run services and Cloud Run functions scale down to zero instances when there's no traffic, and you aren't billed for compute while idle (though minimum-instance configurations and certain storage costs can still apply).
Is Cloud Run good for AI agent workloads? Increasingly, yes. Recent additions like Cloud Run sandboxes are aimed specifically at safely executing AI-agent-generated or untrusted code within the platform, reflecting Google's broader push to position Cloud Run as infrastructure for agentic applications.
What language runtimes does Cloud Run functions support? Node.js, Python, Go, Java, Ruby, and PHP are all supported, with specific version support evolving over time — check Google's official release notes for the current GA and Preview status of each runtime before deploying.
Final Thoughts
Google Cloud Run has evolved from "just a container runtime" into the backbone of Google's serverless strategy — one platform that covers everything from a single event-driven function to a full production application, with newer additions aimed squarely at AI agent workloads. If you're deciding where to build your next serverless project, understanding this unified model — rather than treating Cloud Run and Cloud Functions as separate products — will save you time and help you architect it correctly from day one.
Comments