Next.js on Google Cloud Run
Google Cloud Run publishes its own guide for deploying Next.js.
React framework with file-based routing, server components and a build step that produces both static and server-rendered output.
What Next.js needs.
Every host claims to run Next.js, so the claim on its own decides nothing. These are the things Next.js actually requires from the platform underneath it, and what Google Cloud Run publishes about each. Google Cloud Run documents 3 of the 6.
Max request duration
5 minutes by default, extendable to 60 minutes per request.
Server components and route handlers run per request. The wall-clock ceiling decides whether a slow upstream API or a model response can finish at all.
Sources (1) →Sources ↓
- Configure request timeout for services — Google Cloud Documentation ↗
“The timeout is set by default to 5 minutes (300 seconds) and can be extended up to 60 minutes (3600 seconds).”
Read 2026-09-09 · official docs
Streaming response limit
Not documented
The App Router streams the dynamic parts of a page as they resolve. A host that buffers the whole response first removes the benefit.
Edge network
Limited — deploy per region, add a load balancer
Middleware runs on every matched request before the cache is consulted. Where it executes decides how much latency it adds.
Sources (1) →Sources ↓
- Serve traffic from multiple regions — Cloud Run — Google Cloud Documentation ↗
“Because Cloud Run services deploy into individual regions, you must deploy your service to multiple regions and then configure global load balancing for the service. You can automate cross-regional failover using Cloud Run service health.”
Read 2026-09-09 · official docs
Build allowance
Not documented
A large Next.js app prerenders at build time, so the build allowance is a recurring cost rather than a one-off.
Git deployment
Supported
The Next.js workflow assumes a push builds and ships. A host without git-triggered deploys means wiring CI yourself before the first deploy, which is most of the setup cost.
Sources (1) →Sources ↓
- Continuously deploy from a repository — Cloud Run — Google Cloud Documentation ↗
“If you have source code or functions in a Git repository and want to automate builds and set up continuous deployments from a repository, you can use either Cloud Build or Developer Connect in the Cloud Run console.”
Read 2026-09-09 · official docs
Concurrent builds
Not documented
Next.js builds are slow enough that queueing is felt. One build at a time is workable alone and becomes the bottleneck the moment two people merge in the same hour.
What Google Cloud Run documents.
Google Cloud Run publishes its own guide for deploying Next.js.
Build and deploy a Next.js web app to Cloud Run Learn how to use a single command to build and deploy a "Hello World" web application from a code sample to Google Cloud using Cloud Run. By following the steps in this quickstart, Cloud Run automatically builds a Dockerfile for you when you deploy from source code.
Sources (1) →Sources ↓
- Quickstart: Build and deploy a Next.js web app to Google Cloud with Cloud Run ↗
“Build and deploy a Next.js web app to Cloud Run Learn how to use a single command to build and deploy a "Hello World" web application from a code sample to Google Cloud using Cloud Run. By following the steps in this quickstart, Cloud Run automatically builds a Dockerfile for you when you deploy from source code.”
Read 2026-09-09 · official docs
Next.js features on Google Cloud Run
Capabilities Google Cloud Run documents specifically for Next.js, with the constraint it documents alongside each.
Streaming SSR
Supported
Response streaming Cloud Run supports streaming HTTP responses. No configuration is required to enable the feature. The server has to respond with a Transfer-Encoding: chunked response header.
Sources (1) →Sources ↓
- Invoke with an HTTPS Request | Cloud Run | Google Cloud Documentation ↗
“Response streaming Cloud Run supports streaming HTTP responses. No configuration is required to enable the feature. The server has to respond with a Transfer-Encoding: chunked response header.”
Read 2026-09-13 · official docs
What it costs to run there.
- Entry paid plan
- No plan fee and no minimum commitment. Cloud Run bills per vCPU-second, GiB-second and request once the monthly free allowance is used, so there is no entry price to compare, only a rate card. Recorded without a magnitude for that reason.
- Pricing model
- Metered by resource, billed in 100 ms increments, with no monthly minimum. Two billing settings change what is counted: request-based charges CPU only while a request is being processed, instance-based charges for the whole instance lifecycle. Prices vary by region — the location list is split into Tier 1 and Tier 2 pricing — and the free tier is applied as a spending-based discount at Tier 1 rates.
- Regions
- 43 regions, counted from Cloud Run's own locations list — Google publishes the list rather than a total. 20 are Tier 1 and 23 Tier 2, so the region chosen changes the bill as well as the latency.
Sources (3) →Sources ↓
- Cloud Run pricing | Google Cloud ↗
“With Google Cloud's pay-as-you-go pricing, you only pay for the services you use.”
Read 2026-09-16 · official pricing
- Cloud Run pricing — Google Cloud ↗
“Cloud Run charges you only for the resources you use, rounded up to the nearest 100 millisecond. Your total Cloud Run bill will be the sum of the resource usage in the pricing table after the free tier is applied. [...] Cloud Run pricing depends on the selected region. Pricing for Cloud Run services also depends on the billing configuration. [...] The free tier is applied as a spending based discount using Tier 1 pricing.”
Read 2026-09-09 · official pricing
- Cloud Run locations ↗
“Each Cloud Run resource resides in a region. [...] Customer data associated with the Cloud Run resource is stored in the selected region. [...] Subject to Tier 1 pricing [...] Subject to Tier 2 pricing”
Read 2026-09-13 · official docs
Whether it suits you.
A container you already build, that should cost nothing when nobody is using it. Scales to zero by default and back up on request volume, with a 60-minute ceiling per request that most request-driven platforms do not offer.
Consider something else if…
You need a process that stays running between requests, or a disk that survives a deploy.
Visit Google Cloud Run documentation