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!

Table of Contents

• Quick Start with Terraform
• Manual Step-by-Step Guide
• Configuration
• Queue Mode Deployment
• Updates & Maintenance
• Cost Estimates
• Troubleshooting

Overview

n8n is brilliant for automating all those tedious tasks you'd rather not do manually. This setup uses:

• Google Cloud Run for hosting the application (pay only when it runs)

• Cloud SQL PostgreSQL for database persistence (because your workflows should survive restarts)

• Google Auth Platform for connecting to Google services (sheets, drive, etc.)

Why self-host? Complete control over your automation workflows and data. No arbitrary execution limits. No wondering where your sensitive data is being stored. And with Cloud Run, you get the best of both worlds - the control of self-hosting with the convenience of not having to manage actual servers.

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.

Community Video Walkthrough

Massive thanks to Terra Femme for creating this brilliant step-by-step video walkthrough of the entire deployment process! If you're more of a visual learner or want to see someone actually troubleshoot the common gotchas in real-time, this is gold.

▶️ Watch the deployment video by Terra Femme (@terra.femme).

The video covers the full Terraform deployment using Google Cloud Shell Editor, including the port configuration fix that trips up most people. It's basically a live demo of everything in this guide, which is pretty awesome.

Step 1: Set Up Your Google Cloud Project

First, let's get our Google Cloud environment sorted:

# Set your Google Cloud project ID
export PROJECT_ID="your-project-id"
export REGION="europe-west2"  # Choose your preferred region

# Log in to gcloud
gcloud auth login

# Set your active project
gcloud config set project $PROJECT_ID

# 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.

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 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).

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:

#!/bin/sh

# Add startup delay for database initialization
sleep 5

# Map Cloud Run's PORT to N8N_PORT if it exists
# Otherwise fall back to explicitly set N8N_PORT or default to 5678
if [ -n "$PORT" ]; then
  export N8N_PORT=$PORT
elif [ -z "$N8N_PORT" ]; then
  export N8N_PORT=5678
fi

# 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"

# Start n8n with its original entrypoint
exec /docker-entrypoint.sh

The port mapping script gives you flexibility - you can let Cloud Run assign the port dynamically OR set it explicitly. This is useful because:

1. Cloud Run auto-assigns ports - if someone deploys without setting --port=5678, Cloud Run will inject a PORT variable

2. Future-proofing - if Cloud Run changes port handling, the script adapts

3. Works in multiple environments - the same image works on Cloud Run, Cloud Run Jobs, or other container platforms

Option A doesn't need this because it explicitly sets everything via command-line flags.

Dockerfile:

FROM docker.n8n.io/n8nio/n8n:latest

# Copy the script and ensure it has proper permissions
COPY startup.sh /
USER root
RUN chmod +x /startup.sh
USER node
EXPOSE 5678

# Use shell form to help avoid exec format issues
ENTRYPOINT ["/bin/sh", "/startup.sh"]

This custom setup solves the port mismatch problem and helps with debugging. Without it, you'd just see a failed container with no helpful error messages. And yes, that's exactly as frustrating as it sounds.

If you run into problems with Option B:

• Check that your startup.sh file has Unix-style line endings (LF, not CRLF)

• Verify the file has proper execute permissions

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:

# Create a repository in Artifact Registry
gcloud artifacts repositories create n8n-repo \
    --repository-format=docker \
    --location=$REGION \
    --description="Repository for n8n workflow images"

# 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 4: Set Up Cloud SQL PostgreSQL Instance

Now for the database. We'll use the smallest instance type to keep costs reasonable:

# Create a Cloud SQL instance (lowest cost tier)
gcloud sql instances create n8n-db \
    --database-version=POSTGRES_13 \
    --tier=db-f1-micro \
    --region=$REGION \
    --root-password="supersecure-rootpassword" \
    --storage-size=10GB \
    --availability-type=ZONAL \
    --no-backup \
    --storage-type=HDD

# Create a database
gcloud sql databases create n8n --instance=n8n-db

# Create a user for n8n
gcloud sql users create n8n-user \
    --instance=n8n-db \
    --password="supersecure-userpassword"

The db-f1-micro tier is perfect for most personal n8n deployments. I've run hundreds of workflows on this setup without issue. And you can always upgrade later if needed.

Step 5: Create Secrets for Sensitive Data

Never put passwords in your deployment configuration. Let's use Secret Manager instead:

# Create a secret for the database password
echo -n "supersecure-userpassword" | \
    gcloud secrets create n8n-db-password \
    --data-file=- \
    --replication-policy="automatic"

# Create a secret for n8n encryption key
echo -n "your-random-encryption-key" | \
    gcloud secrets create n8n-encryption-key \
    --data-file=- \
    --replication-policy="automatic"

That encryption key is particularly important - it protects all the credentials stored in your n8n instance. Make it long, random, and keep it safe. If you lose it, you'll n