When Splunk SOAR or self-hosted Shuffle fits a SOAR decision
Splunk SOAR fits best when your estate is already centered on Splunk, your team has Python playbooks and custom apps that work, and you need vendor support and analyst case views as part of the platform. Shuffle fits best when you want licensing tied to app runs rather than seats, want the platform and its data in your own infrastructure, and expect most of your integrations to come from OpenAPI specifications or the Python app SDK. Neither answer is correct in general. It depends on the four points below, and you should settle them before the renewal or upgrade date forces the choice.
Start with case handling. Splunk SOAR gives analysts a mature container and case model, and Shuffle is built around workflows and executions, so ask which case views your analysts use every day and whether you need to rebuild them. Then look at Python extensibility: count your existing custom functions and check whether they already run on Python 3. Shuffle apps are written as versioned Docker containers, so each custom action is a rewrite, not a port. The third point is capacity. Shuffle's own docs recommend an OpenSearch cluster, more than one Orborus node and shared storage for high availability, so confirm who on your team will run those components, patch them and back them up. The fourth point is SIEM fit. Confirm which SIEM sends your alerts and whether a Shuffle app exists or can be built for it.
Which platform fits which operating situation
If your SOC already runs Splunk Enterprise Security and has a body of working Splunk SOAR playbooks, staying on Splunk SOAR is usually the lower-risk path in the short term. Splunk SOAR keeps the playbooks, apps, assets and analyst case views your team already knows, and the Splunk integration is native rather than built by you. Moving to Shuffle is a rewrite project, not a configuration change, so the case for it rests on licensing or deployment needs, not on tooling parity.
- Playbook inventory: Count the playbooks, custom functions and apps in use. Each Python custom function will need to become a Shuffle app or workflow step if you move.
- Export path: Playbooks can be exported as .tgz archives, but asset configurations and credentials have to be mapped again in the target platform.
- Splunk version and edition: Confirm which Splunk SOAR (On-premises) version you run and whether the classic playbook editor, deprecated in 2024, is still in use.
- Cloud migration: Splunk documents migrating On-premises administration, apps, playbooks and custom functions to Splunk SOAR (Cloud), which requires converting custom code to Python 3 first.
- Decision trigger: Stay if the playbooks work and the license terms fit. Evaluate Shuffle if the renewal cost or the upgrade path is the main pressure.
Confirm the exact license terms and Splunk SOAR support dates with Splunk before you decide, since these depend on your contract.
If your detection stack is Microsoft Sentinel, Elastic, Wazuh, Graylog or another SIEM, Splunk SOAR's advantage in native integration shrinks, and Shuffle's app model becomes easier to weigh on its merits. Shuffle connects to tools through apps built in its App Creator from OpenAPI specifications or written in Python with the Shuffle app SDK, so the work is in building or validating the integration for your SIEM rather than in carrying over Splunk-specific code.
- Connector inventory: List every SIEM, ticketing and enrichment system the playbooks call, then check whether Shuffle already ships a premade app or whether you need to build one.
- OpenAPI coverage: Apps built from OpenAPI specifications only cover what the specification describes, so confirm the endpoints you need exist and are documented.
- Alert ingestion: Confirm how alerts will reach Shuffle from your SIEM, and that the chosen trigger method suits your alert volume.
- Run-time cost: Shuffle's licensing counts app runs, so high-volume enrichment against a non-Splunk SIEM can drive usage up and should be modeled.
- Testing: Validate each app against a non-production SIEM tenant before cutover.
Confirm current app coverage for your specific SIEM in the Shuffle documentation and test it in your own environment.
If your organization must keep incident data, case records and credentials on infrastructure it controls, the deployment model matters more than feature parity. Splunk SOAR (Cloud) is hosted and managed by Splunk, so its data location depends on that service. Shuffle can run in your own cloud accounts, data centers or private networks, and its hybrid option lets a local Orborus run without inbound firewall ports while the backend stays under your control. Shuffle encrypts saved app credentials in OpenSearch with AES-256 using a secret you manage.
- Deployment model: Single server with Docker Compose, Docker Swarm, Kubernetes with Helm, or the hybrid model, each with different isolation and operating needs.
- Key management: The SHUFFLE_ENCRYPTION_MODIFIER secret protects saved credentials. Losing or changing it breaks every saved app authentication, so it needs a documented backup and rotation procedure.
- Identity: Shuffle supports SAML (added in 0.9.16) and OpenID Connect (added in 1.0.0), with SAML being deprecated on Shuffle Cloud.
- Audit evidence: Confirm the logging and access records your auditors expect, and how they are exported.
- Assessment support: DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any report.
Check with your legal, privacy and compliance teams which data classes can leave your environment, and confirm both platforms' hosting terms in writing.
If a small team runs security operations with little spare capacity for platform work, the question is less about features and more about who will patch, back up and scale the platform. Shuffle's default Docker Compose setup is not a scalable build without changes and needs at least 4 GB of RAM, so a single-node install is the simplest start but not a production-grade cluster. Shuffle also offers a hosted cloud service at shuffler.io, and Splunk SOAR (Cloud) removes the operations burden entirely at the cost of the hosting relationship.
- Operational load: A self-hosted Shuffle install adds OpenSearch, the backend, the frontend and Orborus to patch and monitor.
- High availability: The docs recommend an OpenSearch cluster, shared cache and file storage, and more than one Orborus node. Each adds components to run.
- Hosted option: Shuffle Cloud can reduce operations work, but confirm its data handling against your policy.
- Support: Ongoing support, upgrades and continuous testing are available as DeployOpen retainers, scoped in writing.
- Upgrade rhythm: Shuffle recommends the latest Docker tag for stable releases, so set a patch schedule before go-live.
Ask your vendor or partner for a written scope covering installation, backup, upgrades and on-call responsibility before choosing a self-hosted path.
Scenario, better fit and why
This table maps common buying scenarios to the platform that fits each one better, and states the condition under which that fit holds. Read each row against your own SIEM, licensing position and data residency rules, because the same scenario can point in different directions in different environments. The main takeaway is that Shuffle fits best when app-run licensing, on-premises residency or a non-Splunk SIEM dominate, while Splunk SOAR fits best when Splunk integration and existing Python playbooks dominate.
| Scenario | Better fit | Why and the condition it depends on |
|---|---|---|
| Heavy Splunk integration across detection and response | Splunk SOAR | Native Splunk alert and search integration reduces connector work. This holds only if Splunk remains the primary alert source for the foreseeable future. |
| Large library of existing Python custom functions and playbooks | Splunk SOAR | Python logic can stay in place with less rewriting. This holds only if the code runs on the Python version your Splunk SOAR release supports; confirm this before planning a move. |
| Analyst case management is central to daily work | Splunk SOAR | Splunk SOAR has built-in case and container handling for analysts. Shuffle covers workflow execution well, so confirm that its case views meet your analysts' needs in a trial. |
| Licensing exposure grows with workflow volume | Shuffle | Shuffle prices on app runs, counting only executed actions, and users, apps and workflows are unlimited. This holds if your automation volume is high and seat counts are low. Model app runs against your real workflows before deciding. |
| On-premises data residency with no external SaaS dependency | Shuffle | Shuffle can run entirely in your own Docker or Kubernetes environment, and the hybrid option needs no inbound firewall ports for the local Orborus. Confirm that your residency rules accept the OpenSearch store and credential encryption you would operate. |
| A non-Splunk SIEM as the alert source | Shuffle | Shuffle is not tied to Splunk, so it integrates with other SIEMs through apps built from OpenAPI specifications or the Python SDK. This holds if the SIEM's API covers the actions you need; verify that with your SIEM vendor. |
| Team has in-house capacity to run OpenSearch and HA | Shuffle | Shuffle's high availability guidance calls for an OpenSearch cluster, shared files and several Orborus nodes. This holds if you can operate those components; otherwise a Splunk SOAR cloud or managed option may reduce operational load. |
| Need for enterprise SSO and per-tenant controls | Either, after review | Shuffle offers SAML and OpenID Connect single sign-on with per-tenant enforcement. Confirm which SSO features your edition and deployment include, and compare them with your Splunk SOAR configuration. |
Where the data lives and who controls the platform
Splunk SOAR and Shuffle differ most in who operates the platform and where case data, playbook content and stored credentials sit. The cards below cover the hosting choices, the encryption key that protects saved app credentials, identity controls and the compliance evidence you will need to collect in either model.
Hosting model and operator
Splunk SOAR (Cloud) is a SaaS service hosted and managed by Splunk, while Splunk SOAR (On-premises) runs in your own environment. Shuffle can run entirely in your infrastructure with Docker Compose, Docker Swarm or Kubernetes, or use a hybrid model in which Shuffle Cloud hosts the backend and a local Orborus runtime executes actions inside your network. Confirm with each vendor which components sit in their environment and which sit in yours, including the runtime that touches your systems.
Shuffle Cloud as an option
Shuffle also offers a hosted service at shuffler.io as an alternative to self-hosting. Choosing it moves the backend and database operation to Shuffle, so you should ask where case and workflow data is stored, which regions are used, how tenants are separated and what happens to data at exit. The hybrid design keeps action execution local, which many teams use to limit what leaves their network.
Credential encryption key
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing this value breaks every saved app authentication, so store it in a secrets manager, back it up with the database and document the rotation procedure before go-live. Splunk SOAR handles asset credentials in its own store, so compare how each platform's key custody fits your existing key management process.
Identity and single sign-on
Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, on premises and in the cloud, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so new integrations should target OpenID Connect. Check how Splunk SOAR users and roles map to your identity provider, and confirm that administrator access to the runtime and to the key store is restricted separately from analyst access.
Backup and key recovery
Shuffle's high availability guidance calls for an OpenSearch cluster, shared files for multiple backends and more than one Orborus node. Backups must cover the OpenSearch data, workflow definitions and the encryption secret together, because one without the others cannot restore working app connections. Ask Splunk for its backup and data retention terms for the Cloud service, and confirm your own retention periods for case records, which often fall under internal policy or regulation.
Compliance evidence and ownership
Hosting choices shape which controls you inherit and which you must evidence yourself. For self-hosted Shuffle, your team owns the access logs, change records, patch cadence and key management that auditors will sample. DeployOpen can plan, configure and document these controls and prepare the evidence for an assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
How Shuffle app-run licensing differs from seat-based pricing
Shuffle meters app runs, not people. An app run is an action that actually executes in a workflow. Triggers and skipped actions are not counted, and Shuffle states that users, apps and workflows are unlimited. Your cost therefore rises with automation volume: a playbook that fires many actions per alert consumes more runs as alert volume grows, while adding analysts costs nothing extra. Splunk SOAR works the other way. Seat-based licensing ties cost to the people who log in, and the free Splunk SOAR (On-premises) Community License caps you at 100 licensed actions per day, 1 tenant and 5 open cases. Those three limits grow at different speeds, so model each one against your real alert and case numbers.
The open-source edition includes every feature. Shuffle says all features are available in the open-source edition and that paid tiers differ in feature limits, scaling and support. Since v2.1.1, those limits are actively enforced, so the question is whether your run volume or scale fits the edition you run, not whether you can use a capability. Ask Shuffle in writing which limits apply to self-hosted deployments, how it counts runs in a distributed setup with several Orborus nodes, and what happens when you exceed a limit. Also confirm whether the current edition terms match the Shuffle pricing article, since limits can change between releases.
Licensing of code and content is split. The Shuffle backend is licensed under AGPLv3, which carries source-sharing duties if you modify it and make it available to users over a network. Workflows, documentation, apps and app specifications are under MIT, so the playbooks and custom apps your team writes can stay under your own terms. Have legal review what AGPLv3 means for any patches you plan to run. Splunk SOAR is licensed under its own agreement, so confirm its seat terms, Community License restrictions and any export rights with Splunk before comparing total cost.
What drives the cost of each platform
How is Splunk SOAR licensed compared with Shuffle?
Splunk SOAR is licensed commercially, with terms set by Splunk and its reseller agreement, while Shuffle's backend is AGPLv3 and its workflows, apps and documentation are MIT. Shuffle prices its enterprise tiers on app runs, meaning actions that actually execute in a workflow, and its docs state that users, apps and workflows are unlimited. Ask Splunk for the written metric, the included actions, the tenant count and the renewal terms, and ask Shuffle which tier and app-run allowance the planned volume falls into. Licensing is recurring, so compare it over the full term, not the first quote.
What servers does self-hosted Shuffle need?
Shuffle's install guide lists Docker and Kubernetes as installation options and states that it needs a minimum of 4 GB of RAM. The default Docker Compose setup is not a scalable build without changes, so a production design usually uses Docker Swarm, Kubernetes with Helm, or the hybrid model with local Orborus nodes. Server costs are recurring and depend on the number of workflows, parallel executions and the nodes you run for resilience. Ask your infrastructure team to size the backend, frontend, OpenSearch and Orborus nodes against expected workflow volume before comparing to a SaaS line item.
How much does OpenSearch storage add to a Shuffle deployment?
Shuffle uses OpenSearch as its document database, so execution history, workflow data and stored records consume disk in your cluster. Storage cost is recurring and grows with retention settings, execution volume and how much workflow output you keep. Plan for retention policies from the start, because the cost of disk, snapshots and backups tends to outlast the initial build. Ask for a sizing estimate based on your daily execution count and retention period, and confirm which OpenSearch version the release requires.
What high availability components add cost to Shuffle?
The Shuffle configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when running several backends, scaled backend and frontend across servers, and more than one Orborus node so workflows keep running if one fails. Each component is an extra server, disk or operating effort that recurs every month. Redundancy adds cost, so decide which workflows need uninterrupted execution, such as containment actions, and size the design to those. Ask your implementation partner to show which components are required for your recovery targets and which are optional.
How much effort does rewriting Splunk SOAR playbooks for Shuffle take?
Rewrite effort depends on how many playbooks, custom Python functions and app-specific actions you have, and on how many depend on Splunk-specific containers, assets and classic editor features. Splunk documents exporting playbooks as .tgz archives and notes the classic playbook editor was deprecated in 2024. Shuffle apps can be built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK, so each custom function becomes a versioned app to test. This is largely a one-time cost. Ask for an inventory of playbooks by complexity and a test plan with sample alerts before agreeing to a fixed scope.
What does upgrading each platform cost over time?
On Splunk SOAR (On-premises), upgrades follow Splunk's supported minor versions and require planning for Python 3 changes when you consider Splunk SOAR (Cloud). On self-hosted Shuffle, you own the upgrade cycle: the docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so you choose a tag and test before you move production. Upgrades are recurring operational work either way. Ask each vendor for its supported-version policy and release notes, and budget for staging environments and regression tests in your own team's time.
What support costs should I expect for Shuffle and Splunk SOAR?
Splunk SOAR support is part of its commercial agreement, and the terms, response times and escalation paths should be written into the contract. Shuffle's open-source edition is community supported, while its paid tiers differ in support and scaling, so confirm which support level your tier includes. Self-hosting shifts operations, on-call and patching to your team or a support retainer. Ask each vendor for written support hours, severity definitions and response commitments, and ask your implementation partner whether ongoing support is needed as a fixed-scope engagement or a retainer.
What should I request in a quote for a Shuffle migration?
Ask for a written scope that lists the playbooks to rewrite, the apps to build or adapt, the deployment architecture, the high availability components, the OpenSearch sizing assumptions and the testing plan. Include whether the quote covers installation, hardening, backup, documentation and handover, and whether it includes upgrades or only one-time delivery. For Splunk SOAR, request the annual license cost, the renewal terms and any cloud migration costs in writing. Compare both sides over the same period, with one-time and recurring items shown separately.
What a move from Splunk SOAR to Shuffle involves
The sequence turns Splunk SOAR playbooks, apps and assets into a Shuffle deployment that handles the same alerts, with each stage checked before the next one starts. The total effort depends on how many playbooks you run and how much custom Python code they contain.
Inventory playbooks, apps and custom code
The security engineering lead lists every active playbook, the apps and assets each one calls, the custom functions they use, and the cases and containers they touch. Splunk documents exporting and importing playbooks as .tgz archives, so start there and note which playbooks depend on the classic editor, which was deprecated in 2024. The step is done when the list is complete and each playbook has an owner and a rough complexity rating agreed by the team.
Export playbooks as .tgz archives
The platform administrator exports each playbook from Splunk SOAR (On-premises) as a .tgz archive and stores the archives in version control alongside the inventory. Keep the exports as a reference record, because they show the logic you are rebuilding even though they will not be imported into Shuffle. Confirm the export steps against your Splunk SOAR version in the Splunk documentation. The step is done when every archive in the inventory is stored, named and checked to open.
Map custom Python functions to Shuffle apps
Developers review each custom Python function and decide whether it becomes a Shuffle app, a step inside a workflow, or code that is no longer needed. Shuffle builds integrations from OpenAPI specifications in its App Creator and also accepts Python apps written with its app SDK, which run as versioned Docker containers. Test each new app against a sandbox tool instance before it touches production data. The step is done when every function has a documented disposition and each retained app passes its tests.
Recreate app authentication and assets
The integration owner recreates each app connection in Shuffle, because Splunk SOAR asset configurations cannot be carried over as they are. Shuffle stores app credentials and API keys encrypted in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret, so record that secret in your secrets manager before any credential is saved. The step is done when each connection authenticates against its source system and the secret is backed up in a location separate from the server.
Rebuild case handling practices
The SOC manager defines how alerts become cases, who owns them, and which fields, approvals and closure rules analysts rely on, then rebuilds that practice in Shuffle's workflows and in whatever case or ticketing system your team uses. Confirm the case features you need against Shuffle's current documentation, since this area often needs more design work than the playbook code itself. The step is done when a written case procedure is approved and a test case moves through it from open to closed.
Reconnect the SIEM as the alert source
The detection engineer points your SIEM, whether Splunk or another platform, at Shuffle as the destination for alerts, using the trigger and webhook options in Shuffle's app catalog. Test that alert fields arrive in the format each workflow expects, and check that the SIEM's own alert suppression still applies. The step is done when test alerts from each source start the matching workflow and the results appear in the case queue.
Run in parallel, then cut over
For a defined period agreed by the security leadership, both platforms receive alerts, and the team compares actions, outcomes and case records side by side. Plan for Shuffle's high-availability guidance, including an OpenSearch cluster and more than one Orborus node, before production load arrives. Cut over one playbook group at a time, keeping Splunk SOAR available for rollback until the last group is verified. The step is done when parallel results match and the Splunk SOAR playbooks are disabled under a signed change record.
Questions buyers ask before choosing Shuffle over Splunk SOAR
How much cost and effort does switching from Splunk SOAR to Shuffle take?
The switch cost is driven mostly by the number of playbooks, custom Python functions and app integrations you need to rebuild, not by the software itself. Shuffle's backend is licensed under AGPL-3.0 and its workflows and apps under MIT, so there is no license fee to pay for the platform code, but you still pay for servers, storage for OpenSearch, and the people who rewrite and test workflows. Recurring costs include infrastructure, upkeep and any support retainer you choose. Ask any provider, including DeployOpen, for a quote built from a written scope that lists each playbook, app and asset to migrate, your hosting model and your support expectations. Shuffle's paid tiers differ in feature limits, scaling and support, so confirm which tier your required features need before you compare totals.
How long does a Splunk SOAR to Shuffle migration take?
Timeline depends on how many playbooks you run, how much custom Python they contain and how many integrations must be re-authenticated. Teams with a small set of standard playbooks usually move faster than teams with dozens of custom functions that call internal systems. Factors that extend the schedule include testing against live alert sources, change approval windows and high availability design. Shuffle's install guide notes that the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM, so sizing and architecture choices belong early in the plan. Agree on a timeline in writing only after an inventory of playbooks and apps is complete.
What does our team need to provide during the move?
You need people who understand your current Splunk SOAR playbooks, the business purpose of each one and the systems they touch. Your team should export playbooks from Splunk SOAR as .tgz archives, list every asset and app configuration, and identify the owners of each integration. Someone must also own the Shuffle environment after go-live, including the SHUFFLE_ENCRYPTION_MODIFIER secret. The docs warn that losing or changing it breaks all saved app authentications, so it must be stored and backed up securely. Plan time for security review, change approval and analyst testing of rebuilt workflows.
Can our own team migrate from Splunk SOAR to Shuffle without outside help?
Yes, a capable team can attempt it, especially for a small number of standard playbooks and a single Shuffle server. The harder parts are rewriting Python custom functions as Shuffle apps, building apps from OpenAPI specifications in the App Creator where needed, and designing high availability with an OpenSearch cluster, shared files and more than one Orborus node. Shuffle's configuration docs describe these high availability components. Decide honestly whether your team has the Docker, Kubernetes and Python skills, and the time, to run this alongside daily operations. Outside help is commonly scoped as a fixed engagement with written deliverables, which you can compare with an internal plan.
Does Shuffle work with a SIEM other than Splunk?
Shuffle is a SOAR platform that connects to many tools through its app catalog, so a non-Splunk SIEM can usually act as the alert source. Shuffle ships premade apps for security tools and includes an App Creator that builds integrations from OpenAPI specifications. Confirm that a premade app or an OpenAPI definition exists for your specific SIEM version, and test how alerts arrive, whether by webhook, polling or a connector, before you commit. Splunk alert workflows can be kept in place as sources while the response logic moves to Shuffle.
Does Shuffle cover case handling the way Splunk SOAR does?
Shuffle focuses on workflow automation, meaning triggers, actions, branching and app execution, and you should confirm whether its case and container features meet your analysts' needs. Splunk SOAR provides analyst-facing case and container views that many teams depend on. If case handling is central to your process, map each analyst view you use today to a Shuffle capability, or to a separate case management tool, and test it with real analysts before deciding. Shuffle's documentation is the place to verify current case features.
Is a hosted Shuffle option available instead of self-hosting?
Yes. Shuffle offers a hosted cloud service at shuffler.io as an alternative to self-hosting. It also documents a hybrid architecture in which Shuffle Cloud is paired with a local Orborus that needs no inbound firewall ports, which can suit environments where alert data must stay inside your network. Choose hosted, hybrid or fully self-hosted based on data residency, your team's capacity and your compliance requirements. Confirm current hosting terms and data locations with Shuffle before you decide.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Splunk SOAR vs Shuffle decision, we start with a written scope that tests your playbooks, apps, SIEM integration and licensing position against what you actually need.
How we scope
- Inventory your Splunk SOAR playbooks, apps, assets and custom Python functions before estimating any rewrite work.
- Confirm whether your app run volume and seat count fit Shuffle's app-run licensing model in your own environment.
- Agree deliverables, timelines and exclusions in writing before work starts, since most engagements are fixed-scope.
How we build
- Deploy Shuffle in the architecture your environment requires, such as Docker Compose, Docker Swarm, Kubernetes or a hybrid with local Orborus.
- Rebuild priority integrations as Shuffle apps, using the App Creator from OpenAPI specifications or the Python app SDK.
- Test workflow execution, credential encryption, SSO and high availability settings against documented acceptance criteria.
How we hand over
- Document architecture, workflow inventory, app authentication mapping and the secret used for credential encryption, with its recovery procedure.
- Walk your security operations and platform teams through running, troubleshooting and changing workflows and apps.
- Deliver backup and upgrade runbooks so your team can operate the platform without ongoing dependence on us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Re-test workflows and integrations after Shuffle upgrades or SIEM changes, and report findings in writing.
- Prepare controls and evidence for your compliance assessments, while independent auditors issue any formal reports.
