Introduction to Serverless Apps with Google Cloud Run

Google Cloud Run is a new service that was announced on Cloud Next 19. In this blog, I’ll give you an introduction and compare it to App Engine and Cloud Functions.

What is it?

Cloud Run is Google’s latest managed compute platform, which allows you to run HTTP-invocable containers.

Since Cloud Run is a managed and serverless service, Google takes care of all infrastructure management such as provisioning, configuring and managing servers. It also offers traffic-based automatic scaling from zero to an upper limit of 1000 containers.

It’s based on Knative, a Kubernetes platform created by Google.
It’s also possible to use Cloud Run in your existing Kubernetes cluster with Cloud Run on GKE.
You can use this if you’ve already invested in GKE or if you need specific GKE features like custom networking and GPUs.


With Cloud Run, you pay for compute, memory, requests and network egress. Billable time starts when the container instance is starting and when at least one request is being processed. So, if there are no requests, the application is free. There is also a free tier, which resets every month.
Additional information about Cloud Run pricing can be found here.


When I think of HTTP-driven Serverless Google offerings my first thoughts go to Google App Engine and Google Cloud Functions.
So, what makes Cloud Run different?

  • App Engine
    Google App Engine Standard offers the possibility to deploy HTTP applications, but is limited to specific languages/runtimes. While Google also offers support for custom runtimes with App Engine Flex, this suggests Cloud Run as the chosen service for custom runtimes. Since App Engine Flex is built on VMs, it is slower with deploy and scale operations. The pricing model is also different since App Engine Flex is always running at least 1 instance at any time.

  • Cloud Functions
    Where Google App Engine and Cloud Run are intended to run a whole application, Cloud Functions support functions as its unit of deployment.
    This event-driven service allows you to setup a trigger, which then executes your code.
    Cloud Functions are also more opinionated about how the code is deployed and only Support Node.js, Python 3, and Go runtimes.


As of writing, Google Cloud Run is in Beta. This means that no SLA applies to this service and features might change or have limited support.
Also, the fully managed version of Cloud Run does not (yet) support the following services:

  • Virtual Private Cloud Networks
  • VPC Service Controls
  • Cloud Memorystore
  • Cloud Filestore

To get around these problems, you could consider using Cloud Run on GKE.

Integrating with other services

Using the Google Cloud Client Libraries, you can integrate with other GCP services, like Cloud Storage and Cloud Datastore, to enhance your application. For Cloud SQL, you must use the SQL proxy.

Cloud Run is integrated with Stackdriver, which allows you to get logging and monitoring information from your application.

It’s also possible to use Cloud Run as a target for Cloud Pub/Sub, Cloud Tasks, and Cloud Scheduler by using the HTTP integration.


Because Cloud Run serves a (Docker) container, you need to build a container image. This container image can run code written in any programming language, using any base image, if it listens to HTTP requests.

To create an image, you first need a Dockerfile.
Based on this file an image can be build and pushed to a registry with either Cloud Build or with docker build & docker push.

While building your image, you have to keep the following things in mind for Cloud Run:

  • The container must listen for requests on on the port defined by a PORT environment variable.
  • A Container instance must be able to start an HTTP server within 4 minutes.
  • Data written to the filesystem does not persist when the container instance is stopped.
  • Your service should be stateless.
  • Container image should be stored in Google Container Registry, Cloud Run on GKE can use an image from any registry.
  • Optimize for application startup speed to minimize latency during scaling.


Once you’ve created the container image, it’s possible to deploy it to the service with:

gcloud beta run deploy [SERVICE] \ 
--image[PROJECT-ID]/[IMAGE] \
--region [REGION] \
--platform managed

If you want to deploy the application using Cloud Run on GKE, you have to change the platform to gke and add the following to above command:

--cluster [CLUSTER_NAME] \ 
--cluster-location [CLUSTER_LOCATION]

Furthermore, you can change the maximum amount of memory, add environment variables, set a maximum request number per container and a request timeout.

Of course it’s also possible to make building and deploying your Cloud Run application part of your CI/CD pipeline. A tutorial can be found here.

When your deployment has succeeded you will receive a URL that you can use to reach your application. Each application has a unique and permanent URL.

Cloud Run services are deployed privately by default, more details on how to configure this can be found here.
Cloud Run is a regional service with automatic replication across multiple zones.

A couple of days ago, Google introduced the ‘Cloud Run Button’, a feature that makes it possible to deploy to Cloud Run from a Git repository. Click on the button below to try this out with an example application.

Martijn van de Grift is a cloud consultant at, where he specializes in creating solutions using GCP and AWS. He holds most relevant technical certifications for both clouds. Martijn has a great passion for IT and likes to work with the latest technologies. He loves to share this passion during training and webinars. One of his trainings is O’Reilly’s GCP Certified Data Engineering Exam Preparation.
Share this article: Tweet this post / Post on LinkedIn