When the open-source edition is enough and when a Shuffle license is needed
A security team deciding whether the AGPL edition can carry its SOAR workload should know that every feature is the same across tiers. Shuffle states that all features are included in all tiers, and the differences are enforced feature limits, scaling and support. That makes the decision a question of volume, topology and service obligations, not of capability. The open-source edition hard-limits app runs to 25k, allows 3 tenants and 1 location, offers no branding and no high availability. Business and Enterprise licenses lift those limits and add SLA-backed support and onboarding. The free edition suits a single team running a modest number of executed actions from one location, where a workflow outage for a short period is tolerable and no tenant separation is needed. It is also the better choice for a lab, a proof of concept, or a CERT that wants to evaluate the full feature set before committing budget, because nothing is gated during evaluation. Confirm the current app-run count against the 25k hard limit with a representative week of playbooks, since app runs count only actions that actually execute, not triggers or skipped steps. A paid license becomes necessary when you run several tenants or locations, need high availability with more than one Orborus node and a scaled backend, want custom branding for a managed service, or require a response-time commitment from the vendor. Ask the Shuffle sales team to confirm in writing which license tier covers your app-run forecast, how the 3-use-case onboarding in Business compares with unlimited use cases in Enterprise, and whether on-premises license files are delivered through the worker download process described in the configuration docs.
Which limits and features differ between the editions
This table compares Shuffle's open-source edition with the Business and Enterprise licenses on the limits that are enforced and the features that are common to all tiers. Read the limit rows as the points that can change your operating model, and the feature rows as the reason the license choice is about scale and support rather than capability.
| Area | Open-source edition | Business and Enterprise licenses |
|---|---|---|
| Feature set | Same features as paid tiers, per Shuffle's open-source article | Same features as the open-source edition, per Shuffle's open-source article |
| App runs | Hard limit of 25k app runs | Soft limit of 300k+ app runs, per Shuffle's tier chart |
| Tenants | 3 tenants | Unlimited tenants |
| Locations | 1 location | Unlimited locations |
| Branding | No branding option | Branding available, per Shuffle's tier chart |
| High availability | Not included in the open-source tier | Included in paid tiers, per Shuffle's tier chart; confirm the exact HA scope with Shuffle |
| Enforcement | Limits enforced from v2.1.1 onward | Limits enforced from v2.1.1 onward; support for versions before v2.1.1 ended January 31, 2026 |
| Support and onboarding | Community support only; confirm channels with Shuffle | Business: email support with 24-hour SLA and onboarding for 3 use cases; Enterprise: on-call support, alert mechanism, professional services and unlimited use case onboarding |
How licensing, support and updates differ by edition
Shuffle ships the same feature set in every tier, so the differences sit in enforced limits, support commitments and how you receive updates. Read each card with the question your operations team will face first: what runs out, who answers the phone, and which version you can still get fixes for.
AGPL-3.0 open-source edition
The platform code is licensed under AGPL-3.0, while workflows and modular app content are MIT. Shuffle states it is built on the AGPLv3 and has no plans to close-source the platform. For operations, the open-source edition carries a hard limit of 25k app runs, 3 tenants, 1 location, no branding and no high availability. Check whether those limits fit your expected execution volume before you deploy, and confirm with Shuffle how the AGPL source obligations apply if you modify the code.
Business license support
The Business license adds email support with a 24-hour SLA and onboarding that covers 3 use cases. The limit moves to a soft limit of 300k+ app runs, with unlimited product limits. Ask for the written SLA definition, including what counts as a response and how severity is set. Plan internally for onboarding scope, because a team with more than three use cases will need to decide which ones go first.
Enterprise license support and services
The Enterprise license adds on-call support, an alert mechanism, professional services and onboarding covering unlimited use cases. This suits teams that run SOAR as a service for a SOC on a night and weekend rota. Confirm the on-call hours, escalation path and whether professional services are included in the license price or billed separately, and get those terms in writing before you sign.
Version enforcement and older releases
From v2.1.1 onward, Shuffle actively enforces the differences between the open-source and Enterprise editions, so limits apply at runtime. Support for versions older than v2.1.1 ended on January 31, 2026. Current release is v2.3.0, published September 28, 2026. Keep the platform on a supported line, and test upgrades in a staging environment before you move production.
Docker tags and licensed worker delivery
The docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so pin a specific version in production rather than following nightly. On premises, a licensed customer receives a URL to download the licensed worker, which is loaded with docker load. Confirm the download URL, the delivery process for each new worker build, and who in your organization is authorized to receive it.
What the free edition is missing for typical enterprise needs
The gaps that matter are the ones your organization's structure creates, because every tier ships the same feature set. Start with separation. The open-source edition allows 3 tenants and 1 location, and since v2.1.1 those limits are actively enforced. An MSSP onboarding more than three customers, or a bank splitting SOC work across business units and regions, can reach the tenant or location ceiling quickly. Branding is the other gap: the free edition has no branding, so a managed service that presents Shuffle under its own name should confirm what the Business or Enterprise license permits. Ask Shuffle to explain in writing how tenants and locations are counted before you design your tenancy model.
High availability is the gap most likely to decide the question. Shuffle's tier chart lists no high availability for the open-source edition, so a team that needs HA must plan for a paid license or get the HA terms confirmed in writing before design work starts. The Shuffle configuration docs describe the HA pattern: an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, backend and frontend scaled across servers, and more than one Orborus node so executions continue if one fails. Each element is infrastructure you run and staff, whichever license you hold. The license fee and the labor to build and operate that cluster are separate budget lines, so ask for both in any quote.
Support and onboarding are bought separately. According to Shuffle's tier chart, the Business license adds email support with a 24-hour SLA and onboarding covering 3 use cases, while the Enterprise license adds on-call support, an alert mechanism, professional services and onboarding for unlimited use cases. Confirm the current wording and response commitments in your contract instead of relying on this summary. A single-team deployment with one tenant, one location and fewer than 25k app runs may never reach these limits and may not need a paid tier. Measure your executed actions first, since triggers and skipped actions are not counted toward the app run metric, and compare the total with the open-source limit before you decide.
What the cost of each edition is made of
This table breaks down what you pay for when you move from Shuffle's open-source edition to a Business or Enterprise license, separating the license from the infrastructure, staff time and implementation work around it. Read the rows with the app-run metric and the one-time versus recurring column in mind, because those two decide most of the total.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| License fee | Shuffle, for Business or Enterprise access | Recurring, quoted from written scope; no price is published in this comparison | Set by the license tier; ask Shuffle for the quote and what it covers |
| App-run volume | Shuffle, through the license metric | Recurring, tied to usage | Counts actions that actually execute; triggers and skipped actions are not counted, while users, apps and workflows are unlimited |
| OpenSearch infrastructure | Your cloud or data center team or vendor | Recurring, plus initial sizing | Data retention, alert volume and number of backend nodes; an HA setup calls for a cluster |
| Workers and Orborus nodes | Your infrastructure team or cloud provider | Recurring compute | Execution volume, number of locations and the extra Orborus node HA requires |
| Staff time to operate and upgrade | Your internal engineers | Recurring | Upgrade cadence, number of tenants, SSO setup and encryption key handling |
| Implementation and onboarding | Shuffle (onboarding scope by tier) and/or DeployOpen under a fixed-scope written agreement | One-time, with optional retainers for ongoing support | Number of use cases in scope, custom apps built from OpenAPI specs and hardening work |
Moving from the open-source edition to a paid license and back
This sequence moves a Shuffle deployment from the AGPL open-source edition to a licensed Business or Enterprise edition without losing workflows, saved app credentials or execution history, and it defines how to reverse that move if the license changes. Each step ends with a check you can record before the next one starts.
Confirm the current version and baseline
Your platform or security engineering lead records the Shuffle version you run today and compares it with the current release, v2.3.0, published on September 28, 2026. Confirm the image tags your Docker Compose, Swarm or Helm deployment pulls, and whether you track the latest stable tag or a nightly tag. Export the current configuration, including the SHUFFLE_ENCRYPTION_MODIFIER value, and store it in your secrets manager. The output is a dated baseline document naming the version, the image tags and the location of the backup.
Measure app runs against the open-source limit
Your SOC or SOAR owner pulls the app run counts for the last full billing period from the platform and checks them against the open-source hard limit of 25k app runs. Remember that licenses are priced on app runs, meaning actions that actually execute, so triggers and skipped actions do not count toward the metric. Record the trend and the peak month. The output is a volume figure that shows whether the open-source edition is already constraining you and which license tier to request.
Obtain the license and the licensed worker
Procurement or the platform owner requests the Business or Enterprise license from Shuffle in writing, specifying the app run volume, number of tenants, locations, branding needs and whether you need high availability. Confirm in writing which support tier and onboarding use cases are included. Once licensed, Shuffle provides a URL to download the licensed version of the worker. The output is a signed order or license confirmation and the download link, stored with your change record.
Load the licensed worker image with docker load
The platform engineer downloads the licensed worker archive from the URL Shuffle provides and loads it on each host that runs Orborus with docker load. Stop the affected services first, then start the upgraded containers against the same OpenSearch data volume and configuration. Check the image digests on every host so no node runs an older worker. The output is a list of loaded images that matches the approved version, with all Orborus nodes reporting healthy.
Validate SSO and encryption before enabling workflows
The identity team confirms that SAML or OpenID Connect sign-in works for test accounts on the upgraded instance, including per-tenant SSO enforcement if you use it. The security engineer confirms that SHUFFLE_ENCRYPTION_MODIFIER is unchanged, because the documentation warns that losing or changing it breaks every saved app authentication. Test one saved app connection end to end. The output is a signed-off test record covering sign-in, enforcement and at least one working app credential.
Reconfigure tenants, locations and Orborus nodes
The platform owner sets the tenant count, locations and Orborus nodes to match the licensed scope, and adds a second Orborus node if high availability is part of the agreement. Shared components such as the OpenSearch cluster, NFS storage and Memcached should be configured as the high availability guidance describes. Run a representative workflow on each location and confirm executions complete when one Orborus node is stopped in a test window. The output is a documented topology and a failover test result.
Plan the reverse path before any downgrade
Before the business relationship changes, the platform owner documents how to return to the open-source edition. Since v2.1.1, Shuffle actively enforces the limits between editions, so a downgrade can leave you above the 25k app run hard limit, with 3 tenants, 1 location and no high availability. Decide in advance which workflows, tenants or locations will be retired or reduced, and export credentials and execution data while the encryption modifier is still known. The output is a written rollback plan that a second engineer has reviewed.
Put the scope in writing before the change
Before the license change, the owner and your implementation partner agree the scope in writing: target version, license tier, app run volume, tenants, locations, Orborus nodes, SSO method, validation tests and the rollback conditions. Ask the vendor to confirm which items are covered by the license and which are your responsibility. A written scope turns each step above into a checkable deliverable and makes a later quote comparable. The output is a signed change scope that every later step is measured against.
Questions buyers ask before choosing a Shuffle edition
Does the open-source Shuffle edition have the same features as the paid licenses?
Yes, according to Shuffle, all features are included in every tier, and the paid licenses differ in feature limits, scaling and support. The open-source edition has a hard limit of 25k app runs, 3 tenants, 1 location, no branding and no high availability. Business and Enterprise carry a soft limit of 300k+ app runs and unlimited product limits. Since v2.1.1, Shuffle actively enforces these differences, so an environment that grows past the open-source limits will hit them in the product itself. Confirm the current limits with Shuffle before you size a deployment, because the tier chart is the vendor's own description.
What does a Shuffle Business or Enterprise license cost?
No price is published in the sources we rely on, so the figure has to come from Shuffle directly. Shuffle prices licenses on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Your annual cost therefore follows the volume of executed actions your workflows will produce, plus the support tier you pick. Ask Shuffle for a quote that states the app run allowance, the support level, the number of onboarding use cases and whether the license covers high availability and extra locations. Ask whether renewals are priced on the same metric.
How much work does moving from the open-source edition to a paid license take?
The effort depends on your environment, your data and your worker setup, so no fixed duration applies. On premises, a licensed customer receives a download link for the licensed worker and loads it with docker load. The larger items are the data and secrets: saved app credentials are encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, and changing or losing that value breaks every saved app authentication, so the key must carry over unchanged. Plan for a test restore of the OpenSearch data, a review of single sign-on settings and a check of workflow run volume against the license allowance. Ask Shuffle which steps it handles and which fall to your team.
Can an internal team run the open-source Shuffle edition alone?
A team with container and search operations experience can run it, but it has to own several moving parts. The server side is a frontend, a Go backend API on port 5001 and an OpenSearch document database, and the runtime side uses Orborus to start a worker for each execution, which in turn starts app containers. Your team needs to run Docker or Kubernetes, operate OpenSearch, keep images patched by tracking the latest Docker tag for stable releases, and back up data and the encryption secret. Without a paid license, high availability is not offered, so a single failure point stays in place. Decide early who owns on-call response.
What does the Business license support and onboarding include?
The Business license includes email support with a 24-hour SLA and onboarding that covers 3 use cases, according to Shuffle's tier chart. The Enterprise license adds on-call support, an alert mechanism, professional services and onboarding that covers unlimited use cases. Read the SLA wording in the contract, because the chart describes the response window but not what counts as a severity event. If your team needs incident response outside office hours, Enterprise is the tier that lists on-call support. Ask which services are included in the onboarding and whether any extra use cases are billed separately.
Should we bring in a partner to run Shuffle, and what does DeployOpen do?
A partner is useful when your team lacks the capacity to plan, deploy and maintain the platform. DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing upgrades and support are available as retainers. DeployOpen is not a Shuffle reseller and does not issue Shuffle licenses, so the license itself still comes from Shuffle. Ask for a written scope that names what is covered before any work begins.
Which Shuffle versions still receive support for the license enforcement rules?
Shuffle's configuration docs state that versions v2.1.1 and later actively enforce the differences between the open-source and Enterprise editions. Support for older versions ended on January 31, 2026. The current release is Shuffle 2.3.0, published on September 28, 2026. If you run an older build, plan an upgrade before you compare limits, because the older build may not enforce the same rules. Check the release notes on the GitHub releases page and confirm the support status of your build with Shuffle before you commit to a version.
When a paid Shuffle license is worth the cost
A paid Shuffle license makes sense when the open-source edition's limits start to shape how your team works. Begin by measuring app runs, the actions that actually execute in a workflow, against the open-source hard limit of 25k. Triggers and skipped actions do not count, so a team that tallies workflow triggers will overestimate its usage. If your run volume is growing toward that ceiling, plan for the paid tier before enforcement interrupts production playbooks, and ask the vendor how the Business and Enterprise soft limits behave near the threshold.
The second trigger is structural. The open-source edition allows 3 tenants and 1 location, with no branding and no high availability. If you need to separate customers, business units or regions, or you need the Shuffle docs' HA pattern (an OpenSearch cluster, shared files, several backends and more than one Orborus node), a paid license is usually the cheaper path than rebuilding the architecture yourself. Contracted support also matters here: the Business license includes email support with a 24-hour SLA, and the Enterprise license adds on-call support. Confirm the exact response terms in writing, because a support window that fits a SOC running around the clock is a different commitment from one that fits business hours.
Weigh the license fee against staff time and the risk of enforced limits. Engineers who would otherwise maintain HA, handle limit workarounds and write their own onboarding carry recurring cost, and a limit that stops a containment workflow during an incident carries a cost that is hard to quantify. The open-source edition remains the right answer when run volume is well below the limit, a single tenant and location serve you, your team can run the architecture and a single Orborus node meets your availability needs, and you have engineers who can own upgrades. Before signing, get the current license terms, enforcement rules and onboarding scope in writing, since the Business license covers 3 use cases and Enterprise covers unlimited use cases.
Official Shuffle sources to read before buying
Shuffle publishes its edition rules, limits, pricing logic and architecture in its own documentation and release notes. Read these in order before you ask for a quote, because the license tier decides which limits apply to your run volume, tenant count and high availability design.
Open source edition positioning
The Shuffle Open Source article states that every feature ships in every tier and that the paid tiers differ only in feature limits, scaling and support. It also states that Shuffle is built on AGPLv3 and has no plans to close-source the platform. Read it to confirm what the open-source edition covers before you assume any feature needs a license. Ask in writing which limits your team would hit first.
Tier chart and support levels
The tier chart in the open-source article lists the hard limits on tenants, locations, branding and high availability for the free edition, next to the soft limits and support terms for Business and Enterprise. Compare the onboarding use case counts and the support features line by line against your own use case list. Confirm how each tier's support SLA is delivered and who answers after hours.
Enforcement from v2.1.1
The configuration docs state that v2.1.1 and later actively enforce the differences between the open-source and Enterprise editions, and that support for older versions ended on January 31, 2026. This matters if you plan to run an older build or inherit one from another team. Confirm your exact version and tag before you size the deployment, and test a run-limit scenario in a non-production tenant.
How licenses count app runs
The pricing article meters licenses on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Model your expected action volume per day from real workflow logs, including retries and enrichment fan-out, before you accept a run-based quote. Ask the vendor how it reports usage against the license.
High availability and encryption prerequisites
The configuration docs list the high availability pieces that the free tier does not include in its hard limits: an OpenSearch cluster, optional Memcached, NFS for shared files and more than one Orborus node. They also warn that the SHUFFLE_ENCRYPTION_MODIFIER secret protects saved app credentials, and that losing or changing it breaks every saved authentication. Plan backup and key custody for that secret before you go to production.
Release tags and architecture
The architecture docs describe the Go backend on port 5001, the OpenSearch document store and Orborus workers that start an app container per execution, across single server, Swarm, hybrid and Kubernetes layouts. Check the GitHub releases page for the current v2.3.0 release, released September 28, 2026, and the tag your deployment will pin. Decide whether you will track stable tags or nightly builds before you draft your change process.
How DeployOpen scopes and delivers a Shuffle deployment
DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside the client's own infrastructure, and a Shuffle deployment is scoped the same way. The license decision comes first and belongs to the client: DeployOpen does not issue Shuffle licenses, does not publish prices and does not claim partner, reseller or certified status with Shuffle. The license tier, its terms and its pricing come from Shuffle, so confirm the tier and the app run volume you expect directly with Shuffle before any scope is written.
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For a Shuffle deployment, that written scope would typically name the architecture (single server, Docker Swarm, Kubernetes or hybrid with a local Orborus), the OpenSearch sizing, the handling of the SHUFFLE_ENCRYPTION_MODIFIER secret, the SSO configuration and the onboarding use cases. Ask any provider, DeployOpen included, to name which of these items sit in the quote and which are left to your team, and to state how a license tier change would be handled if your app run volume grows.
Ongoing support, upgrades and continuous testing are available as retainers, which matters because Shuffle's configuration docs tie enforced limits to specific releases. Confirm with your own team which version you will run and whether you will follow the latest Docker tag or the nightly tag, and plan upgrades as a recurring task rather than a one-off. Ask for a written quote that separates one-time build work from recurring retainer work so that you can see what continues after go-live.
