Node.js on Google Cloud Run
Google Cloud Run publishes its own guide for deploying Node.js.
JavaScript runtime used to run servers and build tooling outside the browser.
What Node.js needs.
Every host claims to run Node.js, so the claim on its own decides nothing. These are the things Node.js actually requires from the platform underneath it, and what Google Cloud Run publishes about each. Google Cloud Run documents 4 of the 4.
Persistent processes
Limited — instance-based billing keeps CPU allocated
A long-running process is the point: WebSocket connections, in-memory caches and job queues all die with it. A host that only runs functions cannot keep one alive.
Sources (1) →Sources ↓
- Billing settings for Cloud Run services — Google Cloud Documentation ↗
“With request-based billing, CPU is only allocated during request processing. With instance-based billing, CPU is allocated for the entire container instance lifecycle. [...] Instance-based billing can be useful for running short-lived background tasks and other asynchronous processing tasks. This setting was previously called CPU always allocated.”
Read 2026-09-09 · official docs
Max request duration
5 minutes by default, extendable to 60 minutes per request.
Anything the process does inside a request — a large upload, a slow query, a streamed response — is bounded by this ceiling.
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
Docker deployment
Supported
Node apps routinely need a system binary the platform's buildpack does not ship. A Dockerfile is the escape hatch when they do.
Sources (1) →Sources ↓
- Deploy container images to Cloud Run services — Google Cloud Documentation ↗
“You can directly use container images stored in Artifact Registry, or public images from Docker Hub or GitHub Container Registry.”
Read 2026-09-09 · official docs
Scales to zero
Supported
An always-on process bills while idle. Scaling to zero removes that cost and adds a cold start to the next request instead.
Sources (1) →Sources ↓
- About instance autoscaling in Cloud Run services — Google Cloud Documentation ↗
“When a revision does not receive any traffic, by default, it is scaled to zero instances.”
Read 2026-09-09 · official docs
What Google Cloud Run documents.
Google Cloud Run publishes its own guide for deploying Node.js.
In addition to sources with a Dockerfile, deploying from source supports the following languages using Google Cloud's buildpacks: Runtime Source deployment Configuration Go Deploy a Go service Configure Go buildpacks Node.js Deploy a Node.js service Configure Node.js buildpacks Python Deploy a Python service Configure Python buildpacks Java (includes Kotlin, Groovy, Scala) Deploy a Java service Configure Java buildpacks [...] PHP Deploy a PHP service Configure PHP buildpacks
Sources (1) →Sources ↓
- Deploy services from source code — Cloud Run — Google Cloud Documentation ↗
“In addition to sources with a Dockerfile, deploying from source supports the following languages using Google Cloud's buildpacks: Runtime Source deployment Configuration Go Deploy a Go service Configure Go buildpacks Node.js Deploy a Node.js service Configure Node.js buildpacks Python Deploy a Python service Configure Python buildpacks Java (includes Kotlin, Groovy, Scala) Deploy a Java service Configure Java buildpacks [...] PHP Deploy a PHP service Configure PHP buildpacks”
Read 2026-09-09 · official docs
Node.js features on Google Cloud Run
Capabilities Google Cloud Run documents specifically for Node.js, with the constraint it documents alongside each.
websockets
Supported
WebSockets applications are supported on Cloud Run with no additional configuration required. [...] Increase the request timeout period to the maximum duration you would like to keep the WebSockets stream open, for example 60 minutes.
configurable_request_timeout
Supported
The timeout is set by default to 5 minutes (300 seconds) and can be extended up to 60 minutes (3600 seconds). [...] You can change this setting when you deploy a container image or by updating the service configuration.
background_workers
Supported
Worker pools are a Cloud Run resource specifically designed for performing continuous background work. In contrast to Cloud Run services, worker pools do not have a load balanced endpoint/URL and do not support autoscaling.
Sources (3) →Sources ↓
- Using WebSockets | Cloud Run | Google Cloud Documentation ↗
“WebSockets applications are supported on Cloud Run with no additional configuration required. [...] Increase the request timeout period to the maximum duration you would like to keep the WebSockets stream open, for example 60 minutes.”
Read 2026-09-13 · official docs
- Configure request timeout for services | Cloud Run | Google Cloud Documentation ↗
“The timeout is set by default to 5 minutes (300 seconds) and can be extended up to 60 minutes (3600 seconds). [...] You can change this setting when you deploy a container image or by updating the service configuration.”
Read 2026-09-13 · official docs
- Deploy worker pools to Cloud Run | Google Cloud Documentation ↗
“Worker pools are a Cloud Run resource specifically designed for performing continuous background work. In contrast to Cloud Run services, worker pools do not have a load balanced endpoint/URL and do not support autoscaling.”
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