Google Cloud
Run n8n on Compute Engine or Cloud Run.
Deploy n8n on Google Cloud Run for a serverless container (no idle cost when unused, but needs external Postgres) or on a Compute Engine VM with Docker Compose for a more traditional setup.
Pros
- Cloud SQL Postgres
- IAM + Secret Manager
- Great for BigQuery / Vertex AI workflows
Cons
- Cloud Run cold starts hurt webhooks
- IaC required for maintainability
Prerequisites
- A GCP project with billing enabled
- Cloud SQL for PostgreSQL instance (recommended over SQLite)
- A domain with DNS you control
- gcloud CLI (for Cloud Run)
Step-by-step guide
Step 1
Create a Cloud SQL Postgres instance
Choose a small tier (db-f1-micro) to start; note the connection name.
Step 2
Deploy n8n to Cloud Run
Deploy the n8nio/n8n image with the Cloud SQL Auth Proxy sidecar and required env vars.
gcloud run deploy n8n --image=n8nio/n8n --add-cloudsql-instances=PROJECT:REGION:INSTANCE --set-env-vars=DB_TYPE=postgresdb,N8N_HOST=your-domain.comStep 3
Map a custom domain
Use Cloud Run domain mappings or a Load Balancer for HTTPS on your own domain.
Step 4
Set concurrency & min instances
Set concurrency=1 (n8n isn't fully stateless per-request) and min-instances=1 to avoid cold starts breaking webhooks.
Scaling & queue mode
For heavy workloads, prefer GKE (Kubernetes) with a queue-mode Helm deployment over Cloud Run, since Cloud Run's request-based scaling model doesn't suit long-running workflow executions well. On GKE, scale worker pods horizontally with an HPA tied to Redis queue length.
Backup & upgrade
Enable Cloud SQL automated backups and point-in-time recovery. Upgrade n8n on Cloud Run by deploying a new revision with an updated image tag (instant rollback to the previous revision if needed).
Security checklist
- Always run behind HTTPS (Caddy/Traefik/Nginx + Let's Encrypt) — never expose port 5678 directly.
- Set a strong, permanent N8N_ENCRYPTION_KEY and back it up (losing it breaks stored credentials).
- Use Postgres, not the default SQLite, for anything beyond local testing.
- Enable N8N_BASIC_AUTH or an SSO/proxy layer if the instance is reachable from the internet.
- Restrict inbound firewall rules to 80/443 (and SSH from your IP only).
- Keep the n8n image pinned and update on a schedule instead of always using :latest in production.
Cost breakdown
- Cloud Run (light traffic)~$10–20/mo
- Cloud SQL db-f1-micro~$10–15/mo
Troubleshooting & FAQ
+Can I use SQLite instead of Postgres?
n8n defaults to SQLite, which works for testing but isn't recommended for production: no concurrent writers, harder backups, and risk of corruption under load. Use Postgres for anything real.
+My webhooks return 404 / don't trigger — why?
WEBHOOK_URL must match the public HTTPS URL exactly (including trailing slash), and the workflow must be activated (not just saved) for production webhook URLs to work.
+How do I move from Google Cloud to another host later?
Export workflows/credentials with the n8n CLI (`n8n export:workflow --all` / `export:credentials --all`) or the REST API, restore the Postgres dump on the new host, then import.
+Do I lose data if the container restarts?
No, as long as n8n_data and the Postgres volume are mounted as named Docker volumes (not ephemeral container storage), your data persists across restarts and image updates.