n8n Kubernetes Deployment per Customer: An Isolated SaaS Pattern
The n8n Helm chart can deploy the application, workers, webhook processors, and supporting Kubernetes resources. Turning that deployment into a customer-facing SaaS offering requires another layer: a repeatable way to create, configure, upgrade, suspend, and remove one isolated n8n environment per tenant. OpenTenant supplies that lifecycle layer without requiring a fork of the upstream chart.
What the n8n Helm chart already provides
The official n8n Helm chart supports two distinct operating models. Standalone mode runs a single pod with SQLite and is intended for development or smaller installations. Queue mode separates the main process from workers and optional webhook processors; it requires external PostgreSQL and Redis.
That distinction matters for a hosted product. In n8n queue mode, the main instance receives triggers, Redis holds pending execution IDs, and workers load workflow data from the database and execute jobs. The chart also exposes controls for ingress, worker scaling, KEDA, pod disruption budgets, network policies, task runners, and existing Secret references.
Those are deployment capabilities. They do not decide who owns each customer environment or how customer lifecycle events become safe infrastructure changes.
The use case: dedicated workflow automation environments
A release-per-customer model fits products that embed or resell n8n while promising stronger operational separation than a shared application instance can provide. Each customer can receive its own release, namespace, hostname, encryption key, database credentials, resource policy, and upgrade window.
This pattern is useful when customers need:
- independent workflow and credential stores;
- customer-specific domains and branding;
- separate worker capacity or webhook scaling;
- controlled plugin, task-runner, or network access;
- maintenance windows that do not affect every tenant at once;
- a clean export, suspension, and deletion boundary.
OpenTenant models those differences around the chart. The chart remains the versioned deployment template; the tenant declaration supplies customer-specific configuration and references to scoped secrets.
Reference architecture
customer record
→ validate tenant declaration
→ reserve namespace and hostname
→ resolve tenant-scoped secrets
→ install or upgrade n8n Helm release
→ verify ingress, main process, workers, and dependencies
→ record release status and revision
For queue mode, PostgreSQL and Redis are part of the operational boundary. A platform can choose dedicated services per customer, dedicated databases on shared services, or another reviewed topology. The important point is that the tenancy decision is explicit and recoverable; it is not hidden in a one-off values file.
Illustrative tenant declaration
tenant: acme
userspace:
namespace: tenant-acme-prod
domain: automations.acme.example
deployment:
engine: helm
template: n8n
release: n8n-acme
values:
mode: queue
workerReplicas: 3
secretScope: tenants/acme/n8n
This is an architectural example, not a promise of stable field names. The durable pattern is the separation of template identity, tenant configuration, secret scope, and release ownership.
Production decisions to make before onboarding customers
Database and Redis topology. Queue mode requires both. Decide whether isolation means separate service instances, separate databases and credentials, or a carefully governed shared service.
Encryption keys and credentials. Keep n8n encryption keys, database passwords, Redis credentials, and third-party connector secrets out of chart values. Resolve them from tenant-scoped secret storage and rotate them through a reviewed process.
Webhook routing. n8n supports optional webhook processors for scaling incoming production webhooks. Give each tenant hostname ownership, TLS, rate limits, and a clear route to the correct release.
Worker capacity. Set resource requests and limits, then choose HPA or KEDA based on the workload. Autoscaling configuration is not a substitute for per-tenant quotas and cost controls.
Upgrades and rollback. Pin chart and image versions. Promote a tested revision through tenant cohorts, retain the previous known-good values, and keep database compatibility in the rollback decision.
When a shared n8n instance is the better fit
Dedicated releases cost more to operate. A shared instance can be the right choice for internal automation, low-risk prototypes, or products whose users do not need infrastructure-level separation. Choose release-per-customer when isolation, independent change windows, customer-specific networking, or clean lifecycle ownership justify that overhead.
Evaluation checklist
- Can one tenant's workers exhaust another tenant's capacity?
- Are encryption keys and connector credentials scoped per tenant?
- Can a hostname resolve only to its owning release?
- Are PostgreSQL, Redis, and binary-data boundaries documented?
- Can you upgrade one customer, verify it, and stop the rollout?
- Does offboarding remove routes and runtime access before deleting retained data?
OpenTenant makes those lifecycle operations declarative while leaving n8n's own runtime and security behavior to the upstream software and the infrastructure you configure.