Your First GCP Cloud Run Deployment

Objective

Deploy a simple containerized application to GCP Cloud Run from scratch, understanding each step rather than copy-pasting a command sequence blindly. By the end, you'll have a real, publicly reachable URL serving your own code, and you'll understand what "serverless" actually means in concrete terms.

Setup

Confirm your starting state before beginning:

gcloud auth login
gcloud config set project YOUR_PROJECT_ID
gcloud config list

Confirm the output shows the correct project ID and an authenticated account. If you don't yet have a project, create one in the GCP Console first — this lab assumes billing is already enabled, since Cloud Run has a generous free tier but still requires a billing account attached.

Steps

1. Confirm you have a simple deployable application locally. For this lab, any minimal web server that listens on a port and responds to HTTP requests works — it doesn't need to be complex. If you don't have one handy, a two-line Node.js/Express "hello world" server is enough.

2. Enable the required GCP APIs (only needs to be done once per project):

   gcloud services enable run.googleapis.com
   gcloud services enable cloudbuild.googleapis.com
   

3. Deploy directly from source, letting Cloud Build handle the container image creation for you:

   gcloud run deploy my-first-service --source . --region asia-south1 --allow-unauthenticated
   

   Here, --source . tells Cloud Run to build a container from your current directory automatically (using Cloud Build behind the scenes), --region picks a physical deployment region, and --allow-unauthenticated makes the resulting URL publicly reachable without requiring GCP credentials to view it — appropriate for a public-facing web page, not for anything sensitive.

4. Wait for the deployment to complete. The command will print a service URL once done — this is a real, public HTTPS URL, TLS certificate included automatically, with no manual certificate setup required.

5. Open the printed URL in a browser and confirm your application responds.

6. List your service's revisions to see what was actually created:

   gcloud run revisions list --service my-first-service --region asia-south1
   

   Notice that each deployment creates a new, immutable revision — this is what makes a rollback on Cloud Run straightforward: traffic can be redirected to any prior revision without rebuilding anything.

Verification checklist

• A container image was successfully built from your source code.
• The image was deployed to Cloud Run and shows a healthy, serving revision.
• You can load the deployed service's URL in a browser and see your application respond.
• You can explain, in your own words, what "serverless" means in the context of what you just deployed.

If the last checklist item feels shaky: "serverless" here specifically means you never provisioned, sized, or patched a virtual machine — Cloud Run manages the underlying compute, automatically scales your service up when traffic arrives and down to zero when it doesn't (so you aren't paying for idle capacity), and you were responsible only for the application code and its container definition.

Extend this lab

Try deploying a second, deliberately broken version of your application, confirm it fails or serves errors, then redirect traffic back to the previous healthy revision using gcloud run services update-traffic — this is a hands-on preview of the same rollback thinking covered in Rolling Back a Bad Deployment Safely, applied specifically to Cloud Run's revision model.

Verification checklist

• A container image was successfully built from your source code.
• The image was deployed to Cloud Run and shows a healthy, serving revision.
• You can load the deployed service's URL in a browser and see your application respond.
• You can explain, in your own words, what 'serverless' means in the context of what you just deployed.

Part of: DevOps Beginners, Cloud Beginners

Continue learning

Mark this article as read

← Back to Labs