Shuffle cost of ownership: what changes after the free edition
The license fee is only one part of what Shuffle costs to run. Shuffle says all features are available in its open-source edition, so the question for a security team is not whether the software is free to use but what it takes to operate it: infrastructure, build work and ongoing upkeep. Those costs exist whichever edition you run, and they are usually the larger part of the total over time.
A cost review typically starts when a decision forces the question. Common triggers include choosing a SOAR platform for the first time, moving off a commercial tool, growing automation volume, or meeting a new compliance requirement that needs documented, tested workflows. Each trigger changes what you need to count: the number of workflows, the systems they touch, the places they run, and who is accountable for them after go-live.
Shuffle's paid tiers differ from the open-source edition in feature limits, scaling and support. Since version 2.1.1 those limits are actively enforced, so an edition check belongs in the review before you commit to a design. Confirm current limits directly with Shuffle, because the boundary between editions is the part most likely to change.
Shuffle's commercial licensing uses one metric: app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Ask Shuffle to confirm how it counts runs for your expected workflow patterns, and model run volume from your alert rates and playbook logic rather than from the number of workflows you plan to build.
Most teams model this cost in-house first, using the server, runtime and staffing estimates from their own platform team, then decide whether a partner should cover the build or the run. Either way, the written model should separate one-time costs (design, integration, testing) from recurring costs (hosting, OpenSearch capacity, worker capacity, app updates and support), and it should name who pays for each line. Ask any partner for a quote that follows from a written scope, not a flat estimate.
What a Shuffle cost of ownership review covers
A cost of ownership review turns the open-source versus licensed question into a written model based on your workflows, runtime layout and team. Each card below is one part of that work, and together they produce a model you can update as usage grows.
Edition and feature fit
We compare the features your use cases need against what the open-source edition provides and what the paid tiers add. Shuffle states that all features are available in the open-source edition, while its paid tiers differ in feature limits, scaling and support. Since v2.1.1, those limits are enforced, so we check each limit against your planned volume and user count. You receive a written list of gaps with the edition that closes each one.
App-run volume from real workflows
Licensing is based on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. We measure run volume from your existing alerts, tickets or scheduled jobs where possible, and estimate it where history does not exist. Each estimate is recorded as an assumption with the source behind it. Confirm with the vendor how app runs are reported in your tenant before you rely on the figure.
OpenSearch and worker sizing
The server side runs a frontend, a Go backend API and an OpenSearch document database, and the runtime side runs Orborus nodes that start a worker for each workflow execution and app containers for each action. We size these components against peak concurrency and retention needs, then state the hardware or cloud capacity each layer requires. High availability adds OpenSearch cluster members and redundant Orborus nodes, so we model those separately.
Build, test and upkeep effort
Initial build covers workflows, custom apps and integrations, while upkeep covers version changes in connected tools, app updates after Shuffle upgrades and workflow fixes after failed runs. We estimate the effort for each category and separate one-time work from recurring work. The model shows who carries each cost: your team, a partner or the vendor. Ask any partner to break effort into build, test and maintenance so the totals can be compared.
Version and support obligations
Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so the model must reflect the upgrade path onto a supported release. Keeping frontend, backend and worker images aligned takes recurring effort, and the model records how often that work happens. Support packages and their response terms vary by tier, so confirm what the paid support covers before comparing it with in-house time.
Written model and open questions
The output is a cost model in a spreadsheet with every assumption labeled, so your finance and security leads can change inputs later. It includes an edition recommendation tied to the feature gaps found earlier, and a list of open questions for the vendor, such as pricing for your app-run volume and scaling terms. DeployOpen does not publish prices, so figures come from the agreed written scope rather than a standard rate.
How Shuffle counts app runs in a licensed model
Shuffle's paid licensing uses one metric: app runs, meaning actions that actually execute in a workflow. Triggers do not count, skipped actions do not count, and users, apps and workflows are unlimited. The licensing question is therefore how many actions run in production, not how many people log in or how many playbooks you maintain. The open-source edition includes all features according to Shuffle, while its paid tiers differ in feature limits, scaling and support. A licensed model only becomes relevant when your design needs one of those tiers, so start by deciding whether you need one at all.
Volume becomes the main licensing question because every executed action is counted each time it runs. A single enrichment step attached to a high-volume alert source multiplies with that alert volume. Branching changes the arithmetic: only the path an execution takes runs its actions, so a workflow with many branches can produce fewer app runs per execution than its total action count suggests. To estimate, review each workflow's logic and list the executed actions on each path. Then check how often typical alerts take each path, using counts from your SIEM, EDR or ticketing exports, and multiply by your expected volume. Illustrative example: a workflow that executes five actions per alert and receives 1,000 alerts a day would produce 5,000 app runs per day.
Since v2.1.1, Shuffle actively enforces the limits between the open-source and enterprise editions. A design that depends on a feature, a scaling limit or a support level can behave differently after an upgrade if it sits on the wrong side of a limit. Before you build, list the capabilities your design requires, such as single sign-on, concurrency, runtime locations and the number of concurrent executions you expect. Then confirm against Shuffle's current edition documentation which edition provides each one and whether any enforced limit sits within your expected volume. Record the result in the project plan so the architecture is not revisited after go-live.
Metering terms can change, so confirm the current definition with Shuffle directly and in writing before you budget. Ask how failed actions, retries, nested workflow calls and skipped branches are classified, whether the definition is identical for self-hosted and Shuffle Cloud deployments, and how run counts are reported to you. Ask for a way to verify those counts against your own execution logs, so your estimate and the vendor's figure can be reconciled each month. Treat the answers as the basis for the licensing line in your cost model, and repeat the check at renewal.
What drives the Shuffle cost up or down
This table lists the drivers that change what running Shuffle costs over time, from the app-run metric in paid tiers to the infrastructure, identity and upkeep work around the platform. Read each row as a question to answer during scoping: which driver applies to your environment, and whether it adds to one-time or recurring cost. The main takeaway is that licensing depends on edition and app runs, while runtime locations, high availability and playbook upkeep often set most of the ongoing effort.
| Driver | Why it moves the cost | How to keep it down |
|---|---|---|
| App-run volume and workflow branching | Paid tiers meter app runs, the actions that actually execute, so more branches and more frequent triggers raise the count. Triggers and skipped actions are not counted. | Estimate expected runs per workflow, add conditions that skip unneeded actions, and review high-volume workflows before they go live. |
| Number and type of integrations | Each integration needs an app, and custom apps need build, testing and upkeep as the vendor API changes. Existing apps cost less to adopt. | Check the existing app catalog first, build custom apps only for systems without a suitable app, and version every app. |
| Runtime locations, including on-premises Orborus nodes | Each location needs an Orborus node, container host capacity and network paths to internal tools such as SIEM or EDR, which adds hosting and network work. | Consolidate runtimes where data rules allow, and confirm that a hybrid setup with a local Orborus needs no inbound firewall ports. |
| High availability requirements | An OpenSearch cluster, shared storage, Memcached, several backends and more than one Orborus node add servers, storage and monitoring effort. | Size high availability to the workflows that must keep running, and confirm the topology in the Shuffle configuration docs before buying hardware. |
| Environments: test, staging and production | Each environment needs its own deployment, credentials and test data, which multiplies infrastructure and testing time. | Keep non-production environments small, share one test runtime where possible, and promote tested workflow versions without rebuilding them. |
| SSO and identity integration | SAML support was added in version 0.9.16 and OpenID Connect in 1.0.0, and per-tenant enforcement and provider setup add configuration and support work. | Use the identity provider your organization already runs, and plan for OpenID Connect on Shuffle Cloud, where SAML is being deprecated. |
| Edition and feature needs | The open-source edition includes all features, while paid tiers differ in feature limits, scaling and support, and those limits are enforced since v2.1.1. | Check the limits your design needs against the current configuration docs, and ask any vendor or partner to state the paid tier scope in writing. |
| Number of playbooks and compliance evidence requirements | Each playbook needs testing, documentation and change records, and compliance evidence adds retention, review and sign-off steps. | Prioritize playbooks by risk, use one test and change template for all, and agree evidence needs with your assessor before building. |
How a Shuffle cost model is built step by step
The sequence below turns a set of intended automations into a cost model that separates the free open-source footprint from any licensed component, with each phase producing a document the client can check and reuse. It is designed so the model can be updated when use cases, app-run volume or the deployment option changes.
Inventory intended use cases and tools
Start by listing the security processes you want Shuffle to automate, the tools each one touches (SIEM, EDR, ticketing, identity, cloud), and who owns each workflow. DeployOpen works through this list with your security operations and platform teams and records it as a use case register with a named owner and the systems each workflow depends on. The step is complete when every planned workflow has a use case, a tool list and an agreed priority order that the rest of the model can reference.
Check edition and feature needs
Compare the features each use case needs against what the open-source edition provides and what the paid tiers add in feature limits, scaling and support. Shuffle states that all features are available in the open-source edition and that limits between editions are enforced since v2.1.1, so the check confirms which limits, if any, your use cases would hit. Ask the vendor to confirm current tier details in writing, since editions can change. The output is an edition decision record that states which edition each environment will run and why.
Estimate app-run volume
Estimate how many app runs each workflow will produce per period, using alert volumes, enrichment calls and expected action counts from your own history. Shuffle prices licensed use on app runs, meaning actions that actually execute, and does not count triggers or skipped actions, so the estimate should exclude those. Ask for your current alert and ticket volumes and the expected growth. The output is a volume table by workflow with low, expected and peak scenarios, which becomes the input for any licensing line in the model.
Size architecture and infrastructure
Map the expected volume and availability target to one of the documented deployment options: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus, or Kubernetes with Helm charts. Each option changes the number of servers, OpenSearch sizing, worker placement and the network paths needed to reach internal tools. Gather your hosting constraints, data residency rules and firewall policies first. The output is a sized infrastructure bill of materials per environment, with the recurring hosting and storage lines that drive run-state cost.
Estimate build and test effort
Break the build into concrete work items: runtime setup, tool integrations, custom apps from OpenAPI specifications or Python, playbook logic, secrets handling and test cases for each workflow. Mark which items are one-time and which need revisiting when a tool or API changes. Provide your existing scripts, runbooks and test data so the work can be sized against real inputs. The output is a work breakdown with effort ranges and an explicit list of assumptions the client must confirm, which becomes the one-time cost section of the model.
Model run-state upkeep and support
Define the recurring work after go-live: upgrades to supported Shuffle versions, rebuilding saved app authentications after credential changes, updating apps when vendor APIs change, monitoring OpenSearch and workers, and responding to failed workflows. Decide who does each task, in-house or through a support package or retainer, and what response expectations apply. Ask for your current on-call model and change-control process. The output is a recurring cost table that separates staff time, infrastructure and any external support, with the drivers that raise each line noted.
Hand over the final cost model
Assemble the earlier outputs into one model with a one-time section, a recurring section, a licensed section tied to the app-run estimate (if any), and a sensitivity view for volume and deployment changes. Review it with your finance, security and platform owners and record each assumption with its source. DeployOpen hands over the workbook, the assumptions log and the update procedure so your team can rerun the model when volumes or editions change. The step closes when the owners have signed off the assumptions and know how to refresh the model.
Recurring Shuffle costs after go-live
This table lists the recurring cost components that appear once a Shuffle deployment is live, who is paid for each, and what drives it up or down. Use it to build a quote request and to separate the open-source edition from any paid tier you may need. Most recurring spend sits in your own infrastructure and staff time, so ask each provider and internal owner for figures in writing.
| Cost component | One-time or recurring | What drives it | What to ask for in a quote |
|---|---|---|---|
| Shuffle license or paid tier | Recurring, only if the chosen edition requires it | App runs, meaning executed actions; triggers and skipped actions are not counted | Rate per app run, included volume, overage terms and the support tier bundled with it |
| Hosting for frontend, backend and OpenSearch | Recurring | Server size, OpenSearch node count, index retention and the high availability layout | Compute, storage and network rates per node from your provider, plus any committed-use options |
| Worker and Orborus capacity | Recurring | Concurrent workflow executions, app container count, Orborus node count and runtime locations | Capacity per runtime node, container registry costs and the number of nodes needed for redundancy |
| Backups and storage | Recurring | OpenSearch index size, backup frequency, retention period and off-site copies of the encryption secret | Storage and data transfer rates, backup tool licensing and the recovery objectives written into scope |
| Upgrades and image alignment | Recurring, with a one-time first alignment | Release frequency, number of frontend, backend and worker images, and test environments | Who performs each upgrade, what testing is included and the effort per release |
| App maintenance after upstream API changes | Recurring | Number of custom and vendor apps, how often third-party APIs change and app versions in use | Maintenance effort per app per year, response process and how pinning or retirement is handled |
| Playbook upkeep and testing | Recurring | Number of active workflows, tool changes in your stack and staging test coverage | Per-workflow update effort, regression test scope and who owns the test evidence |
| Internal staff time | Recurring | Analysts who change workflows, platform owners for patching and on-call coverage | Your own hour estimates by role, used as the baseline for comparing external support quotes |
| External support | Recurring if contracted | Support tier, response scope, upgrade help and whether app and playbook fixes are included | Written scope, coverage hours, response commitments and listed exclusions |
Which Shuffle cost work teams keep in-house and which they outsource
Each card is one part of the Shuffle cost model, with the skills it needs and whether teams usually keep it in-house or buy it in. The right split depends on team size, how many workflows you run, and which skills already exist in your security and platform groups.
Volume and licensing analysis
Estimating app runs is the first cost decision for licensed Shuffle tiers, because licensing is priced on actions that actually execute in a workflow, while triggers and skipped actions are not counted. The skills are security automation design and a clear view of which processes will run how often. Teams with an analyst who knows the alert volume usually keep this in-house, and a partner can help model scenarios. Confirm the current metric and tier terms in writing with Shuffle before you rely on any figure.
Infrastructure sizing and runtime
Sizing covers the backend, frontend, OpenSearch, Orborus nodes and the Docker or Kubernetes hosts where app containers run. The skills are OpenSearch administration, Docker or Kubernetes operations and Linux networking. Platform teams that already run container hosts usually keep this in-house, while teams without that experience often buy the initial design. Ask for the deployment architecture, the number of Orborus nodes and the storage plan.
Playbook build and testing
Building workflows for your detection, enrichment and response processes, then testing each branch with representative inputs, is the largest recurring share of effort. The skills are security automation design, incident response knowledge and workflow testing discipline. Teams with an existing automation owner usually keep this in-house, and buying in makes sense for the first set of high-value use cases. Ask how test data, sandbox runs and sign-off are handled.
Custom app development
Where Shuffle lacks an app for a tool you use, a custom app is built from an OpenAPI specification in the App Creator or written in Python with the Shuffle app SDK, then packaged as a versioned Docker container. The skills are Python or OpenAPI, API authentication handling and container packaging. Teams with developers who already integrate internal APIs usually keep this in-house. Ask for the test plan, versioning approach and documentation delivered with each app.
Identity integration and access
Connecting Shuffle to your identity provider through OpenID Connect or SAML, and deciding how users are provisioned and which roles they receive, requires identity administration and an understanding of tenant-level enforcement. Identity teams usually keep the provider side in-house and often buy in the Shuffle configuration once, with the role design agreed with them. Confirm which SSO protocol your provider supports and whether it is being deprecated for your deployment type.
Upkeep and version alignment
Upkeep covers patching, moving frontend, backend and worker images to supported versions together, updating apps after upgrades, and monitoring OpenSearch health and backups. The skills are container operations, change management and OpenSearch administration. Teams with a stable platform rotation usually keep this in-house, and many buy a retainer for upgrade windows. Ask for the supported version policy and the rollback plan for each upgrade.
Governance of the model over time
Governance decides who owns each workflow, who approves changes, how the encryption secret for saved app credentials is stored and rotated, and when the cost model is reviewed as app-run volume changes. The skills are security governance, secrets management and clear ownership across SOC and platform teams. This is usually kept in-house because it reflects your own risk decisions. Ask for a written owner list, a change approval path and a review schedule.
How the Shuffle cost differs by starting point
Teams arriving from a commercial SOAR or from scripts and cron jobs share one cost pattern: spend moves from licences to people, because playbooks must be rebuilt as workflows and apps. The open-source edition carries all features, so the licence line you retire is the main recurring saving to model. The rebuild and parallel-run effort is one-time, but it scales with the number of automations. Scripts usually remove no licence line, yet they demand the most inventory work because undocumented jobs surface late.
- Retired licences: Commercial SOAR fees you stop paying are the largest recurring item to model. Script migrations often have no licence to remove.
- Rebuild effort: Each playbook, connector and schedule becomes a workflow or app. This is a one-time cost driven by count and complexity.
- Parallel running: Keeping the old tooling alive during validation adds temporary infrastructure and staff time.
- Connector gaps: Integrations your old platform offered out of the box may need custom apps, which add build and upkeep cost.
- Retirement: Decommissioning old runners and removing stored credentials is a one-time task that is easy to omit from a quote.
Before requesting a quote, ask which current tools and licence terms will end, and how many automations are undocumented.
A single server with Docker Compose has the lowest infrastructure entry cost, and the open-source edition adds no licence fee for the platform itself. Spend concentrates on one host, its backups and the staff who patch it. The frontend, backend, OpenSearch and runtime share one machine, so there is no redundancy and an outage stops every workflow. Growth usually forces a later move to a multi-node design, which is a separate project with its own one-time cost.
- Host and storage: The server, whether hardware or a cloud instance, and the disk for OpenSearch data are recurring costs.
- Backups: Regular backups of OpenSearch data and the encryption secret are a recurring operational task.
- Patching: Your team applies platform and app image updates, which is usually the main staff cost.
- Outage exposure: Without redundancy, a failed host halts all workflows. The cost of that risk depends on your response obligations.
- Scaling step: Moving to a multi-node design later is a one-time project, often larger than planning the multi-node design now.
Check which workflows are time-sensitive and how long an outage can be tolerated before committing to a single host.
Running Shuffle across Docker Swarm or Kubernetes adds cost mainly through more nodes, cluster tooling and the people who operate them. The Shuffle documentation recommends an OpenSearch cluster, backends and frontends across servers, and more than one Orborus node for resilience, so the infrastructure line grows with each of these. Kubernetes with Helm charts also brings cluster operations skills, monitoring and registry costs that a single Compose host does not carry. These costs recur and often become the largest operating cost once several teams depend on the platform.
- Cluster nodes: Servers or nodes for backends, frontends, OpenSearch and workers are recurring infrastructure costs.
- Shared storage: NFS for shared files and optional Memcached add components to run, monitor and back up.
- Redundant Orborus: Multiple runtime nodes keep workflows running if one fails and increase worker capacity needs.
- Cluster operations: Platform engineering time for upgrades, Helm values and node maintenance recurs with each release cycle.
- Image registry and caching: Storage and bandwidth for app images grow with app count and worker volume.
Ask who on your team already operates Swarm or Kubernetes, since that skill decides whether this cost stays internal or needs an external retainer.
Shuffle Cloud with a local Orborus moves frontend and backend operation to a managed service, while the runtime stays inside your network so apps can reach internal SIEM, EDR and directory services. Your infrastructure bill shrinks to the runtime hosts you run, but any paid subscription becomes the main platform cost. Paid tiers are licensed on app runs, so workflow volume drives licence cost directly. The local Orborus needs no inbound firewall ports, which lowers network change effort, though outbound connectivity and its patching remain yours.
- Hosted control plane: Frontend and backend operation moves to the vendor, reducing your server count and patching load.
- Runtime hosts: Orborus nodes you run stay on your infrastructure bill and your patch cycle.
- App-run volume: Actions that execute are metered, so volume growth raises licence cost. Triggers and skipped actions are not counted.
- Firewall work: Outbound-only connectivity avoids inbound rule changes, a one-time saving.
- Data location review: Confirming where workflow data is stored is a one-time legal and security effort.
Confirm which metering and support terms apply to the cloud tier you need, and where its data is held.
In an air-gapped network, every dependency that normally arrives online must be brought in deliberately: container images, app packages, updates and any feeds the platform uses. Costs shift toward internal artifact handling, controlled transfer procedures and staff time for each release. The open-source edition removes the licence fee, but these operational costs still recur. Some features depend on external services, so confirm each one with the vendor before design, because offline behavior cannot be assumed for every feature.
- Image transfer: Mirroring Docker images and app containers into an internal registry is a recurring task for each release.
- Update cadence: Each upgrade needs a validated transfer bundle, which adds staff time per cycle.
- Offline app dependencies: Apps that call external APIs need internal endpoints or proxies, which is a build cost.
- Verification: Testing offline builds after each transfer adds recurring effort that a connected environment avoids.
- Secrets and backups: Keeping the encryption secret and OpenSearch backups inside the enclave requires controlled handling.
Ask the vendor which features need outside connectivity and how releases reach your enclave before estimating internal effort.
Where Shuffle cost models go wrong
Most Shuffle cost models fail in the same few places: how app runs are counted, how volume grows after launch, and which infrastructure and upkeep work is left out. Each card names one error, why it affects the total cost of ownership, and the check that prevents it.
Miscounting app runs
Shuffle licensing is priced on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, so a model that counts every event or every workflow node will overstate the licensed cost. Retries need their own check, because a flaky external API can raise the number of executed actions without any new playbook. Prevention: pull a sample week of executions from a pilot, count them using the pricing definition, and add observed retry rates to the model. Confirm with Shuffle how retried actions are counted before you rely on the figure.
Underestimating volume after go-live
Early estimates often multiply the number of planned playbooks by an assumed run count. Once the first playbooks process live alerts, volume usually grows as teams add enrichment steps, cover more alert types and connect more tools. Every added action that executes adds to the app-run count. Prevention: build the model from per-playbook execution data gathered during testing, and schedule a volume review after the first production period so the run count is recalculated against the licensing definition.
Omitting the second Orborus or OpenSearch node
A single Orborus node is a single point of failure for workflow execution, and the Shuffle configuration docs recommend more than one Orborus node for high availability. The same guidance points to an OpenSearch cluster instead of a single document database. Each extra node adds servers, storage, patching, monitoring and backup scope, and these costs recur. Prevention: include the redundant nodes, their storage and their operating effort in the infrastructure line of the model, and ask any implementation partner to price recovery testing separately.
Losing or changing the encryption secret
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The configuration docs warn that losing or changing this value breaks all saved app authentications, so every connected tool stops working until its credentials are entered again. That recovery work is labor the licensed and open-source comparison should both account for. Prevention: store the secret in a managed secrets store with restricted access, keep a tested backup, and write a change procedure that plans for re-authenticating every app.
Skipping app maintenance after API changes
Shuffle apps are built from OpenAPI specifications or the Python app SDK and run as versioned Docker containers. When a vendor changes an API, the affected app can fail, and every playbook that depends on it fails with it. Maintenance therefore recurs for as long as the integrations are in use, and it is easy to leave out of a first-year estimate. Prevention: keep an inventory of each app with its vendor, version and owner, put regression tests on the critical playbooks, and budget recurring effort per integration.
Treating the free edition as zero upkeep
Shuffle states that all features are available in the open-source edition, and the paid tiers differ in limits, scaling and support. The open-source edition still carries servers, upgrades and staff time. Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so upgrades are a recurring task. SSO also needs setup work, since SAML arrived in version 0.9.16 and OpenID Connect in 1.0.0. Prevention: list infrastructure, upgrade, SSO and support labor as recurring lines before comparing with a licensed quote.
What your team needs to provide for an accurate Shuffle cost model
An accurate Shuffle cost model depends on inputs that only your team holds. Before a partner can estimate infrastructure, implementation effort or recurring upkeep, you need to supply a current and planned automation inventory, the systems each automation touches, the network zones involved, and the volumes you expect. Without these, any figure is a guess, and the gap usually shows up later as an underestimated app-run volume or an unplanned runtime location. Start with the automation list. For each current or planned workflow, record the trigger source (a SIEM alert, an EDR detection, a ticketing webhook, a schedule, a mailbox), the expected number of executions per day or month, and the number of actions each run performs. Shuffle's licensing counts app runs, meaning actions that actually execute, and does not count triggers or skipped actions. So the action count per run, not the number of workflows, is what moves the licensed cost. Note which automations are business-critical and which are experimental, because that separates the baseline from the growth allowance.
Next, list every tool and API the workflows call, along with the zone each one lives in. Include the SIEM, EDR, identity provider, ticketing system, cloud control planes and any internal APIs. Mark which ones need a runtime inside a private network, since Shuffle's hybrid option uses a local Orborus that reaches internal services without inbound firewall ports, and a fully hosted runtime cannot reach them. The number of runtime locations and the number of Orborus nodes you need drive infrastructure cost directly. Also state your availability targets, because a single-node design and a redundant design with several Orborus nodes and an OpenSearch cluster are priced differently. Your team should also provide user counts, the number of environments (production, staging, test), and the compliance evidence your controls require, such as logs of workflow changes, approval records for playbook releases or access reviews for the platform. Evidence needs add recurring effort, because someone must produce and retain it. Ask a partner to show how each evidence item is collected and who performs the collection.
Four roles must be named before the model can be finalized. The security automation lead owns the use case list, the priority order and the acceptance criteria for each playbook. The platform or infrastructure owner decides where containers run, which servers and runtimes are provisioned, and who patches them. The identity administrator confirms how users will sign in, which affects whether OpenID Connect or SAML is configured and who provisions accounts. The budget approver sets the cost ceiling and decides how one-time implementation is separated from recurring licensing, infrastructure and support. Each role should sign off on the inputs it owns. Sample workflow logs and alert volumes make the estimate far more reliable. Export a representative period of alert counts per source and, if you already run scripts or another SOAR, the execution history of those automations. Real volumes reveal how many actions a typical run performs and how often failures trigger retries, both of which change app-run consumption. Where no history exists, say so and label the planned volumes as assumptions to be revisited after the first production month.
Questions buyers ask about Shuffle cost and effort
Is Shuffle free to run in production?
The open-source edition is free to download and run, and Shuffle states that all features are available in it. What is not free is the infrastructure it runs on, the staff time to deploy and maintain it, and any paid tier you choose. Paid tiers differ in feature limits, scaling and support, and since v2.1.1 the limits between the open-source and enterprise editions are actively enforced. Before you budget, confirm with Shuffle which limits apply to your planned design, such as scale or support level, and whether the open-source edition meets your requirements. Your total cost of ownership is the sum of hosting, staff time, and any subscription, so model all three rather than treating the software line as zero.
How is Shuffle licensing metered?
Paid licensing is metered on one measure: app runs, meaning actions that actually execute inside a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. This means cost follows automation activity rather than headcount. To estimate it, review your highest-volume workflows, count how many actions run per day on average and at peak, and separate scheduled polling from alert-driven runs, since polling workflows can generate many executions. Ask Shuffle to confirm the current metering terms in writing, including how they count retries and failed actions, because those details change how you forecast volume.
What drives the infrastructure cost of a Shuffle deployment?
Infrastructure cost comes from the components Shuffle needs to run. The server side includes the frontend, the Go backend API, and an OpenSearch document database. The runtime side includes Orborus nodes, which poll the backend for jobs and start a worker for each workflow execution, and the app containers those workers launch. High availability adds cost because the Shuffle documentation recommends an OpenSearch cluster, optional Memcached, NFS for shared files when running several backends, and more than one Orborus node. Costs rise with execution volume, the number of parallel runs, retention of stored execution data, and whether runtimes sit in your data center, a cloud account, or a hybrid design. Ask your infrastructure team to size these components against your expected volume before committing.
How long does it take to build a Shuffle cost model?
The time depends on the scope agreed in writing before work starts. A cost model that covers one deployment architecture and a short list of use cases takes less effort than one that compares several runtime locations, high availability designs, and licensing tiers across a large set of playbooks. The main inputs are your priority use cases, the tool integrations they need, the number of runtime locations, your expected app-run volume, and whether you want one-time and recurring costs separated. DeployOpen does not state a fixed duration for this work. Request a written scope with deliverables and a timeline from us, and check that it lists which inputs you must supply and when.
Can our own team run Shuffle without a partner?
Yes, many teams do, provided they have the skills the deployment needs. Those skills include container and Docker or Kubernetes operations, OpenSearch administration, networking and TLS for webhooks, secrets handling for the encryption secret that protects saved app credentials, and enough Python or OpenAPI knowledge to build and maintain apps. Losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks all saved app authentications, so your team must be able to back it up and restore it. A partner is useful when one or more of these skills are missing, when the timeline is short, or when you want the design reviewed before production. Assess your team against this list honestly before deciding.
What does a Shuffle implementation need from our team?
The work needs several inputs from your side. Start with an inventory of current automations, including scripts, cron jobs, and any existing SOAR workflows, with their triggers and the systems they touch. Provide logs or execution records that show how often each process runs and where it fails. Name an owner for each workflow and each integrated tool who can approve changes and answer questions. Grant access to the environments, the security tools that apps will connect to, and the network paths between runtimes and internal services. Also provide a test environment and a change window. Missing inputs usually extend the schedule, so confirm the list with your delivery lead before work starts.
What should we confirm with Shuffle directly before budgeting?
Several points change over time and should come from the vendor, not from this page. Confirm the current terms for licensing and metering, including the definition of app runs. Confirm the limits on each edition, such as scale and support, and which limits are enforced in the version you plan to run. Confirm the edition that matches your design, especially if you need SSO, high availability, or multiple runtime locations. Ask which versions are currently supported. Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026, so a deployment on an older release needs an upgrade path in the budget. Get these answers in writing and date them, because they affect your model directly.
How DeployOpen builds and hands over a Shuffle cost model
DeployOpen builds a Shuffle cost of ownership model from the written scope of your environment, separating the free open-source edition from any licensed tier you would need. The model traces each cost to a component you can verify, including app-run volume, runtime infrastructure, implementation effort and ongoing upkeep.
How we scope
- We confirm which Shuffle features your use cases need and whether the open-source edition covers them.
- We inventory planned workflows, apps and runtime locations so app-run volume can be estimated from actual automations.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We model one-time costs such as deployment, integrations and playbook build separately from recurring infrastructure and licensing.
- We size OpenSearch, backend, frontend and Orborus infrastructure against the deployment architecture you select.
- We test the cost assumptions against a sample of workflows so app-run counts reflect real execution, not design estimates.
How we hand over
- You receive the cost model as a document with every assumption, driver and source named for your team to review.
- We document how to recheck app-run counts and infrastructure usage so your team can update the model as automations grow.
- We walk your finance, security and platform staff through the model and the quote basis before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, and we can keep the cost model current with them.
- We review the model when you change Shuffle versions, add runtime locations or expand workflow volume.
- Before any licensing decision, we recommend confirming current edition limits and pricing directly with Shuffle.
