GKE, CR, Scaling, etc.

[rgrzesk]

Hi! Thanks for publishing this Cloud Run guide for n8n — it’s very useful.

I’m evaluating options for running n8n on GCP and have a few questions based on your approach:

1. Cloud Run vs GKE

• Why did you choose Cloud Run for n8n over GKE?
• Have you encountered specific limits or pitfalls with Cloud Run (concurrency, request timeouts, CPU/memory limits, VPC connectivity to Cloud SQL) that would make GKE preferable?

2. Scaling for multiple customers/tenants

• How would you scale from one deployment to multiple customers with different integrations?
• Would you keep a shared Cloud Run service with tenant routing, or create a separate service per customer?
• Any tips for webhook routing, per-customer secrets/service accounts, and when to split web and worker services?

3. Database isolation

• Is it reasonable to share the same Cloud SQL Postgres used by the main application, or would you recommend a dedicated Postgres instance for n8n?
• If sharing, would you isolate by schema per environment/customer?
• Any advice on least-privilege permissions for the n8n DB user, and on avoiding connection/backup conflicts when sharing?

Thanks in advance for your insights — any practical tips or gotchas from your experience would be greatly appreciated.

[datawranglerai]

Hey @rgrzesk, you're very welcome! Appreciate the thoughtful questions. Here's my take from what I know about GCP architecture:

1. Why I chose GCR vs GKE

Mainly due to simplicity and cost. Meaning I don't have to manage clusters, node pools, etc. Also, I can scale GCR to zero while GKE charges per VM.

GCR works for my purposes, but I would probably need to think about GKE if I had more complex networking requirements, needs for stateful workloads or more persistent storage or something. Otherwise, you can have up to 1,000 concurrent requests per instance on GCR, and request timeouts go up to 60 minutes usually.

2. Scaling for multi-tenant setups

Would probably use a hybrid approach. I'd probably opt for a separate GCR service per customer for isolation and security. But I'd use shared infra components like Artifact Registry, monitoring etc. In terms of tenant-specific routing I'd use Cloud Load Balancer.

For tenant routing, use Cloud Load Balancer or a lightweight routing service that forwards webhooks to tenant-specific endpoints. Queue mode with Redis/Memorystore really shines for high-volume setups by splitting main and worker instances, scaling like a champ — but it adds cost and complexity.

3. Database isolation

A shared Cloud SQL instance with schema-level separation hits a sweet spot between cost and security. If you have high-security or mega tenants, dedicated Cloud SQL instances make sense.

I love a bit of PoLP. Least privilege is key. Give tenants minimal permissions scoped to their schema, revoke global powers. Something like:

Maybe something like:

-- Minimal n8n database user permissions
CREATE USER 'n8n_tenant'@'%' IDENTIFIED BY 'secure_password';

-- Grant only necessary permissions
GRANT SELECT, INSERT, UPDATE, DELETE ON tenant_schema.* TO 'n8n_tenant'@'%';
GRANT CREATE, DROP, INDEX, ALTER ON tenant_schema.* TO 'n8n_tenant'@'%';

-- Explicitly deny global permissions
REVOKE PROCESS, SUPER, RELOAD ON *.* FROM 'n8n_tenant'@'%';

Hope this helps answer your questions! Keen to hear from others in the community about how they'd tackle these things.