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.

[rgrzesk]

Thank you @datawranglerai for your answers :)

I am just about during a scripted setup of db for N8N, as I said - it's a shared DB, I was hoping that creating the schema before N8N starts would let me limit privileges for n8n user even more. That was a wrong assumption. I was trying different privileges and it turned out that the user has to have CREATE permission on the DB in order to proceed. If not, the service doesn't start and throws permission denied. I described it here quite well: https://community.n8n.io/t/postgresql-missing-permissions-for-creating-schema/179912

I hope that N8N might treat that as a feature request to always check if a schema exists before trying to create a new one. Otherwise, I find it quite insecure.

[rgrzesk]

Thank you @datawranglerai for your response! Really appreciate that :)

I am currently moving a step forward, and I will be setting up N8N under the same HTTPS Load Balancer as we keep the application. However, I have some questions about the security. Did you set up WAF with CloudArmor for that purpose? If it's so, can you suggest any rules that are a must or good for N8N?
So far, I have been thinking about a few:

• rate limiting to prevent brute forcing
• some API endpoint protections (which ones? login - to prevent brute forcing)
• core web vulnerabilities (SQL Injection, XSS, etc.)
• vulnerability scanner blocking

Thank you!

[datawranglerai]

Any time 🤠.

Great questions, you're definitely thinking along the right lines. I haven't gone this far myself, but if it were me, here's what I'd be thinking:

1. Start with managed WAF rules like CA's preconfigured OWASP Core Rule Set (CRS)

2. Tiered rate limiting with different requests/min limits for. E.g. fewer requests/min for the login page, higher for webhook endpoints.

3. Custom protection rules for n8n's critical paths like /auth/login, /webhook, oauth...

4. Enable CA's bot management

5. Implement IAP for admin access to UI (can be a headache to setup in my experience but worth it)

That I guess that'd filter out 95% of garbage traffic without breaking legitimate users. Then I'd keep an eye on the logs and tune it from there.