Tenant Onboarding and Configuration Management at Scale in n8n

Questions
1

Hello
I’m building a multi-tenant automation platform on top of n8n, and I’m trying to figure out the best way to manage tenant onboarding as the number of customers grows.
Each tenant has:
Their own API credentials
Their own WhatsApp number/instance
Custom settings and limits
Different workflow configurations
Right now, onboarding is mostly manual, which won’t scale well.
Current idea:New Tenant → Create Config → Store Credentials → Enable Workflows
I’m considering:
A centralized tenant configuration database
Automated provisioning workflows
Dynamic configuration loading based on tenant_id
Self-service onboarding portals
My goals are:
Fast onboarding
Consistent configuration
Easy credential rotation
Minimal manual work
For teams managing many tenants in n8n:
How do you automate onboarding and configuration management?
Do you keep tenant configs in a database, secret manager, or both?
Any lessons learned when scaling from a few tenants to hundreds?

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hello @Kabrooks The most scalable approach is to use a central tenant configuration database and automate onboarding as much as possible.

Common approach: New Tenant → Create Tenant Record → Store Credentials → Enable Workflows

Store things like: API keys
WhatsApp settings
Rate limits
Feature flags

under a unique tenant_id.

Best practice

Load tenant settings dynamically when workflows run instead of hardcoding values.

For sensitive data, many teams use:
Database for tenant configs
Secret manager for credentials

As you scale

Automate: Tenant creation
Credential setup
Default workflow configuration
Monitoring and alerts

This keeps onboarding fast and manageable as you grow from a few tenants to hundreds.

3

The pattern that works well at scale is a “config loader” sub-workflow: every tenant-facing workflow starts with an Execute Workflow node that calls a shared sub-workflow passing only the tenant_id. That sub-workflow fetches the full config from your DB and returns it as a structured object. All subsequent nodes reference {{ $json.config.apiKey }}, {{ $json.config.whatsappNumber }}, etc. This keeps your credential/config logic in one place and avoids duplicating fetch logic across dozens of workflows.

For credential storage specifically, keep API keys in your own DB (encrypted), not in n8n credentials - that way you can rotate them without touching n8n’s credential store, and you load them dynamically in HTTP Request node auth headers via expression.

The n8n API (POST /api/v1/workflows) also lets you automate workflow import and activation per tenant if you need per-tenant workflow isolation.

4

Hey! Great timing to think about this it’s much easier to architect this right early than to refactor at 200 tenants.

What’s worked well for others at scale:

1. Use a database as your single source of truth Store all tenant configs (settings, limits, WhatsApp instance, workflow flags) in one table. Postgres works great here. Each workflow just queries by tenant_id at runtime no hardcoding anything per tenant.

2. Keep credentials in n8n’s built-in credential store, not your DB Store sensitive API keys as n8n credentials and just save the credential ID in your tenant table. This way credential rotation is just updating one record your workflows don’t need to change at all.

3. Your onboarding workflow should do the heavy lifting When a new tenant signs up, a single webhook-triggered workflow should handle everything create the DB record, provision the WhatsApp instance, assign credentials, activate their workflows. Zero manual steps.

4. Use a “config loader” sub-workflow Build one reusable sub-workflow that takes a tenant_id and returns all their config. Every other workflow calls this first. Makes updates instant across the board.

Biggest lessons from scaling:

  • Never hardcode tenant-specific logic in workflows, it becomes unmaintainable fast

  • Add a status field to your tenant table (active/suspended/onboarding) so you can gate things cleanly

  • Log every provisioning step, debugging a failed onboarding is painful without it

What database are you currently using? Happy to help sketch out the actual workflow structure.