Cloud Run is a managed compute platform that lets you run stateless containers. You can deploy container images to Cloud Run directly from Artifact Registry, Google Cloud’s unified artifact management service.
Let’s see this in action. Imagine you have a simple Go web server:
package main
import (
"fmt"
"log"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintln(w, "Hello, Cloud Run!")
})
port := "8080" // Cloud Run sets the PORT environment variable
log.Printf("Server listening on port %s", port)
if err := http.ListenAndServe(":"+port, nil); err != nil {
log.Fatal(err)
}
}
First, you need to build this code into a container image. You’ll need a Dockerfile:
# Use the official Golang runtime as a parent image
FROM golang:1.21-alpine
# Set the working directory in the container
WORKDIR /app
# Copy the local package files to the container's working directory
COPY . .
# Build the Go app
RUN go build -o main .
# Expose the port the app runs on
EXPOSE 8080
# Define the command to run the application
CMD ["./main"]
Now, build the image and push it to Artifact Registry. You’ll need to have Artifact Registry enabled and create a repository. Let’s assume your project ID is my-gcp-project and you want to create a repository named my-repo in us-central1.
# Authenticate Docker with Artifact Registry
gcloud auth configure-docker us-central1-docker.pkg.dev
# Build the Docker image
docker build -t us-central1-docker.pkg.dev/my-gcp-project/my-repo/my-app:v1.0 .
# Push the image to Artifact Registry
docker push us-central1-docker.pkg.dev/my-gcp-project/my-repo/my-app:v1.0
With the image successfully pushed, you can deploy it to Cloud Run.
gcloud run deploy my-service \
--image us-central1-docker.pkg.dev/my-gcp-project/my-repo/my-app:v1.0 \
--platform managed \
--region us-central1 \
--allow-unauthenticated
This command tells Cloud Run to deploy a new service named my-service using the specified container image, running in the us-central1 region, and accessible to the public internet. Cloud Run will pull the image from Artifact Registry and start serving requests.
The problem this solves is decoupling your application’s build artifacts from your deployment environment. Instead of building your code on a CI/CD runner and then deploying it, you build a self-contained container image and store it in a registry. Cloud Run then consumes this image, ensuring that what you build is exactly what you run.
Internally, when you deploy to Cloud Run, Google manages the underlying infrastructure. It takes your container image, schedules it onto available compute resources, and provides a public endpoint. It handles scaling, load balancing, and networking. You don’t provision VMs or manage clusters; you just provide the container.
The key levers you control are the container image itself (its contents, dependencies, and how it’s built), the Cloud Run service configuration (CPU, memory, environment variables, concurrency, scaling settings), and the IAM permissions that allow Cloud Run to pull from Artifact Registry.
A common misconception is that Cloud Run needs direct access to your source code. It doesn’t. It only needs the container image. This is why using a registry like Artifact Registry is crucial – it acts as the immutable source of truth for your deployable artifact.
The next concept you’ll likely explore is setting up CI/CD pipelines to automate the build and push of new container images to Artifact Registry, and then trigger Cloud Run deployments.