Shuffle vs n8n licensing: which license fits a security team or MSSP
If your security team or MSSP is choosing a self-hosted automation platform, the license decides more than the feature list does. Shuffle is licensed under AGPL-3.0, with workflows and modular app content under MIT, while n8n is distributed under the Sustainable Use License, which is not an OSI-approved license. That license allows use or modification only for your own internal business purposes or for non-commercial or personal use, and files marked .ee fall under a separate n8n Enterprise License. Whether n8n is ruled out depends on how you plan to use it: running automation only for your own security operations is one case, while operating it as a service for clients is another.
Start by sorting your plan into one of three buckets. If the platform will only automate your own internal security work, the Sustainable Use License's internal business purpose language may fit, but you should still confirm that your intended use, including any shared or group-wide deployments, sits inside it. If you plan to modify the code, the AGPL-3.0 terms on Shuffle require you to meet source availability obligations for modified versions you run for users over a network, so your engineers should review those terms before any fork. If you intend to run the platform for client organizations, the n8n terms are the first place to look, because providing it as a managed service for others is not the internal use the license describes.
Because these license terms interact with contracts, data processing agreements and your own sourcing policy, have qualified legal counsel review the exact license text, the n8n plan you would buy, and the Shuffle edition you would run before you commit. Confirm with each vendor, in writing, how their terms apply to an MSSP model. Also note that n8n's paid features such as SAML and LDAP single sign-on are tied to Business or Enterprise licensing, which changes the cost picture even where the license allows your use. Shuffle's GitHub repository and n8n's LICENSE.md are the primary texts to bring to that review.
How the license terms compare part by part
This table sets Shuffle's AGPL-3.0 terms against n8n's Sustainable Use License row by row, so you can see which permitted uses change the answer for your team. Read each row against your own use case, especially internal security operations versus services delivered to clients. The main takeaway is that the two licenses differ most on use for client or MSSP services and on enterprise-marked files.
| Term | Shuffle | n8n |
|---|---|---|
| Base license | AGPL-3.0 | Sustainable Use License (fair-code) |
| OSI-approved open source | Yes, AGPL-3.0 is an OSI-approved license | No, not an OSI-approved license |
| Workflow and app content license | Workflows and modular app content are MIT | Not separately licensed; covered by the base license terms |
| Permitted internal business use | Yes, under AGPL-3.0 terms | Yes, for your own internal business purposes |
| Permitted use for clients or MSSP services | Permitted under AGPL-3.0 terms; network-facing modifications carry source obligations (confirm with counsel) | Not covered by internal business or non-commercial use; confirm with n8n before offering client-facing services |
| Distribution | Permitted under AGPL-3.0 with source obligations | Only free of charge and for non-commercial purposes |
| Enterprise-marked files | Shuffle edition limits are enforced since v2.1.1, separate from the AGPL code | Files marked .ee require a valid n8n Enterprise License |
| Current release | Shuffle 2.3.0 (September 28, 2026) | n8n 2.43.7 (October 16, 2026) |
What AGPL-3.0 obligations mean for Shuffle users
AGPL-3.0 is a copyleft license that follows the software across a network. A team that runs Shuffle inside its own environment for its own security operations can use it without publishing anything, because running the code internally is not distribution. The obligations begin when you modify Shuffle or offer it to people outside your organization over a network, such as an MSSP giving customers access to a hosted instance. In those cases, the license requires that users interacting with the modified program over the network can receive the corresponding source code, including your changes. Keep a record of every modification you make to the Shuffle code, and do not treat internal patches as private by default. Confirm with your counsel which of your planned uses trigger these terms, because the answer depends on how users reach the service.
Shuffle's workflows and modular app content are licensed under MIT, according to the LICENSE file and README in the Shuffle GitHub repository, which is a different and more permissive regime than the AGPL-3.0 code. In practice, this means a playbook or app module you write can usually be reused, shared or adapted under MIT terms, while changes to the Shuffle platform itself carry the copyleft obligations. Check the license of each artifact before you move it between environments or contribute it to a partner, and keep your own internal runbooks and case-specific logic separate from anything you intend to distribute. Confirm the exact file-level license boundaries with the Shuffle GitHub repository before you build a reuse policy around them.
Shuffle's paid Business and Enterprise licenses are a separate commercial matter, governed by their own terms rather than by the open-source license alone. Shuffle says all features are available in the open-source edition and that paid tiers differ in limits, scaling and support, so a license decision should not be treated as a substitute for an AGPL review. Ask counsel to confirm how AGPL-3.0 applies to your specific deployment, including whether an MSSP hosting model, a customer-facing portal or a hybrid runner changes your obligations. Written answers from counsel should be kept with your architecture records, because they will be the reference point when auditors or customers ask how the platform is licensed.
Which license facts change the decision
Shuffle and n8n sit under different license families, and the difference only matters once you know how the platform will be used. The cards below list the factors that most often change the result, each with the check to run before you commit.
Internal-only or client-facing use
n8n's Sustainable Use License permits use only for your own internal business purposes or for non-commercial or personal use. If you run n8n to deliver security monitoring or response to customers, you need to check whether that service falls outside the internal-use grant. Shuffle's AGPL-3.0 does not restrict who the platform serves, so an MSSP can operate it for several clients. Ask counsel to review your service model against the n8n license text before you assume either way.
Modifying or redistributing the code
Under AGPL-3.0, if you modify Shuffle and make the modified version available to users over a network, you must offer those users the corresponding source code. Distributing copies to third parties triggers similar obligations. n8n's license also limits modification and distribution to free-of-charge, non-commercial cases. Map which of your planned changes, such as custom apps or forks shared with a partner, would create a source disclosure duty under each license.
Reliance on .ee-marked files
Files with .ee in their name or directory fall outside n8n's Sustainable Use License and need a valid n8n Enterprise License. If your team copies code from the n8n repository into internal tooling, check paths for .ee before reuse. Shuffle's open-source edition is described as offering all features, with limits enforced between editions since v2.1.1, so the license question is about enforced limits rather than hidden code paths. Confirm the exact file set you intend to use.
SSO, LDAP and multi-main needs in n8n
In n8n, SAML and LDAP single sign-on, multi-main mode, environments, external secrets, log streaming and Git version control need a paid Business or Enterprise license. Multi-main high availability is restricted to Enterprise self-hosted deployments. If your identity policy requires SSO or your uptime design needs several main instances, the license tier is a requirement, not an option. Add the tier cost to the comparison before you treat the Community edition as free for your use case.
Reuse of MIT workflow content
Shuffle states that its workflows and modular app content are MIT-licensed, while the platform code is AGPL-3.0. That split lets your team reuse shared playbooks and app content under permissive terms, separately from the platform obligations. Check the LICENSE file and README of the specific repository you copy from, since the license applies to the content, not automatically to every file in the project.
OSI-approved license in procurement policy
n8n's Sustainable Use License is not an OSI-approved license. If your procurement or open-source policy accepts only OSI-approved licenses, n8n may fail that gate regardless of how you use it. Shuffle's AGPL-3.0 is a standard open-source license. Put the policy wording to your legal and procurement team early, and ask them to confirm how a fair-code license is classified under it.
How each license fits an internal team versus an MSSP
An internal security team automating its own organization is the case the license terms address most directly. The main question is whether every workflow serves your own internal business purposes and whether you control the deployment. For n8n, the Sustainable Use License permits use or modification for internal business purposes or for non-commercial or personal use, which covers a SOC automating its own alert triage and ticketing.
- Internal use in n8n: Automating your own alerts, tickets and enrichment fits the internal business purpose wording. Confirm that no workflow is run for third parties.
- Shuffle under AGPL-3.0: Running Shuffle unmodified for your own SOC creates no source-sharing step. Modifications that you make available to others over a network bring AGPL obligations into play.
- Enterprise files in n8n: Files marked
.eerequire a valid n8n Enterprise License even for internal use, so check which features your design depends on. - Edition limits in Shuffle: All features are available in the open-source edition, but limits between editions are enforced since v2.1.1. Compare your expected app runs against the Shuffle pricing article.
Check whether your planned use is internal under the exact license wording, and confirm with the vendor which edition limits apply to your run volume.
An MSSP runs the same platform for several client organizations, so the license must cover use on behalf of others. This is where n8n's terms are most restrictive. Its Sustainable Use License limits use to your own internal business purposes or to non-commercial or personal use, and it does not describe a managed service provider case. Shuffle's AGPL-3.0 terms are built around modification and network use rather than internal use, so the review focuses on how your client-facing changes and portals are treated.
- n8n service delivery: Running client automation as a paid service is a use your counsel must review against the internal business purpose wording before any onboarding.
- n8n pricing unit: n8n counts an execution as one run of a whole workflow and lists unlimited users on all plans. That affects cost planning but does not answer the license question.
- Shuffle client-facing changes: AGPL-3.0 obligations attach to modifications and network interaction. Document every change you make to Shuffle and how clients reach it.
- Tenant and run limits: Shuffle's paid editions differ in feature limits and tenant handling. Ask the vendor how tenant counts and per-tenant SSO apply to your model before sizing it.
Check for written counsel advice on service-provider use under both licenses, and get vendor confirmation of tenant and run limits for the edition you would license.
A software vendor that embeds a platform in its own product is distributing or redistributing it, which moves the question from internal use to distribution terms. Here the licenses diverge sharply. n8n's Sustainable Use License allows distribution only free of charge and only for non-commercial purposes, so embedding n8n in a commercial product falls outside the license. Shuffle's AGPL-3.0 instead sets conditions on how modified versions are distributed and shared, which means the architecture of your product matters as much as the license text.
- n8n in a commercial product: Distribution is limited to non-commercial use under the Sustainable Use License, so a commercial embed needs a separate agreement with n8n before any planning.
- Shuffle copyleft obligations: Distributed modified versions must carry source under the same license. Any proprietary code linked into the product needs counsel review of how the combined work is treated.
- Shuffle workflow and app content: Workflows and modular app content are MIT, which is more permissive than the core code. Confirm exactly which components your product would ship.
- Branding and white-labeling: Shuffle's enterprise limits include branding, so any white-label plan requires written vendor confirmation.
- Support commitments: n8n's Enterprise plan includes dedicated support with an SLA. If you resell, confirm what support your customers receive and who provides it.
Check for a written distribution or OEM position from each vendor, plus counsel's review of how AGPL-3.0 applies to your product's architecture.
How to confirm the license fit before you commit
This sequence turns the license question into a documented decision: which uses you plan, which license clause each one falls under, which n8n features you need, and whether any .ee files come into your build. It ends with a record your counsel can review against the actual model.
List every planned use of the platform
The platform owner, security lead and a delegate from legal or procurement write down each way the automation will be used. Separate internal use by your own security operations team, use for client or customer work such as running automation for other organizations, and any case where you would ship a workflow or product that embeds the platform. Record who operates it, who receives output, and whether any third party touches the running system. The step is done when every use has a one-line description and an owner, and the list is signed off by the people who will run it.
Map each use to the license clause
For each use on the list, the legal reviewer reads the LICENSE file for the candidate platform and notes the clause that governs it. For Shuffle, that is the AGPL-3.0 terms for the code, with workflows and modular app content under MIT, so the reviewer also notes which artifacts carry which license. For n8n, the reviewer checks the Sustainable Use License terms for internal business use, non-commercial use and free distribution, and notes any use that falls outside them. The output is a table with one row per use, the governing clause, and a clear yes, no or needs-counsel mark. A use marked no or needs-counsel moves to the next decision point.
Check required features against paid tiers
The platform owner lists the features the team needs, such as single sign-on through SAML or LDAP, multi-main high availability, environments, external secrets, log streaming and Git version control. For n8n, compare that list against the n8n documentation, which places several of these in the paid Business or Enterprise license. For Shuffle, compare against its edition documentation, since it states that feature sets are the same in open source while limits differ. The check is complete when each required feature has a named edition and a source, and any feature that needs a paid tier has a written entry in the decision record.
Identify any .ee files in the planned build
The engineer responsible for the build inspects the planned n8n deployment and any custom code, and lists every file or directory with .ee in its name or path. The n8n LICENSE.md states that these files are not covered by the Sustainable Use License and require a valid n8n Enterprise License. The engineer confirms whether the build contains any of them, whether a paid license key is planned, and whether any custom node or fork pulls them in. The step is done when the list is empty or every entry is tied to a license the organization holds, and the result is attached to the decision record.
Ask counsel to review the model against both licenses
Send the use list, the clause mapping, the feature check and the .ee inventory to counsel. Ask counsel to review the AGPL-3.0 obligations that would apply to Shuffle if the organization modifies it or offers it to users over a network, and the Sustainable Use License limits on internal business use and free distribution for n8n. Ask specifically whether client-facing managed services, embedded use and hybrid deployments fall inside each license. Counsel's written answer, or a documented decision to proceed without it, closes this step. DeployOpen does not give legal advice, so the review must come from the organization's own counsel.
Document the decision and the conditions attached to it
The platform owner writes a decision record that states the chosen platform, the uses it covers, the license clauses relied on, the paid features and any .ee components, and the open conditions counsel set. The record also names the owner who will re-check it when the use changes, such as a new client service, a new embedded component or a move to a different license tier. Store it with the architecture documentation and the procurement file. The step is done when the record is approved by the accountable executive and linked from the implementation plan.
Confirm the scope in a written quote
Before work starts, share the decision record with the implementation partner so the fixed-scope agreement reflects the chosen license model, the features in scope and the artifacts to be delivered. Ask the partner to state in writing which licensing questions are outside its scope, and which items depend on your counsel's answer. This keeps the quote tied to a confirmed license position rather than an assumption. The step is complete when the signed scope references the decision record and no open license question is left unassigned.
Licensing questions security teams ask before choosing
Is Shuffle's AGPL-3.0 license more restrictive than n8n's license?
Shuffle's AGPL-3.0 is the more open of the two for internal and service use, because it is an OSI-approved copyleft license that does not limit who can run the software or for what purpose. Its obligations apply when you modify the code and distribute it or offer it to users over a network, in which case you must make your changes available under the same terms. Shuffle's workflows and modular app content are MIT, which is a simpler permissive license. n8n's Sustainable Use License limits use to your own internal business purposes or non-commercial use, and files marked .ee need a separate Enterprise License. Read the n8n LICENSE.md and have counsel confirm how the AGPL network clause applies to your planned modifications.
Can an MSSP run n8n to deliver security services to its clients?
Under the Sustainable Use License, an MSSP running n8n to deliver services to client organizations is outside the stated permitted uses, because those uses cover your own internal business or non-commercial and personal use. Distribution is allowed only free of charge for non-commercial purposes. This makes n8n a poor fit for a managed service model unless n8n grants a separate commercial agreement, which you should request in writing before building any client workflows. Shuffle's AGPL-3.0 does not restrict service delivery in the same way, though you should still confirm your obligations for any modified code with counsel. For an illustrative case, an MSSP that hosts one shared n8n instance for twenty clients would need that written permission before go-live.
What do paid n8n Business and Enterprise plans add for SSO and multi-main?
Without a license key, n8n runs as the free Community edition. SAML and LDAP single sign-on, multi-main mode, environments, external secrets, log streaming, Git version control and projects require a paid Business or Enterprise license. SAML single sign-on is available on the Business and Enterprise plans, with setup guides for Okta Workforce Identity and Azure AD. Multi-main setup, which runs several main instances for high availability, is restricted to Enterprise self-hosted deployments and is not available in the Community edition. For a security team, this means SSO and high availability both depend on a paid tier. Confirm the current feature split on the n8n editions page before you commit.
Does Shuffle licensing cost more than n8n?
The published prices do not allow a direct comparison, because the two vendors meter differently. n8n's pricing page lists a free self-hosted Community edition, Starter and Pro cloud plans at 20 euros and 50 euros per month billed annually, and a Business plan at 667 euros per month billed annually that is currently self-hosted only. Enterprise is custom priced. n8n counts an execution as one run of a whole workflow. Shuffle prices on app runs, meaning actions that execute in a workflow, and states that users, apps and workflows are unlimited. Shuffle's open-source edition includes all features, while its paid tiers differ in feature limits, scaling and support. Ask Shuffle for a quote based on your expected app run volume, and compare the two quotes against your own execution counts.
How much does legal license review cost, and who should do it?
No supplied fact gives a price or duration for license review, so treat any figure you hear as a quote to verify. Your in-house counsel or outside technology counsel should review the license text, and the review cost depends on how much of the question they can answer from the text and how much needs a vendor response. Ask counsel to cover three points: whether AGPL-3.0 obligations change if you modify Shuffle's code, whether your MSSP or client delivery model fits n8n's internal business use wording, and which terms apply to any .ee files you would use. Get vendor answers in writing, because a verbal assurance from a sales contact does not bind either vendor.
Can DeployOpen help evaluate and implement either platform within a written scope?
Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including security automation platforms. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. An evaluation scope could cover license terms with your counsel, a proof of concept on your own infrastructure, and a documented decision record. DeployOpen does not provide legal advice on license terms, so you should keep counsel in the loop for that part.
What switching later costs if the license changes
Switching later is expensive because workflows do not move between Shuffle and n8n without rework. Each platform stores its automations in its own data model, and the connections, triggers and app steps are tied to that platform's integrations. Shuffle apps are built from OpenAPI specifications or written with the Shuffle app SDK and run as versioned Docker containers, while n8n nodes are built on n8n's own integration model. Expect to rebuild and retest each workflow on the new platform, and plan for the hours that work takes across your playbook library. Ask each vendor, and your own engineers, to inventory how many workflows, custom apps and scripts you would have to rebuild.
The license terms decide what you may carry. Shuffle's code is under AGPL-3.0, while its workflows and modular app content are MIT, so your own workflows and apps can be exported, reused and reworked under permissive terms. n8n is under the Sustainable Use License, which permits use or modification only for internal business purposes or non-commercial or personal use, and files marked .ee need a valid Enterprise License. Before you copy n8n workflows or custom nodes into another product, have counsel confirm what the Sustainable Use License allows for your use case, especially if any of that content is shared with a client or another organization.
Credentials and encryption keys need a written handling plan before any migration. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the Shuffle docs warn that losing or changing it breaks all saved app authentications. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials. Decide who holds each key, record it in your secrets store, and plan to re-enter or re-authorize every credential on the target platform, since encrypted values do not carry over. Confirm these handling steps with each vendor's current documentation before you commit.
How DeployOpen helps evaluate and implement Shuffle
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so the license question becomes a concrete design question for your environment. We start from the written scope, test the setup you actually plan to run, and document what your legal and procurement teams need to confirm.
How we scope
- Written scope agreed before work starts, covering which teams, tenants and MSSP customers the Shuffle deployment will serve.
- Review of how Shuffle's AGPL-3.0 obligations and n8n's Sustainable Use License apply to your planned use, flagged for counsel to confirm.
- Inventory of the SSO, scaling and credential-handling requirements that would decide between the two platforms in your environment.
How we build
- Deployment of Shuffle in your cloud account, data center or air-gapped network, with the architecture chosen to match the scope.
- Configuration of SSO, the encryption secret for saved app credentials and the high availability settings the scope requires.
- Testing of workflows and app integrations against the security tools your team relies on, with results recorded against the agreed scope.
How we hand over
- Written documentation of the deployment, configuration decisions and license assumptions for your records.
- Runbooks covering backup, restore and the handling of the encryption secret, which must not be changed without a plan.
- Handover session with your platform, security and procurement owners so each can check the deliverables against the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped in writing.
- Upgrade planning that checks each Shuffle release and any license change against your documented assumptions before you adopt it.
- Ask us to confirm current terms, editions and feature limits with the vendors before any purchase decision is made.
