What n8n is and how it is licensed
n8n is a workflow automation platform. Workflows connect triggers such as webhooks, schedules and app events to nodes that call APIs, transform data, run code and drive AI agents that choose tools and call language models. Each workflow can hold credentials for the systems it touches, so an instance often has broad access across the organization.
n8n is distributed under the Sustainable Use License, which n8n describes as fair-code, with files marked .ee under the n8n Enterprise License. The source is available and self-hostable, but the Sustainable Use License is not an OSI-approved open-source license. It permits use for your own internal business purposes or for non-commercial and personal use.
n8n's license FAQ allows a consultant to charge for installing, configuring, building workflows and maintaining n8n on a client's own infrastructure, as long as the consultant does not also host it. Hosting n8n as a service where clients build workflows is not permitted. Review the license with your legal team for any use beyond internal automation.
Features that depend on a paid plan
n8n marks plan availability on each feature page. These features most often change a self-hosted design.
| Feature | Plan listed in n8n docs | Deployment effect |
|---|---|---|
| SAML single sign-on | Business and Enterprise | Without it, users sign in with accounts managed inside n8n. |
| OIDC single sign-on | Enterprise | If your identity standard is OIDC, plan for Enterprise or use SAML on Business. |
| Source control and environments | Business and Enterprise | Without it, promote workflows with CLI export and import in a reviewed pipeline. |
| External secrets | Enterprise | Pulls credentials from Vault or cloud secret managers. Without it, secrets stay encrypted in the n8n database. |
| Log streaming | Enterprise | Sends audit and workflow events to external tools. If absent, plan monitoring from application logs. |
| Multi-main high availability | Self-hosted Enterprise | Adds failover between main instances. Without it, the main instance remains a single point of failure. |
| S3 binary data storage | Business and Enterprise | n8n will not start in S3 mode without a valid license. |
Components of a scaled deployment
A single container is enough to start. Queue mode separates scheduling from execution.
Main instance
Serves the editor and API, handles timers and webhooks, and creates executions. In queue mode it does not run them.
Workers
Take executions from Redis, run them and store results. Each worker runs 10 jobs in parallel by default.
Webhook processors
Optional instances that add webhook capacity behind a load balancer. n8n advises keeping the main process out of that pool.
Redis
The queue-mode message broker, holding pending executions until a worker takes them.
PostgreSQL
Stores workflows, encrypted credentials and executions. SQLite is the default but is not supported for queue mode.
Task runners
Run Code node scripts isolated from the main process. Enabled by default since n8n 2.0.
Choose a topology
One container with PostgreSQL and persistent storage for the n8n folder, suitable for a pilot. Starting on PostgreSQL avoids a database migration when you move to queue mode.
A main instance, Redis and a pool of workers sharing one PostgreSQL database. Every worker and webhook processor needs the main instance's encryption key to read stored credentials.
Add webhook processors behind a load balancer when inbound volume is high. Expose only webhook paths externally and keep the editor on an internal network.
Load depends on execution count, payload and binary data size, Code node use, AI agent calls and saved execution data. Configure execution data pruning early to control database growth.
Harden credentials, code and AI agents
n8n 2.0 tightened several defaults: task runners isolate Code node execution, Code nodes cannot read environment variables, and the Execute Command and Local File Trigger nodes are disabled. Keep those defaults unless a reviewed workflow needs an exception, and record each exception with its owner.
Limit who can create and share credentials, scope each one to minimum permissions in the target system, and use one service account per integration so access can be revoked cleanly. Restrict outbound network access from workers to approved systems.
An AI agent that reads inbound email or web content and can call tools with stored credentials may be steered by instructions hidden in that content. Limit each agent's tools, require human approval for actions with side effects, and test agent workflows for prompt injection before production. DeployOpen's AI and LLM security testing can cover these workflows.
Community nodes install third-party packages, so approve and pin them like any code dependency. Connect sign-in to your identity provider where the plan includes SSO, and otherwise run a documented joiner and leaver process.
Back up the encryption key with the data
Stored credentials are only usable with the encryption key that protected them.
| Item | Why it matters | Practice |
|---|---|---|
| Encryption key | n8n encrypts credentials with it. If N8N_ENCRYPTION_KEY is unset, n8n generates a key on first launch and stores it in the .n8n folder. | Set it explicitly, keep it in a secret manager and back it up apart from the database. |
| PostgreSQL | Holds workflows, credentials, users and executions. | Back up on a schedule and test restores with the same key. |
| CLI exports | Workflows and credentials can be exported to files. | Use the backup flag for routine copies. A decrypted export exposes every secret, so restrict and delete it. |
| Binary data and configuration | Files handled by workflows, plus environment, Compose or Helm settings. | Back up the binary data volume or bucket, and keep configuration in version control. |
Upgrade with breaking changes in view
n8n uses semantic versioning and releases often. Major releases can require action: 2.0 dropped MySQL and MariaDB as storage backends, so those instances must migrate to PostgreSQL or SQLite first, and Code nodes that relied on environment variables may need changes.
Test upgrades on a staging instance restored from production with the same encryption key, including workflows that use Code nodes, AI agents and community nodes. Upgrade main, workers and webhook processors together, and keep the previous image tag and a database backup for rollback.
n8n operating ownership
The platform team runs n8n. Workflow owners answer for what each workflow does with the access it holds.
Platform team
- Run main, workers, Redis and PostgreSQL.
- Monitor queue depth, failures and database growth.
- Test upgrades and restores with the production key.
Workflow owners
- Name an owner and purpose for each workflow.
- Handle failed executions.
- Retire unused workflows and credentials.
Security
- Hold and back up the encryption key.
- Approve credentials, community nodes and agent tools.
- Review egress and exposed webhook paths.
License and change record
- Record the license and plan in use.
- Keep configuration and exports in version control.
- Log each upgrade and the workflows tested.
n8n deployment questions
Is n8n open source?
Its source is public and self-hostable, but the Sustainable Use License is not OSI-approved. n8n calls it fair-code. It allows internal business use and restricts offering n8n to others as a hosted service.
Can DeployOpen install n8n for us?
Yes, on your own servers or cloud account. n8n's license FAQ allows consultants to install, configure and maintain n8n on client infrastructure, provided they do not also host it. You own the instance and any n8n license.
What if we lose the encryption key?
Stored credentials cannot be decrypted, so every credential would need to be re-entered. Back the key up before the first credential is created.
Do we need queue mode?
Not for a pilot. Move to it when executions compete for capacity or workers need to scale independently. It requires PostgreSQL and Redis.
Scope and handover
DeployOpen installs and configures n8n on infrastructure you own, consistent with n8n's license terms for consultants. We design the topology, set up PostgreSQL, Redis and queue mode where needed, integrate SSO when your plan includes it, harden credentials, code execution and network paths, and set up backups that cover the encryption key as well as the data. We document the platform, plan and test upgrades, and can provide ongoing support.
Handover includes topology and sizing notes, configuration in version control, the encryption key escrow procedure, the license record, a credential and community node inventory, restore test results, the current version and named owners for each operating area.
