Splunk SOAR cost vs self-hosted Shuffle

Is Splunk SOAR cost higher than self-hosted Shuffle for your team?

Self-hosted Shuffle removes the seat-based license, but it does not remove cost. Whether it ends up cheaper than Splunk SOAR depends on three things: how many workflow actions your team runs each month, whether your team can operate a multi-component platform, and how much existing Splunk SOAR content must be rebuilt. Shuffle prices on app runs, meaning actions that actually execute in a workflow, and its pricing article states that users, apps and workflows are unlimited. That shifts the cost from who logs in to how much the platform does. Before you compare, pull your last twelve months of Splunk SOAR renewal terms and your own count of executed actions, and ask Splunk for a written quote for the edition you would keep. No Splunk SOAR price is given here, so take your own quote and set it against the Shuffle components below.

Shuffle's cost is mostly infrastructure and labor. The install guide sets a minimum of 4 GB of RAM, but that is a floor for a test install, not a production sizing. The architecture docs describe a single Docker Compose server, Docker Swarm, a hybrid with Shuffle Cloud, and Kubernetes with Helm charts, and the configuration docs recommend an OpenSearch cluster, optional Memcached, NFS for shared files when several backends run, and more than one Orborus node for high availability. Each of those is a server, a storage class, a backup target and an on-call duty. Ask your platform team to price those components in your own cloud or data center, and to estimate OpenSearch storage from your retention policy and expected case and execution volume. Plan for the one-time migration as well, because Shuffle apps are built from OpenAPI specifications or written in Python, so existing Splunk SOAR custom functions and playbooks must be rewritten rather than copied.

Treat the comparison as a decision with three inputs, not a single number. Price the Splunk SOAR path using your renewal or cloud migration terms, including the Python 3 conversion work the cloud path requires. Price the Shuffle path using server, OpenSearch, backup, upgrade and staff time, plus the rewrite effort for each playbook you must keep. Then ask whether a fixed-scope implementation partner would carry the build and handover, and what the written scope would cover. Where the numbers are close, the deciding factors are usually how many playbooks you truly need to move and whether your team already runs OpenSearch or Kubernetes in production.

Which cost components change when you move from Splunk SOAR to Shuffle

This table shows which cost components move when a team leaves Splunk SOAR (on-premises or cloud) for self-hosted Shuffle, and who carries each one. Read the Splunk column as the items to raise in a quote and the Shuffle column as the work your team or implementation partner would take on. Shuffle's open-source edition has no license fee, but its paid tiers change limits, scaling and support, and Splunk SOAR (Cloud) moves hosting out of the buyer's hands.

Cost component	Splunk SOAR (on-premises or cloud)	Self-hosted Shuffle	One-time or recurring
Subscription or license	Recurring Splunk license under the agreement; confirm seat, action and tenant terms in writing	Open-source edition has no license fee; paid tiers differ in limits, scaling and support	Recurring
Infrastructure (compute, storage, backup)	On-premises: buyer-owned servers and backups. Cloud: hosted and managed by Splunk	Buyer-owned servers or Kubernetes nodes; minimum 4 GB RAM per install guide, more for high availability	Recurring
OpenSearch storage	On-premises: buyer sizes and backs up storage. Cloud: managed by Splunk, confirm retention terms	Buyer sizes an OpenSearch cluster and its backups; the docs recommend a cluster for high availability	Recurring
Implementation	Installation, integration and configuration, done by Splunk partners or internal staff	Install, Orborus nodes, SSO, backups and app setup, done internally or under a fixed-scope engagement	One-time
Playbook and custom code migration	Export playbooks as .tgz archives; a move to Splunk SOAR (Cloud) requires converting custom code to Python 3 first	Rebuild playbooks as Shuffle workflows and rewrite custom Python functions as apps	One-time
Integration and app authentication	Apps and assets must be configured again after a move	Credentials are encrypted in OpenSearch; keep the SHUFFLE_ENCRYPTION_MODIFIER secret safe, since losing it breaks saved authentications	One-time setup, then recurring upkeep
Support	Vendor support under the Splunk contract; confirm response times and scope	Community support on the open-source edition; paid support depends on tier, so confirm terms in writing	Recurring
Upgrades	Cloud upgrades are vendor-managed; on-premises upgrades follow Splunk's supported versions	Buyer or partner applies releases by Docker tag and tests them first, since the docs recommend this for stable and experimental builds	Recurring
Internal skills and monitoring	Admins need Splunk SOAR skills; cloud platform monitoring is largely run by Splunk	Team runs OpenSearch, containers, Orborus and backups, and owns monitoring and alerting	Recurring

What moves the Splunk SOAR and Shuffle comparison most

Splunk SOAR is priced around seats and deployment model, while self-hosted Shuffle is priced on app runs for its paid tiers and carries infrastructure and staffing costs you own. The cards below cover the variables that change which side comes out ahead, and what to measure in your environment before requesting quotes.

Monthly app runs and action volume

Shuffle's licensing counts 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 cost curve depends on how many automated actions run each month, not on how many people build or view playbooks. Measure executed actions per month from current Splunk SOAR action logs, separating enrichment calls from containment steps, and ask Shuffle how its paid tiers map to that count.

Analyst seats and admin headcount

Seat-based Splunk SOAR licensing grows with each analyst who needs access, so adding responders raises the license line directly. With Shuffle, adding users does not change the license metric, but more analysts still mean more build and review work for the team. Count named analysts, engineers and read-only stakeholders who need access, then ask both vendors to price the same headcount in writing.

Data retention and OpenSearch storage growth

Shuffle stores its documents, including workflow execution records, in OpenSearch, so retention settings and execution volume drive disk growth on infrastructure you pay for. Longer retention and more executions mean larger volumes, bigger backups and more capacity planning. Measure the size of current execution and case data over a representative period, set a retention period with your compliance team, and estimate storage growth from that figure rather than from vendor defaults.

Availability requirements and extra Orborus nodes

Shuffle's high availability guidance recommends an OpenSearch cluster, a shared cache, shared file storage when running several backends, and more than one Orborus node so workflows keep running if one fails. Each of these adds servers, licenses for supporting components, and operational hours. If your Splunk SOAR runs as a single system today, a fair comparison must include the extra capacity you would need to match its uptime expectations. Confirm your target availability with the business owners before sizing.

Custom Python functions and apps to rewrite

Every custom Python function, app and playbook you keep in Splunk SOAR is effort to rebuild in Shuffle, either as an app created from an OpenAPI specification or as a Python app written with the Shuffle SDK. Playbooks that only call common tools convert more cheaply than those carrying heavy custom logic. Inventory playbooks, custom functions and app assets, then tag each as reuse, rebuild or retire. Rewrite effort is usually the largest one-time cost in a move.

Team skills in Docker, Kubernetes and OpenSearch

Shuffle installs with Docker or Kubernetes, and its install guide notes that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM. Running it well requires people who can operate containers, Helm charts and an OpenSearch cluster, and who can keep the encryption secret safe, since losing it breaks saved app authentications. Assess the skills you already have, decide whether to train staff or bring in an implementation partner, and price that time into the comparison.

How each deployment option shifts cost between license and operations

Splunk hosts and manages this option as a SaaS service, so Splunk carries the infrastructure and the platform updates that come with the managed service. Your organization pays the subscription and keeps ownership of the playbooks, custom functions and asset configurations that run inside the tenant.

Hosting and platform patching: Splunk runs the infrastructure and applies service-side changes as part of the managed offering.
Subscription: The recurring fee follows your Splunk agreement, so ask for a written breakdown of seats, actions and any add-ons.
Playbooks and integrations: Your team still builds, tests and maintains playbooks and their connections to other tools.
Custom code: Splunk's migration documentation says custom code must be converted to Python 3 before it moves from on-premises to Cloud.
Data location: Confirm where case and playbook data is stored and which regions are available.

Check the hosting, upgrade and data location terms in writing, because the managed scope determines how much operational work stays with your team.

You install Shuffle on your own servers with Docker Compose, Docker Swarm or Kubernetes with Helm charts. You pay for the infrastructure, the staff time and any support contract, and you own every upgrade. The Shuffle install guide says the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM.

Scaling: Single-node Compose is a starting point. The configuration docs recommend an OpenSearch cluster, optional Memcached, NFS for shared files and more than one Orborus node for high availability.
Upgrades and patching: Your team picks the image tags, using the latest Docker tag for stable releases and the nightly tag for experimental changes, and tests before rollout.
Credential key: Losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks all saved app authentications, so key custody and backups are standing operating tasks.
Database capacity: Shuffle uses OpenSearch as its document database, so plan disk capacity and retention with your platform team.
Support tiers: Shuffle says paid tiers differ in feature limits, scaling and support, so confirm the entitlements in writing if you need them.

Count the on-call hours for OpenSearch, Orborus and backups alongside the server line, because those operations make up most of this option's recurring effort.

What rewriting Splunk SOAR playbooks and custom functions costs in effort

Most of the cost of moving from Splunk SOAR to self-hosted Shuffle is labor, not software. The work falls into three parts: exporting playbooks as .tgz archives, rewriting Python custom functions as Shuffle apps, and mapping Splunk SOAR apps and assets to Shuffle app authentication. Your internal automation engineers or a partner you hire will do most of this work, and a one-time migration effort is paid for by the hour or by the fixed scope agreed in writing. Shuffle apps are built either from OpenAPI specifications in the App Creator or written in Python with the Shuffle app SDK, so each custom function needs a decision about which route fits it. Export the archives with the steps in the Splunk documentation on exporting and importing playbooks before you change anything.

Start with an inventory. List every playbook, note which editor it was built in, and count the custom functions each one calls. Splunk documented that the classic playbook editor was deprecated in 2024, so a large set of classic playbooks means more rebuilding than a set built in the newer editor. Then sort each custom function into one of three groups: reuse (the logic is short and the target API is stable), rewrite (the logic is needed but must be rebuilt as a Shuffle app), or retire (no current playbook depends on it). Record which apps and assets each function uses, because each asset's credentials must be recreated in Shuffle app authentication and stored under your SHUFFLE_ENCRYPTION_MODIFIER secret handling. If you plan a move to Splunk SOAR (Cloud) first, Splunk requires converting custom code to Python 3 beforehand, which adds effort that does not carry over to Shuffle.

No per-playbook duration is supplied for this migration, so do not budget from a generic estimate. Run a pilot on three to five representative playbooks, one of them with a custom function and one with an asset that needs authentication. Time each step, including testing against a non-production system, and use those measurements to price the full inventory. Ask any partner for a fixed-scope quote that lists the playbooks in scope, the functions to rewrite, the assets to remap and the testing you expect to see. Recurring costs after the move are small by comparison, mainly the time to maintain apps when the target APIs change.

How to build a Splunk SOAR and Shuffle cost model with your own numbers

This sequence turns a Splunk SOAR renewal and a Shuffle self-hosting plan into one comparable model, built from your seat counts, run volumes, hardware, storage, rewrite scope and staff time over the same period.

Collect the current Splunk SOAR renewal or cloud quote
Start with the written renewal or Splunk SOAR (Cloud) quote from Splunk or your reseller. Record the licensed seat count, the term, the deployment type (cloud or on-premises), the support tier and any included add-ons. Ask the vendor to confirm in writing what each line covers and whether the price changes at renewal. Done when you have one sheet listing every recurring charge and its end date, with no figure taken from a public list price.
Count monthly action and app run volume
Pull execution counts from your own Splunk SOAR logs and from any SIEM or ticketing data that drives playbooks. Separate the Splunk SOAR action count from the Shuffle app run count, since Shuffle bills on app runs, meaning actions that execute in a workflow, while triggers and skipped actions are not counted. Count a typical month and a peak month so spikes are visible. Done when you have monthly figures for each metric, with a note on where each number came from.
Size Shuffle servers against the minimum and your HA layout
Shuffle's install guide sets a minimum of 4 GB of RAM and notes that the default Docker Compose setup is not scalable without changes. Decide whether a single server is enough or whether you need the high availability layout from the configuration docs: an OpenSearch cluster, several backends, shared storage and more than one Orborus node. Price the servers, load balancing and backups for that layout using your own cloud or data center rates. Done when you have a bill of materials for each environment, including a non-production copy.
Estimate OpenSearch storage from your retention policy
Shuffle uses OpenSearch as its database, so storage grows with workflow executions and stored data. Multiply your monthly execution volume by the retention period your policy requires, then add headroom for indices, replicas and backups. Confirm the replication and snapshot settings with your OpenSearch operator or partner. Done when you have a storage figure in gigabytes for the retention period, with each assumption written next to it so an auditor or finance reviewer can follow it.
Scope the playbook and custom function rewrite
Inventory every Splunk SOAR playbook, app, asset and custom Python function, and export the playbooks as .tgz archives. Classify each item as a simple rebuild, a Shuffle app built from an OpenAPI specification, or a custom Python rewrite using the Shuffle app SDK. Ask a partner for a fixed-scope proposal that lists the items, deliverables, testing and handover in writing. Done when the rewrite has a signed scope with a one-time cost and a clear list of what is excluded.
Add support, upgrades and internal staff time
Record the recurring effort on both sides. On the Splunk side, note any upgrade work tied to version support and the cost of moving to Splunk SOAR (Cloud), including converting custom code to Python 3 where it applies. On the Shuffle side, include patching, upgrades, backups, monitoring, secrets handling such as the SHUFFLE_ENCRYPTION_MODIFIER, and whether a retainer covers them. Estimate hours with your own team leads. Done when each recurring activity has an owner, a monthly effort figure and a source.
Compare one-time and recurring totals over one period
Place both models on the same time horizon and split each into one-time costs (rewrite, migration, initial servers, testing) and recurring costs (licenses or app run charges, hosting, storage growth, support, staff time). Run the comparison with your low, expected and high volume assumptions so the sensitivity is visible. Ask each vendor and partner to confirm the written scope and terms behind every figure rather than relying on list prices. Done when a single table shows both options with the same assumptions and the open questions that could change the result.

Costs teams forget on each side of the comparison

Licence fees are the visible line in any SOAR comparison, but most of the total cost sits in upkeep that nobody budgets for. The cards below list the items on the Splunk SOAR side and the Shuffle side that a reader can check against their own environment before signing or migrating.

App and connector upkeep

Every Splunk SOAR app and asset your playbooks depend on has its own version, configuration and credentials to maintain. Before comparing prices, list the apps in use, who owns each one, and how often vendor updates are applied in your environment. On Shuffle, the same work shows up as versioned app containers and app authentication to maintain, so the count of integrations matters on both sides.

On-premises upgrade effort

Keeping a Splunk SOAR (On-premises) deployment current is a recurring internal task with testing, change windows and rollback planning. Confirm the supported version window in Splunk's documentation and estimate the staff time your team spends on each upgrade cycle. Include the regression testing of playbooks, because an upgrade is not finished until those flows run again.

Custom code conversion before a cloud move

Splunk documents that moving to Splunk SOAR (Cloud) requires converting custom code to Python 3 first. Inventory every custom function and playbook that calls it, and count how many need changes. This is effort your team pays for, whether or not the move goes ahead, so record it as a cost line in the comparison.

Encryption secret lifecycle

Shuffle encrypts saved app credentials and API keys in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing this value breaks every saved app authentication, so the secret must sit in a documented vault with backup and rotation rules agreed in advance. Confirm who holds it, where it is stored, and how a restore would be tested.

OpenSearch backups and HA cluster

Shuffle stores its documents in OpenSearch, and the docs recommend a cluster for high availability. Backups, snapshot storage, disk growth and cluster health checks are costs your team carries after go-live. Ask who will run restore drills and how much storage a year of execution history will need in your environment.

SSO and monitoring of Orborus nodes

Shuffle supports SAML and OpenID Connect single sign-on, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Set up identity configuration and per-tenant enforcement as a project task, and monitor each Orborus node, since workflows keep running only while enough nodes are healthy. Both need alerting and an owner.

Paid tier decision on app runs

Shuffle prices its enterprise tiers on app runs, and since v2.1.1 the open-source and enterprise limits are actively enforced. Estimate your monthly action volume from current playbook traffic and check it against the limits in the pricing article before deploying. Ask Shuffle which tier fits your run volume, scaling needs and support level.

What buyers ask about the cost and effort of moving from Splunk SOAR to Shuffle

Does moving from Splunk SOAR to Shuffle lower costs for a small team?

It can, but the saving depends on what you currently pay and what you add. Shuffle's open-source edition includes all features, and its pricing article describes a single metric, app runs, with users, apps and workflows unlimited. Your costs then shift to the servers that run Shuffle, OpenSearch storage, the people who build and maintain playbooks, and any support retainer you buy. Splunk SOAR costs also depend on your license type and deployment, so compare your current invoice line by line against a written scope from an implementation partner and your own infrastructure estimate. Ask your Splunk account team which license terms apply to your current seats and actions before you build the comparison.

How long does a migration from Splunk SOAR to Shuffle take?

The supplied facts do not give a duration, so measure it with a pilot before you commit to a schedule. The main drivers are how many playbooks you run, how many use Python custom functions that must be rewritten as Shuffle apps, how many apps and assets need authentication rebuilt, and how many alert sources must be reconnected. Start with a small set of high-value playbooks, time each rewrite and test cycle, and extrapolate from that data. Export your existing playbooks as .tgz archives first so you know the inventory. A fixed-scope engagement can set deliverables and timelines in writing once that inventory exists.

Can our internal team migrate to Shuffle without outside help?

Many teams can, provided they have engineers who are comfortable with containers and Python and who have time to learn the Shuffle model. The work is not only playbook conversion. You also need a stable deployment, a plan for scaling, backups and upgrades, and a secrets owner. Shuffle's configuration docs recommend an OpenSearch cluster, a shared cache, shared files and more than one Orborus node for high availability, so a single-server pilot does not show the full run cost. Assess your bench honestly, and if gaps exist, scope outside help for the specific parts you cannot cover in time.

What skills does the team need for a Shuffle deployment?

You need operators who can run Docker or Kubernetes and understand how Shuffle's frontend, Go backend and OpenSearch fit together. Shuffle's install guide lists Docker and Kubernetes as installation options and notes that the default Docker Compose setup is not scalable without changes. Your team also needs Python skills for custom apps, since Shuffle apps can be built from OpenAPI specifications in the App Creator or written with the Python app SDK. Assign one owner for SHUFFLE_ENCRYPTION_MODIFIER, because losing or changing it breaks all saved app authentications. Confirm the skill list against your own environment and the current docs before you staff the project.

What costs recur after a Shuffle go-live?

Recurring costs fall into four groups. The first is servers for the backend, frontend, Orborus nodes and OpenSearch, which grow with workflow volume and high availability needs. The second is storage for OpenSearch data, which grows with execution history and retention settings. The third is upgrades, since Shuffle publishes new releases and you must test them against your apps before you adopt them. The fourth is support, whether that is internal staff time or an ongoing retainer for upgrades, continuous testing and assistance. Ask any quote to separate one-time migration work from these recurring items so you can compare year-over-year totals.

Does Shuffle Cloud reduce the operational work?

Yes, it removes server and database operation, but it changes where your data and control sit. Shuffle offers a hosted service at shuffler.io as an alternative to self-hosting. Shuffle's architecture docs also describe a hybrid model in which Shuffle Cloud is paired with a local Orborus that needs no inbound firewall ports, so your runtime can stay inside your network. Compare the hosted option with your data residency and access requirements, and confirm current terms and pricing directly with Shuffle before you decide.

What should a fixed-scope quote for this migration include?

A fixed-scope quote should list the written scope, deliverables, timeline and acceptance criteria before work starts. Ask for the playbook and app inventory, the list of playbooks to rewrite, the list of apps and assets to re-authenticate, and the target architecture, such as single-server Docker Compose, Docker Swarm or Kubernetes with Helm. Ask how secrets, SSO and backups will be handled, what the cutover and rollback plan is, and what documentation and evidence you receive. Confirm which items recur, such as retainers for upgrades or testing, and what is excluded. DeployOpen issues quotes only from a written scope.

What risks should we check before we commit to the move?

Check four risks before you commit. First, confirm that the Python custom functions you depend on can be rewritten and tested as Shuffle apps. Second, plan the encryption secret and credential migration, because saved app authentications depend on it. Third, verify your high-availability design, since the default single-server setup is not a scalable build. Fourth, confirm your SSO path: Shuffle supports SAML and OpenID Connect, but SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Document each risk with an owner and a test before the cutover date.

How DeployOpen scopes a fixed-price Shuffle implementation and what it hands over

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Splunk SOAR cost comparison against self-hosted Shuffle, we start by putting the current licensing, playbook inventory and hosting facts into a written scope before any build work begins.

How we scope

We inventory your current Splunk SOAR licenses, seats or action counts, deployment type and cloud or on-premises footprint.
We list every playbook, custom function and app, and mark which ones need rewriting as Shuffle workflows or apps.
We agree the written scope, deliverables and timeline with you before work starts, since most engagements are fixed-scope.

How we build

We size the Shuffle deployment with you, choosing between single-server Docker Compose, Docker Swarm, hybrid with a local Orborus, or Kubernetes with Helm.
We set up the OpenSearch backend, the Orborus runtime nodes and the encryption secret for saved app credentials, then rebuild integrations with the App Creator or the Python app SDK.
We test each migrated workflow against sample alerts in a non-production environment before any cutover.

How we hand over

We document the architecture, workflow inventory, app credentials handling and backup procedure in a form your own engineers can operate.
We record the cost components we scoped, including the servers, OpenSearch storage and the effort to rewrite playbooks, so your finance and security teams can compare them with the current contract.
We confirm with you which items you own after handover, such as the secret store, configuration files and access controls.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover Shuffle version upgrades, such as moving to a newer release, with testing of your workflows before each change.
Before you sign, ask us to confirm in writing which environment, responsibilities and response arrangements the retainer includes.