GCP Cloud Run
Relevant source files
The following files were used as context for generating this wiki page:
The @nx-extend/gcp-cloud-run package is an Nx plugin that automates the deployment of containerized applications to Google Cloud Run. It integrates with the Nx workspace to provide executors for building and deploying services, managing resource limits, and handling environment configurations.
This plugin streamlines modern full-stack development workflows by providing production-ready deployment targets specifically for the Google Cloud Platform (GCP).
Sources: packages/gcp-cloud-run/README.md:1-12, README.md:1-8
Core Features
The module provides several capabilities for managing Cloud Run services:
- Deployment Management: Deploys containerized applications with configurable scaling and resource limits.
- Container Integration: Supports automatic container builds via Cloud Build or Artifact Registry.
- Security: Manages secrets and environment variables within the Cloud Run environment.
- Connectivity: Connects instances to Cloud SQL and manages VPC settings.
- Traffic Control: Handles version tagging and traffic management between revisions.
Sources: packages/gcp-cloud-run/README.md:14-20
Deployment Logic
The deployment process follows a specific flow where the Nx executor interacts with Google Cloud CLI tools to build and deploy the application.
The diagram shows the two primary paths for deployment: utilizing local source code with Artifact Registry or submitting a build to Cloud Build to create an image.
Sources: packages/gcp-cloud-run/README.md:43-46
Deployment Options
The deploy executor accepts various options to configure the Cloud Run service instance.
| Name | Type | Default | Description |
|---|---|---|---|
region | string | - | Region to deploy Cloud Run revision to. |
project | string | - | GCP project ID. |
name | string | project name | Name of the Cloud Run service. |
concurrency | number | 250 | Max concurrent requests per instance. |
maxInstances | number | 10 | Maximum container instances. |
minInstances | number | 0 | Minimum container instances. |
memory | string | 128Mi | Reserved memory for the instance. |
cpu | number | - | CPU limit in Kubernetes CPU units. |
cpuBoost | boolean | - | Extra CPU on startup to reduce cold starts. |
allowUnauthenticated | boolean | true | Allows unauthenticated requests. |
buildWith | string | artifact-registry | Defaults to artifact-registry for source builds. |
noTraffic | boolean | false | Prevents traffic from routing to new revision. |
Sources: packages/gcp-cloud-run/README.md:33-56
Project Configuration
The plugin is structured as an Nx library with specific targets for development and distribution.
The diagram illustrates the standard Nx targets available for the plugin's own maintenance and lifecycle.
Sources: packages/gcp-cloud-run/project.json:1-68
Package Metadata
The package identifies as @nx-extend/gcp-cloud-run and requires @nx/devkit as a peer dependency.
{
"name": "@nx-extend/gcp-cloud-run",
"version": "14.1.2",
"peerDependencies": {
"@nx/devkit": "^22.0.0"
},
"builders": "./executors.json",
"generators": "./generators.json"
}
Sources: packages/gcp-cloud-run/package.json:1-18
Advanced Configuration Examples
Multi-Container and Volume Support
The plugin supports complex deployments including sidecars and volumes. These features allow Cloud Run services to run helper containers alongside the main application and mount persistent or temporary storage.
Sources: packages/gcp-cloud-run/CHANGELOG.md:144-146
Secrets Management
Secrets can be loaded into the Cloud Run environment using an array or object format. This allows for specific versioning (e.g., :latest) of secrets managed in Google Secret Manager.
{
"deploy": {
"executor": "@nx-extend/gcp-cloud-run:deploy",
"options": {
"secrets": [
"DATABASE_PASSWORD:latest",
"API_KEY:latest"
]
}
}
}
Sources: packages/gcp-cloud-run/README.md:83-93, packages/gcp-cloud-run/CHANGELOG.md:118-120
Conclusion
GCP Cloud Run integration in nx-extend provides a high-level abstraction over the gcloud CLI for Nx workspaces. By centralizing deployment configurations in project.json, teams can ensure consistent scaling, security, and resource management across multiple microservices within a monorepo.