In the previous lessons, you've learned about Google Cloud Run as a serverless platform and how to configure service resources like CPU, memory, and scaling parameters. You've also deployed basic Cloud Run services in earlier practices to get hands-on experience with the fundamentals. However, those initial deployments focused on learning the basics — now it's time to take your deployment skills to the next level with production-ready configurations. This is where Cloud Run service deployment with enterprise-grade components comes into play. A production Cloud Run service goes beyond basic deployment to include proper image management, logging infrastructure, and operational visibility — all essential for real-world applications.

In this lesson, you'll deploy a production-ready Cloud Run service that pulls a container image from Google Artifact Registry, exposes your web application to the internet, and automatically ships application logs to Cloud Logging for monitoring and debugging. This represents a realistic scenario in which you're deploying a custom web application that needs secure image storage, network connectivity, and centralized logging — moving beyond the simple deployments you've done previously.

Your main goal is to deploy a Cloud Run service using the gcloud command-line tool that incorporates these three critical components: Artifact Registry integration for private container images, automatic HTTPS endpoint creation for network access, and Cloud Logging integration for operational visibility. By the end of this lesson, you'll have a running Cloud Run service that's accessible via a public URL and understand how to manage its complete lifecycle in a production context.

Before deploying your Cloud Run service, you need to know the full path to your container image in Artifact Registry. This path follows a specific format and includes your Google Cloud project ID, the region, the repository name, and the image name with its tag.

The standard format for an Artifact Registry image URI is: REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE_NAME:TAG

For this lesson, we will use the following values:

• Service Name: my-web-app
• Region: us-central1
• Image URI: us-central1-docker.pkg.dev/YOUR_PROJECT_ID/my-apps/my-web-app:latest

You will need to replace YOUR_PROJECT_ID with your actual Google Cloud project ID in the commands that follow. You can find your project ID in the Google Cloud Console or by running gcloud config get-value project.

With your image path ready, you can deploy your Cloud Run service. The deployment process involves a single gcloud run deploy command that handles everything: pulling your container image from Artifact Registry, creating the service configuration, provisioning the necessary infrastructure, and exposing your application via an HTTPS endpoint.

Cloud Run automatically handles many aspects of deployment that would require explicit configuration on other platforms. For example, Cloud Run automatically integrates with Cloud Logging to capture your container's stdout and stderr output, creates secure HTTPS endpoints with managed SSL certificates, and configures health checks to ensure your service is running properly.

Run this command in your terminal to deploy your service, making sure to replace YOUR_PROJECT_ID with your actual project ID:

This deployment command combines the resource and scaling configurations you learned in Unit 2 with several deployment-specific parameters:

• my-web-app: The name of your service. This name will be part of your service's URL and used for all management operations.
• --image: Specifies the full container image URI from Artifact Registry. Cloud Run will pull this image and run it as your service.
• --platform=managed: Indicates that you're using the fully managed Cloud Run platform, where Google handles all infrastructure. This is the standard option for most deployments.
• --allow-unauthenticated: Makes your service publicly accessible without requiring authentication. For production services that need access control, you would omit this flag and configure IAM permissions instead.
• --port=3000: Tells Cloud Run which port your container listens on for HTTP requests. Cloud Run will route incoming traffic to this port. Your container must listen on this port for the service to work correctly.

When you run this command, Cloud Run will perform several operations in sequence. First, it authenticates with Artifact Registry and pulls your container image. Then it creates a new service revision with your specified configuration. Finally, it routes traffic to this new revision and provides you with a public HTTPS URL.

The deployment process typically takes 30–60 seconds. You'll see output similar to this:

The Service URL is your application's public endpoint. You can open this URL in a browser or use curl to test your deployed service:

After deploying your service, you'll often want to inspect its configuration to verify that all settings were applied correctly. Cloud Run provides the gcloud run services describe command for this purpose, which shows you comprehensive information about your service, including its current revision, resource allocation, scaling configuration, and endpoint URL.

Run this command to view your service details in a human-readable YAML format:

The --format=yaml flag outputs the service configuration in YAML, which is easier to read than the default JSON output. You'll see detailed information including:

This output shows you the complete service configuration, including some values that Cloud Run set automatically. Key sections to note:

• spec.template.spec.containers: Shows your container configuration, including the image URI, port, and resource limits you specified during deployment.
• spec.template.spec.containerConcurrency: Indicates how many concurrent requests a single container instance can handle. Cloud Run sets this to 80 by default, meaning each instance can process up to 80 requests simultaneously.
• status.url: Your service's public HTTPS endpoint.
• status.conditions: Shows the health status of your service. When type: Ready has , your service is successfully deployed and serving traffic.

You can also use a more concise format to view just the essential information, which is useful for scripting and automation.

This will output just the service URL and its ready status.

One of Cloud Run's most valuable features is its automatic integration with Cloud Logging. Every line your container writes to stdout or stderr is automatically captured and sent to Cloud Logging, where you can search, filter, and analyze your application logs. This happens without any configuration on your part — you don't need to install logging agents or configure log destinations.

To view your service's logs, use the gcloud run services logs read command:

The --limit=50 flag restricts the output to the 50 most recent log entries. You'll see logs from your container's startup, any requests it has handled, and any errors or warnings your application has generated:

Each log entry includes a timestamp, the revision name, and the actual log message from your application. Cloud Run also adds metadata about the request, such as the HTTP method, path, status code, and response time.

For real-time log monitoring, you can use the --follow flag to stream logs as they're generated:

This command will continue running and display new log entries as they arrive, similar to tail -f for local log files. Press Ctrl+C to stop following the logs.

As your application evolves, you'll need to update your Cloud Run service. This might involve deploying a new version of your container image or changing its configuration, such as setting environment variables. Cloud Run makes updates simple — you use the same gcloud run deploy command with modified parameters.

When you deploy an update, Cloud Run creates a new revision of your service. By default, Cloud Run automatically routes all traffic to the new revision once it's ready, ensuring zero-downtime deployments. The previous revision remains available, allowing you to roll back if needed.

Here's an example of updating your service to use a new image tag and set some environment variables for the application. Remember to replace YOUR_PROJECT_ID.

This command updates the image and introduces a new flag:

• --set-env-vars: Sets environment variables inside the running container. This is a common way to pass configuration like database connection strings, API keys, or application settings. Variables are provided as a comma-separated list of KEY=VALUE pairs.

Cloud Run will create a new revision, and once it's healthy, route 100% of traffic to it. The service URL remains the same.

You can list all available revisions for your service to see its deployment history.

The output will show each revision, its creation time, and the percentage of traffic it's currently serving.

To inspect the exact configuration of a specific revision (like the environment variables you just set), use the revisions describe command with the revision's name.

Imagine your new revision (-00002-def) has a critical bug. You can quickly roll back by redirecting all traffic to the previous, stable revision (-00001-abc).

Use the services update-traffic command to manage traffic distribution. To roll back, you simply direct 100% of traffic to the older revision's name.

This command updates the traffic routing instantly, effectively rolling back the change without needing to redeploy anything. The faulty revision remains but receives no traffic, allowing you to debug it later.

When you no longer need a Cloud Run service, you can delete it to stop incurring any charges and clean up your project. Deleting a service removes all of its revisions and makes the service URL inaccessible. This is a permanent operation that cannot be undone, so make sure you really want to delete the service before proceeding.

To delete your service, use the gcloud run services delete command:

You'll see a confirmation prompt. Type Y and press Enter to confirm the deletion. Cloud Run will remove the service and all its revisions:

After deletion, the service URL will no longer be accessible. The container image in Artifact Registry remains unchanged — deleting a Cloud Run service only removes the running service, not the underlying container image.

In this lesson, you deployed and managed a production-ready Cloud Run service, learning the complete lifecycle from deployment to deletion.

The Cloud Run service you deployed demonstrates the platform's key capabilities: automatic container orchestration, built-in HTTPS endpoints, seamless integration with Cloud Logging, and zero-downtime deployments through revision management. You learned how Cloud Run handles infrastructure concerns automatically, allowing you to focus on your application.

In the upcoming practice exercises, you'll build on these fundamentals by exploring more advanced Cloud Run features. You'll learn how to manage secrets for your services, implement traffic splitting for gradual rollouts, set up custom domains, and integrate with other Google Cloud services like Cloud SQL and Cloud Storage. These skills will enable you to deploy production-ready applications with confidence.