Deploying Serverless Containers with Cloud Run: A Complete Guide to Services, Jobs, and Worker Pools

Cloud Run enables you to deploy any OCI-compatible container image to a fully-managed serverless environment that automatically scales from zero to thousands of instances based on HTTP traffic or task completion requirements.

Deploying serverless containers with Cloud Run abstracts away underlying infrastructure management while providing enterprise-grade security, global availability, and pay-per-use pricing. According to the google/skills repository, Cloud Run supports three primary resource types—Services, Jobs, and Worker pools—each optimized for specific workload patterns ranging from HTTP-backed APIs to parallel batch processing and pull-based event consumption.

Cloud Run Architecture and Resource Types

Cloud Run operates on a revision-based deployment model where each deployment creates an immutable snapshot of your container image and configuration. As documented in skills/cloud/cloud-run-basics/SKILL.md, the platform manages three distinct resource types:

• Services – Stateless HTTP-backed containers that autoscale from zero to thousands of instances based on request concurrency and latency.
• Jobs – One-off or scheduled parallel tasks that run to completion, ideal for data processing, ETL pipelines, or batch operations.
• Worker pools – Always-on containers designed for pull-based workloads such as Pub/Sub or Kafka consumers.

All resources run on Google’s global infrastructure and share a common security model based on IAM roles and ingress/egress controls. Each deployment creates a revision that receives a stable HTTPS endpoint (for services) or execution context (for jobs), enabling traffic splitting and rollback capabilities.

Deployment Methods

The gcloud CLI provides multiple pathways for deploying serverless containers with Cloud Run, depending on whether you are pushing pre-built images or deploying directly from source code.

Deploy from Container Image

For production workloads with existing CI/CD pipelines, deploy directly from Artifact Registry or any OCI-compliant registry:

gcloud run deploy SERVICE_NAME \
    --image us-docker.pkg.dev/my-project/my-repo/my-image:latest \
    --region us-central1 \
    --allow-unauthenticated \
    --quiet

This command pulls the specified image, creates a new service revision, and exposes a stable HTTPS endpoint at *.run.app.

Deploy from Source with Buildpacks

When iterating locally without a Docker daemon, use Cloud Buildpacks to automatically detect your language runtime and build the container:

gcloud run deploy SERVICE_NAME \
    --source . \
    --region us-central1 \
    --platform managed \
    --quiet

Buildpacks analyze your source directory, generate an optimized container image, and deploy it without requiring a local Dockerfile.

Deploy with Custom Dockerfile

To maintain full control over the build environment while still deploying from source, specify a custom Dockerfile path:

gcloud run deploy SERVICE_NAME \
    --source . \
    --dockerfile Dockerfile \
    --quiet

Deploy Cloud Run Jobs

For batch processing or scheduled tasks, create a Cloud Run Job instead of a service:

gcloud run jobs create my-job \
    --image us-docker.pkg.dev/my-project/my-repo/my-job-image:latest \
    --region us-central1 \
    --quiet

Execute the job immediately and wait for completion using:

gcloud run jobs execute ingest-job \
    --region asia-east1 \
    --wait

Deploy Worker Pools

For continuous pull-based workloads that require always-on instances:

gcloud run worker-pools deploy my-pool \
    --image us-docker.pkg.dev/my-project/my-repo/worker-image:latest \
    --region us-central1 \
    --quiet

IAM Roles and Security Configuration

Before deploying serverless containers with Cloud Run, ensure your identity possesses the required IAM roles documented in skills/cloud/cloud-run-basics/references/iam-security.md:

• roles/run.admin – Create, update, and delete Cloud Run services and jobs.
• roles/run.sourceDeveloper – Deploy directly from source code using Buildpacks.
• roles/iam.serviceAccountUser – Bind specific service accounts to Cloud Run workloads.
• roles/logging.viewer – Access execution logs for troubleshooting and monitoring.

If using Cloud Build for image compilation, additionally grant roles/run.builder to the Cloud Build service account to enable container pushing and deployment orchestration.

Networking and Egress Controls

Cloud Run provides granular network isolation through ingress and egress configurations defined in skills/cloud/cloud-run-basics/references/networking.md.

Ingress Controls restrict who can invoke your services:

• --ingress allow-all – Public internet access (default).
• --ingress internal-only – VPC-only access.
• --ingress internal-and-cloud-load-balancer – Access only via External HTTP(S) Load Balancer, blocking direct *.run.app access.

Direct VPC Egress enables private resource access without traversing the public internet. Enable Private Google Access on your subnet and attach a VPC connector:

gcloud run deploy SERVICE_NAME \
    --image IMAGE_URL \
    --vpc-connector CONNECTOR_NAME \
    --region REGION

This configuration allows your container to reach Cloud SQL, Memorystore, or internal corporate resources using private IP addresses.

Monitoring and Observability

Cloud Run integrates natively with Cloud Logging, Cloud Monitoring, and Cloud Trace. The platform automatically captures stdout/stderr streams, request latencies, and instance counts. For detailed network traffic analysis, enable VPC Flow Logs on the subnet hosting your VPC connector, as referenced in the networking best practices documentation.

Summary

• Cloud Run supports three resource types: Services (HTTP), Jobs (batch), and Worker pools (pull-based), all defined by immutable revisions.
• Deploy containers using gcloud run deploy for pre-built images or gcloud run deploy --source for Buildpack-based builds from local code.
• Secure deployments require specific IAM roles including roles/run.admin and roles/run.sourceDeveloper, documented in the repository's IAM security reference.
• Control traffic flow using ingress settings (public, internal, or load-balancer-only) and enable Direct VPC Egress for private resource access.
• Monitor serverless workloads through native integration with Google Cloud's operations suite, with optional VPC Flow Logs for network debugging.

Frequently Asked Questions

What is the difference between Cloud Run Services and Cloud Run Jobs?

Cloud Run Services are stateless HTTP containers that autoscale based on incoming request volume and remain available to handle traffic continuously. Cloud Run Jobs are designed for finite tasks that run to completion and exit, supporting parallel execution for batch processing workloads. Services expose HTTPS endpoints, while Jobs are invoked manually or via schedules.

How do I restrict public access to my Cloud Run service?

Set the ingress policy to internal-only or internal-and-cloud-load-balancer using the --ingress flag. For example, gcloud run deploy SERVICE --ingress internal-and-cloud-load-balancer ensures the service is reachable only through an External HTTP(S) Load Balancer, preventing direct access via the default *.run.app URL.

Can I deploy to Cloud Run without writing a Dockerfile?

Yes. Use the --source flag with gcloud run deploy to leverage Cloud Buildpacks, which automatically detect your application language (Node.js, Python, Go, Java, etc.) and generate an optimized container image. This method requires no local Docker installation and is documented in skills/cloud/cloud-run-basics/SKILL.md.

What IAM permissions are required to deploy from source code?

In addition to roles/run.admin, users deploying from source require roles/run.sourceDeveloper to trigger Buildpack builds. The Cloud Build service account also needs roles/run.builder to push the resulting image and create the revision. These requirements are detailed in the IAM security reference file within the google/skills repository.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}