n8n AI工作流自动化

Prerequisites

Before diving in, make sure you've got:

• A Google Cloud account (they offer a generous free tier for new accounts)

• gcloud CLI installed and configured (trust me, it's worth not clicking through web consoles)

• Basic familiarity with Docker and command line

• Docker (only needed if using custom image - Option B)

• A domain name (optional, but recommended for production use)

The command line approach might seem intimidating at first, but it means we can script the entire deployment process. And when you need to update or recreate your instance, you'll thank yourself for having everything in a reusable format.

Enable required APIs

gcloud services enable artifactregistry.googleapis.com gcloud services enable run.googleapis.com gcloud services enable sqladmin.googleapis.com gcloud services enable secretmanager.googleapis.com ```

These commands establish your project environment and enable the necessary Google Cloud APIs. We're turning on all the services we'll need upfront to avoid those annoying "please enable this API first" errors later.

Additional Prerequisites

Queue Mode requires: - The redis.googleapis.com and compute.googleapis.com APIs enabled - A VPC network in your project (the default auto-mode VPC is fine) - The VPC's Private Service Access peering range available (used by Cloud Memorystore)

Cloud Memorystore Redis instances are only reachable via a private VPC IP address — they have no public endpoint. Cloud Run connects to them through Direct VPC Egress, which routes private-range traffic (10.x.x.x, 172.16.x.x, 192.168.x.x) through the VPC while leaving public internet traffic on the normal path.

Step 2: Prepare n8n for Cloud Run Deployment

n8n needs a small startup delay when connecting to external databases to avoid a race condition during initialisation. There are two ways to handle this:

Option B: Custom Docker Image (Advanced)

If you need custom startup logic or want detailed debugging output, use a custom Docker image. This approach gives you more control but requires building and maintaining your own image.

Create these two files in your working directory:

startup.sh:

```bash #!/bin/sh

Configure Docker to use gcloud as a credential helper

gcloud auth configure-docker $REGION-docker.pkg.dev

Build and push your image

docker build --platform linux/amd64 -t $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest . docker push $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest ```

We're explicitly building for linux/amd64 because Cloud Run doesn't support ARM architecture. This is particularly important if you're developing on an M1/M2 Mac - Docker will happily build an ARM image by default, which then fails mysteriously when deployed. Ask me how I know.

Step 7: Deploy to Cloud Run

The moment of truth - let's deploy n8n. The command differs slightly depending on which approach you chose in Step 2.

First, get your Cloud SQL conection namne:

export SQL_CONNECTION=$(gcloud sql instances describe n8n-db --format="value(connectionName)")

Option A: Deploy Using Official Image (Recommended)

gcloud run deploy n8n \
    --image=docker.io/n8nio/n8n:latest \
    --command="/bin/sh" \
    --args="-c,sleep 5; n8n start" \
    --platform=managed \
    --region=$REGION \
    --allow-unauthenticated \
    --port=5678 \
    --cpu=1 \
    --memory=2Gi \
    --min-instances=0 \
    --max-instances=1 \
    --no-cpu-throttling \
    --set-env-vars="N8N_PORT=5678,N8N_PROTOCOL=https,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node/.n8n,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true,N8N_ENDPOINT_HEALTH=health" \
    --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest" \
    --add-cloudsql-instances=$SQL_CONNECTION \
    --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

Option B: Deploy Using Custom Image

```bash

Deploy to Cloud Run

gcloud run deploy n8n \ --image=$REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest \ --platform=managed \ --region=$REGION \ --allow-unauthenticated \ --port=5678 \ --cpu=1 \ --memory=2Gi \ --min-instances=0 \ --max-instances=1 \ --no-cpu-throttling \ --set-env-vars="N8N_PATH=/,N8N_PORT=443,N8N_PROTOCOL=https,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node,EXECUTIONS_PROCESS=main,EXECUTIONS_MODE=regular,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true,N8N_ENDPOINT_HEALTH=health" \ --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest" \ --add-cloudsql-instances=$SQL_CONNECTION \ --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com ```

After deployment, Cloud Run will provide a URL for your n8n instance. Note it down - you'll need it for the next steps.

Update the deployment with proper URL configuration

gcloud run services update n8n \ --region=$REGION \ --update-env-vars="N8N_HOST=$(echo $SERVICE_URL | sed 's/https:\/\///'),N8N_WEBHOOK_URL=$SERVICE_URL,N8N_EDITOR_BASE_URL=$SERVICE_URL" ```

Without these variables, OAuth would fail with utterly unhelpful "redirect_uri_mismatch" errors that make you question your life choices. Setting them correctly means n8n can construct proper callback URLs during authentication flows.

For newer versions of n8n use WEBHOOK_URL instead of N8N_WEBHOOK_URL.

Queue Mode Deployment: Scaling n8n for Production

The steps above give you a solid single-process n8n deployment. For most personal and small-team setups, that's all you'll ever need. But if you start running many concurrent heavy workflows, or if you want to keep the editor responsive while long-running workflows execute in the background, Queue Mode is the answer.

Step QM-5: Deploy the n8n Worker Service

Workers run the n8n worker command instead of n8n start. They do not serve public internet traffic — they poll Redis and connect to Cloud SQL.

gcloud run deploy n8n-worker \
    --image=docker.io/n8nio/n8n:latest \
    --command="/bin/sh" \
    --args="-c,sleep 5; n8n worker" \
    --platform=managed \
    --region=$REGION \
    --no-allow-unauthenticated \
    --ingress=internal \
    --port=5678 \
    --cpu=1 \
    --memory=2Gi \
    --min-instances=1 \
    --max-instances=3 \
    --no-cpu-throttling \
    --vpc-egress=private-ranges-only \
    --network=default \
    --subnet=default \
    --set-env-vars="EXECUTIONS_MODE=queue,DB_TYPE=postgresdb,DB_POSTGRESDB_DATABASE=n8n,DB_POSTGRESDB_USER=n8n-user,DB_POSTGRESDB_HOST=/cloudsql/$SQL_CONNECTION,DB_POSTGRESDB_PORT=5432,DB_POSTGRESDB_SCHEMA=public,N8N_USER_FOLDER=/home/node/.n8n,GENERIC_TIMEZONE=UTC,QUEUE_HEALTH_CHECK_ACTIVE=true,N8N_RUNNERS_ENABLED=true,QUEUE_BULL_REDIS_HOST=$REDIS_HOST,QUEUE_BULL_REDIS_PORT=$REDIS_PORT" \
    --set-secrets="DB_POSTGRESDB_PASSWORD=n8n-db-password:latest,N8N_ENCRYPTION_KEY=n8n-encryption-key:latest,QUEUE_BULL_REDIS_PASSWORD=n8n-redis-auth:latest" \
    --add-cloudsql-instances=$SQL_CONNECTION \
    --service-account=n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

Key worker settings explained:

Method 1: Rebuild and Redeploy (The Clean Way)

```bash

Rebuild your custom image

docker build --platform linux/amd64 -t $REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest .

Redeploy your Cloud Run service

gcloud run services update n8n \ --image=$REGION-docker.pkg.dev/$PROJECT_ID/n8n-repo/n8n:latest \ --region=$REGION

Update your Dockerfile to use this specific version

Then rebuild and redeploy as above

```

This approach lets you test new versions before committing to them. Check the n8n GitHub releases page to see what's new before upgrading.

Terraform Deployment Option

Thanks to a generous contribution from the community, there is now a Terraform configuration available to automate the entire deployment process described in this guide. This Terraform setup provisions all necessary Google Cloud resources including Cloud Run, Cloud SQL, Secret Manager, IAM roles, and Artifact Registry.

Using Terraform can simplify and speed up deployment, especially for those familiar with infrastructure as code. The Terraform files and a deployment script are included in the repository.

Quick Terraform Deployment

Clone the repository and navigate to terraform directory

git clone <your-repo-url>
cd <repo-name>/terraform

Initialize Terraform

terraform init

Review the planned changes

terraform plan

Deploy the infrastructure.

For Option A (recommended - official image):

terraform apply

For Option B (custom image):

terraform apply -var="use_custom_image=true"

Or in terraform.tfvars:

use_custom_image = true  # Only if you want custom image

Terraform Queue Mode Deployment

The Terraform configuration supports Queue Mode through a single feature flag. When enable_queue_mode = true, Terraform will additionally provision:

• A Cloud Memorystore Redis instance (private, VPC-peered)
• A Cloud Run worker service (n8n-worker) with internal ingress and min 1 instance
• A Redis AUTH secret in Secret Manager
• Direct VPC Egress on both Cloud Run services
• The redis.googleapis.com and compute.googleapis.com APIs

Enable Queue Mode via CLI flag:

terraform apply -var="enable_queue_mode=true"

Or in terraform.tfvars:

```hcl gcp_project_id = "your-project-id" enable_queue_mode = true

Self-Hosting n8n on Google Cloud Run: Complete Guide

So you want to run n8n without the monthly subscription fees, keep your data under your own control, and avoid the headache of server maintenance? Google Cloud Run offers exactly that sweet spot - serverless deployment with per-use pricing. Let's build this thing properly.

This guide walks you through deploying n8n (that powerful workflow automation platform) on Google Cloud Run with PostgreSQL persistence. You'll end up with a fully functional system that scales automatically, connects to Google services via OAuth, and won't drain your wallet when idle.

🚀 Quick Start Option: Want to skip the manual setup? Jump to the Terraform Deployment Option section for a streamlined, automated deployment. The step-by-step guide below is valuable for understanding what's happening under the hood, but Terraform will handle all the heavy lifting for you!

Option A: Using the Official Image (Recommended)

This is the simplest approach - use n8n's official Docker image with a command override to add a 5-second startup delay. This pattern comes from n8n's own Kubernetes deployments and works perfectly on Cloud Run.

No additional files needed! You'll use command overrides when deploying (covered in Step 7).

Print environment variables for debugging

echo "Database settings:" echo "DB_TYPE: $DB_TYPE" echo "DB_POSTGRESDB_HOST: $DB_POSTGRESDB_HOST" echo "DB_POSTGRESDB_PORT: $DB_POSTGRESDB_PORT" echo "N8N_PORT: $N8N_PORT"

Which option should you choose?

• Go with Option A if you just want n8n working reliably with minimal fuss

• Use Option B if you need debugging output or custom startup scripts

The rest of this guide will show commands for both approaches where they differ.

Step 3: Set Up a Container Repository (Optional - Custom Image Only)

If you're using Option A (official image), skip this step entirely and go straight to Step 4.

If you're using Option B (custom image), you'll need a place to store your custom container image:

```bash

Key Configuration Notes

Why --no-cpu-throttling? n8n does background processing (database connections, scheduled checks) that happens outside HTTP requests. With CPU throttling enabled, these background tasks get starved and can cause startup issues. This flag ensures n8n gets continuous CPU access, which actually works out cheaper due to eliminated per-request fees and lower CPU/memory rates. Thanks to the Google Cloud Run team for this insight.

Other important settings: - min-instances=0 and max-instances=1 means your service scales to zero when idle (saving money) but won't run multiple instances simultaneously (which can cause database conflicts with n8n) - CPU and memory allocation is sufficient for most workflows without excessive costs - The sleep 5 in Option A handles database initialization timing

Key Differences Between Options

n8n Google Cloud Run Environment Variables

Here's what all those environment variables do:

Pay special attention to DB_TYPE. It must be "postgresdb" not "postgresql" - a quirk that's caused many deployment headaches. And don't explicitly set the PORT variable as Cloud Run injects this automatically.

Step 8: Configure n8n for OAuth with Google Services

Now we need to update the deployment with environment variables that tell n8n how to properly generate URLs for OAuth callbacks:

```bash

Queue Mode Environment Variables Reference

For Option A (Official Image)

The simplest approach - just update the image tag:

Update to latest version:

gcloud run services update n8n \
    --image=docker.io/n8nio/n8n:latest \
    --region=$REGION

Or specify a version:

gcloud run services update n8n \
    --image=docker.io/n8nio/n8n:latest:1.115.2 \
    --region=$REGION

Cloud Run will pull the new image and deploy it automatically. Takes about 1-2 minutes.

If you're using Queue Mode, update the worker service too:

gcloud run services update n8n-worker \
    --image=docker.io/n8nio/n8n:latest \
    --region=$REGION

It's important that the main service and all workers run the same n8n version. Mixed versions in queue mode can cause queue protocol mismatches.

For Option B (Custom Image)

Updating Environment Variables

Sometimes you'll need to update environment variables rather than the container itself:

gcloud run services update n8n \
    --region=$REGION \
    --update-env-vars="NEW_VARIABLE=value,UPDATED_VARIABLE=new_value"

This is useful when you need to change configuration without rebuilding the container.

Optional: tune Redis and worker sizing

redis_tier = "BASIC" # or "STANDARD_HA" for production redis_memory_size_gb = 1 worker_min_instances = 1 worker_max_instances = 3 worker_cpu = "1" worker_memory = "2Gi"

Optional: specify VPC network/subnet if not using the default VPC

Step QM-1: Enable Additional APIs

gcloud services enable redis.googleapis.com
gcloud services enable compute.googleapis.com

Troubleshooting

Note: If you used Terraform for deployment, see the Terraform Troubleshooting section for deployment-specific issues.

When things inevitably go sideways, here are the most common issues and how to fix them:

1. Container Fails to Start:

• Check Cloud Run logs for specific error messages

• Verify DB_TYPE is set to "postgresdb" (not "postgresql")

• Ensure QUEUE_HEALTH_CHECK_ACTIVE is set to "true"
• Remove the EXECUTIONS_PROCESS=main and EXECUTIONS_MODE=regular environment variables as these are now deprecated in newer versions

1. OAuth Redirect Issues:

• Ensure N8N_HOST, N8N_PORT, and N8N_EDITOR_BASE_URL are correctly set

• Verify redirect URIs in Google Cloud Console match exactly what n8n generates

• Confirm N8N_PORT is set to 443 (not 5678) for external URL formatting

1. Database Connection Problems:

• Check DB_POSTGRESDB_HOST format for Cloud SQL connections

• Ensure service account has Cloud SQL Client role

1. Node Trigger Issues:

• Use WEBHOOK_URL instead of N8N_WEBHOOK_URL for newer n8n versions
• Add proxy hop configurations by including N8N_PROXY_HOPS=1 as Cloud Run acts as a reverse proxy

Terraform Troubleshooting

If you're encountering issues with Terraform deployment, especially after a previous manual installation attempt or a failed Terraform run, you may need to clean up existing resources first.

Common scenarios requiring cleanup: - You followed the manual steps before discovering the Terraform option - A previous Terraform deployment timed out or lost connectivity mid-build - You're seeing "resource already exists" errors

Clean up steps:

1. Remove Terraform state files (if you have a corrupted state):

cd terraform/
rm -rf terraform.tfstate*
rm -rf .terraform/

1. Delete existing Google Cloud resources via Console or CLI:

Artifact Registry:

gcloud artifacts repositories delete n8n-repo --location=$REGION

Cloud SQL Instance:

gcloud sql instances delete n8n-db

Secrets:

gcloud secrets delete n8n-db-password
gcloud secrets delete n8n-encryption-key
gcloud secrets delete n8n-redis-auth  # Queue Mode only

Service Account:

gcloud iam service-accounts delete n8n-service-account@$PROJECT_ID.iam.gserviceaccount.com

Cloud Run Services:

gcloud run services delete n8n --region=$REGION
gcloud run services delete n8n-worker --region=$REGION  # Queue Mode only

Cloud Memorystore Redis (Queue Mode only):

gcloud redis instances delete n8n-redis --region=$REGION

3. Alternative: Use Google Cloud Console - Navigate to each service (Cloud Run, Cloud SQL, Memorystore, Secret Manager, IAM, Artifact Registry) - Identify and delete resources with names matching the Terraform configuration - This visual approach can be easier for identifying partially-created resources

1. Re-run Terraform:

terraform init
terraform plan # Verify no conflicts remain
terraform apply

Pro tip: If you're unsure which resources were created, check the Terraform configuration files to see the exact resource names and types that will be provisioned.

Huge thanks to @alliecatowo for this valuable addition!

For more details and usage instructions, please see the terraform/ directory in this repository.

---

And there you have it - a fully functional n8n instance running on Google Cloud Run. You get all the benefits of self-hosting without the headache of managing servers. Your workflows run reliably, your data stays under your control, and you only pay for what you use.