Workflow automation in SaaS products

The Sustainable Use License does not cover building n8n into a product that you sell to customers. Under the license, n8n may be used or modified only for your own internal business purposes or for non-commercial or personal use, and distributed only free of charge for non-commercial purposes. A workflow engine that runs inside a paid feature, processes customer data on your behalf, or is exposed to tenants is hard to describe as internal use. Before any design work starts, ask counsel to read the full n8n LICENSE.md against your intended architecture, including whether customers trigger workflows, see the editor, or receive a copy of the runtime. Expect the answer to point toward a commercial agreement with n8n rather than a self-service path.

The second issue is edition scope. Files marked .ee are not covered by the Sustainable Use License and require a valid n8n Enterprise License, so a feature that depends on them needs that license as well. The n8n pricing page states that SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and that multi-main high availability is limited to Enterprise self-hosted deployments. If your product promises tenant SSO, staged promotion of customer-facing flows, or high availability, confirm which plan or agreement provides each feature in writing. Also note that n8n counts an execution as one run of a whole workflow, so usage-based commitments should be modeled against that definition, not against individual steps.

Treat the terms as a moving target. Verify the current license text, pricing and plan feature lists directly with n8n and with your counsel at the time of decision, because the research behind this page is not a legal opinion and terms can change between releases. Record the answer in your architecture decision log, including which features you depend on and which license tier covers them. If the review concludes that a commercial agreement is needed, compare that cost with an engine whose license permits distribution, such as Node-RED under Apache-2.0 or Temporal under MIT, before committing the product roadmap to n8n.

The core decision is whether tenants share a worker pool with logical isolation or get dedicated pools. A shared pool with namespace isolation is cheaper to run and simpler to operate, but every tenant's executions pass through the same processes, queues and databases. A dedicated pool for large tenants costs more to run and to monitor, yet it keeps their execution data, scaling and failure domains separate. Most SaaS teams settle on a shared pool for smaller tenants and dedicated pools for the few that have contractual isolation requirements or heavy volumes. Confirm the threshold and the contract terms that trigger a move before writing the architecture.

In n8n queue mode, the main instance hands executions through Redis to workers that read and write PostgreSQL, and the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt stored credentials. That means a single encryption key covers credentials for all tenants that share the pool, so per-tenant credential isolation depends on separate deployments, not on workflow permissions. Temporal takes a different route: a namespace separates workflow executions, and the ClaimMapper maps JWT or certificate claims to namespace roles, while the Authorizer decides what each caller may do. Temporal's default noopAuthorizer allows every API request, so an unconfigured tenant boundary is open to all callers. Test that the Authorizer denies cross-namespace calls before any tenant goes live.

Whichever pool model you choose, run the Temporal services on hosts not reachable from the public internet, and enable mTLS for both internode and frontend traffic so workers and clients authenticate each other. Ask your engineering team which per-tenant metrics exist (queue depth, execution counts, failure rates, storage size), how long execution history and payloads are retained per tenant, and whether payload encryption codecs can be applied per namespace. Those answers determine whether a shared pool can meet a tenant's data-handling terms, so get them in writing before you size the pool.

Start with the license question, because it decides whether the rest of the conversation matters. Ask the partner to put in writing how the chosen tool's license applies to your use: n8n's Sustainable Use License permits use for your own internal business purposes or non-commercial use, and files with .ee in their name or directory need an n8n Enterprise License. If the automation runs as a feature your customers operate or pay for, a fair-code tool may not be the right base. Ask for a written license review that covers the exact edition and every directory in the build, and ask who re-runs that review when the vendor changes its terms. Compare this with Node-RED, which is Apache-2.0, and Temporal, which is MIT licensed according to its repository. Confirm the license of every custom node and connector too, since those carry their own terms.

Next, ask how authorization is set up on the Temporal server. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. A customer-facing platform cannot ship with that default. Ask the partner to show the ClaimMapper that maps JWT or certificate claims to namespace roles, the Authorizer plugin that enforces them, and the mTLS settings for frontend and internode traffic. Ask how each tenant maps to a namespace and who approves role changes. Also ask how tenant credentials and encryption keys are isolated: in n8n queue mode the main instance's encryption key must be shared with every worker and webhook processor, so a single key across tenants becomes a single point of exposure. Ask whether each tenant or tenant group gets its own key, where keys are stored, and how payload codecs and the codec server are scoped.

Finally, ask how upgrades and plan features are handled. Temporal guarantees backward compatibility only between successive minor versions, so ask the partner to describe how they move one minor version at a time, which schema upgrades run first, and how they test each step against the current patch release before production. For n8n, ask for a written list of which features each plan includes, such as SSO and LDAP, environments with Git, and log streaming, and confirm that multi-main high availability requires an Enterprise self-hosted deployment. Last, ask who maintains custom nodes after handover: who owns the code, who patches it when the upstream API changes, and what happens to customer flows when the original author leaves.