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

> Deploy serverless containers on Cloud Run. This guide covers services, jobs, and worker pools, offering automatic scaling for your OCI-compatible container images.

- Repository: [Google/skills](https://github.com/google/skills)
- Tags: tutorial
- Published: 2026-08-09

---

**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`](https://github.com/google/skills/blob/main/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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

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

```

### Deploy Worker Pools

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

```bash
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`](https://github.com/google/skills/blob/main/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`](https://github.com/google/skills/blob/main/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:

```bash
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`](https://github.com/google/skills/blob/main/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.