This page lists key requirements and behaviors of containers in Cloud Run
Your container image can run code written in the programming language of your choice and use any base image, provided that it respects the constraints listed in this page.
Executables in the container image must be compiled for Linux 64-bit. Cloud Run specifically supports the Linux x86_64 ABI format.
Listening for requests on
The container must listen for requests on
0.0.0.0 on the port
defined by the
PORT environment variable.
In Cloud Run container instances, the
PORT environment variable is
always set to
8080, but for portability reasons, your code should not hardcode
Startup times and response times
Your container instances must start an HTTP server within 4 minutes after receiving a request.
Your container instance must send a response within the time specified in the request timeout setting after it receives an HTTP request, including the container instance startup time. Otherwise the request is ended and a 504 error is returned.
The following environment variables are automatically added to the running containers:
||The port your HTTP server should listen on.||
||The name of the Cloud Run service being run.||
||The name of the Cloud Run revision being run.||
||The name of the Cloud Run configuration that created the revision.||
The filesystem of your container is writable and is subject to the following behavior:
- This is an in-memory filesystem, so writing to it uses the container instance's memory.
- Data written to the filesystem does not persist when the container instance is stopped.
Container instance lifecycle considerations
In response to incoming requests, each revision of a service is automatically scaled to a certain number of container instances, each of which runs the deployed container image.
When a revision does not receive any traffic, it is scaled down to zero container instances.
Computation is scoped to a request
You should only expect to be able to do computation within the scope of a request: a container instance does not have any CPU available if it is not processing a request.
Your service should be stateless: you should not rely on the state of a service across requests because a container instance can be started or stopped at any time.
Container instance resources
Cloud Run allocates 1 vCPU per container instance, and this cannot be changed. A vCPU is implemented as an abstraction of underlying hardware to provide the approximate equivalent CPU time of a single hardware hyper-thread on variable CPU platforms. The container instance may be executed on multiple cores simultaneously.
The vCPU is only allocated during container instance startup and request processing, it is throttled otherwise.
Each Cloud Run container instance by default gets 256 MiB of memory. You can change this by configuring memory limits, up to a maximum of 2 GiB.
Typical uses of memory include:
- Code loaded into memory to run the service
- Writing to the filesystem
- Extra processes running in the container such as an nginx server
- In-memory caching systems such as the PHP OpCache
- Per request memory usage
Each Cloud Run container instance by default is set to multiple concurrency, where each container instance can receive more than one request at the same time. You can change this by setting concurrency.
Container instance sandbox
The Cloud Run container instances are sandboxed using the gVisor container runtime sandbox. As documented in the syscall compatibility reference, some system calls might not be supported by this container sandbox.
Cloud Run on GKE does not use any container sandbox.
Container instance metadata server
Cloud Run provides a metadata server that knows details about your container instance, such as its containing project ID, service accounts, and tokens used by the service accounts.
You can access this data using simple HTTP requests: no client libraries are required. For more information, see Storing and retrieving metadata.