Does self-hosting Shuffle cost less than renewing Cortex XSOAR?
The license line disappears for Shuffle's open-source edition, but it does not disappear from the budget. If your renewal notice is forcing a decision, the honest comparison is the XSOAR subscription against the servers, OpenSearch storage, app development and staff or partner hours that Shuffle needs in its place. Shuffle's pricing article says its paid licensing is metered on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Your cost therefore tracks automation volume, so pull a real count of executed actions per month from your current XSOAR usage before comparing.
The answer depends on three variables: how many automated actions you run, how many integrations you must build or maintain, and how much analyst and engineering time goes into keeping them working. Shuffle's open source article states that all features are available in the open-source edition, while its paid tiers differ in feature limits, scaling and support. That means the open-source edition is not a cut-down trial, but it also means that scaling and vendor support are the points where a paid tier may be needed. Ask Shuffle directly which limits and support terms apply to your expected volume. The install guide sets a minimum of 4 GB of RAM for a single node, but a production deployment with OpenSearch, several Orborus nodes and high availability will need more capacity, so size it with your own load tests.
This page gives no Cortex XSOAR or Shuffle enterprise prices. Get the XSOAR renewal quote in writing, itemized by license and any support or deployment element, and then build a three-year model that includes one-time items (migration, app rebuilds, initial hardening) and recurring items (servers, storage, backups, upgrades, on-call support). Confirm with your own infrastructure team what the hosting and storage cost is in your environment, and request a written scope from any implementation partner before you commit to a timeline.
Which cost components each option carries
This table lists each cost component for Cortex XSOAR and self-hosted Shuffle, showing who is paid, whether the cost is one-time or recurring, and what drives it. Use it to build your own comparison, then replace every Cortex line with figures from your contract and quote.
| Cost component | Cortex XSOAR (6 on premises or 8) | Self-hosted Shuffle |
|---|---|---|
| License or subscription | Recurring fee paid to Palo Alto Networks, set by your contract. Confirm the renewal figure and term in your own agreement, and check whether your deployment is 6 on premises or 8 SaaS or on premises. | No license fee for the open-source edition, since the backend is AGPLv3 and workflows and apps are MIT. Shuffle's pricing article describes app-run based licensing for its paid tiers, which is a separate recurring line to check. |
| Shuffle enterprise tier or Shuffle Cloud (separate line) | Not applicable | Only if you buy enterprise features or use the hosted service at shuffler.io. Ask Shuffle whether your required features sit in the open-source edition, and whether app-run charges apply at your expected volume. |
| Infrastructure | Little or none on your side for SaaS. For 6 or 8 on premises, you carry the servers, storage and hypervisor capacity the vendor specifies. | Recurring cloud or data center cost for servers, OpenSearch storage and Orborus nodes. The install guide sets a minimum of 4 GB of RAM, but production sizing for high availability needs more. |
| Implementation and content build | Recurring internal or partner effort to configure playbooks, integrations and incident layouts that already exist in the platform. | One-time effort to build apps from OpenAPI specifications or Python, and to rebuild playbooks. Partner fees are set by a written scope. |
| Migration | Export effort for custom content and playbooks, documented in Palo Alto's export steps. Usually one-time and sized by how much custom content you hold. | One-time effort to rebuild integrations and triggers and to run both platforms in parallel. Driven by the number of playbooks and tools you move. |
| Support and vendor fees | Support is typically bundled in the subscription. Confirm the support tier, response terms and any add-on charges in your contract. | Community support is free. Paid support, when chosen, is a recurring line set by Shuffle's support terms. Ask for the scope in writing. |
| Upgrades and maintenance | Included in the subscription for supported versions. Plan for version changes, including end-of-life dates your contract or vendor notices name. | Internal or partner effort for each Shuffle release, plus testing of apps and workflows against new versions. Release timing is published on the Shuffle GitHub releases page. |
| Internal skills and operations | Analysts and engineers who know XSOAR playbooks and the Cortex ecosystem. Recurring salary cost, usually smaller for SaaS. | Platform engineers for Docker, Kubernetes, OpenSearch and secret handling, plus app developers. Recurring salary or contractor cost that rises with the number of apps. |
| Backup and secret handling | Covered by the vendor for SaaS. For on premises, budget your own backup and recovery effort. | Your responsibility in every model. Losing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks all saved app authentications, so protect and back it up as part of setup. |
How Shuffle's app-run metric changes the bill
Shuffle's licensing is priced on one metric: app runs, meaning actions that actually execute inside a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. For a buyer comparing this with Cortex XSOAR, the practical question is no longer how many analysts or playbooks you have, but how many times your automation calls a tool. Your bill therefore tracks execution volume, so a team with few analysts but a noisy SIEM can still generate a large run count. Ask Shuffle to confirm in writing how the metric applies to your edition and tier, and whether any run allowance is included.
Run volume is driven by four things: the rate of alerts that enter a workflow, the number of enrichment steps each playbook performs per alert, the polling and retry behavior of your integrations, and how often a failed action is retried. A playbook that queries three threat intelligence sources, a directory and an EDR for every alert multiplies its run count by the alert rate. Polling and retries add runs that no analyst sees. Tuning deduplication and filtering before the workflow starts usually reduces runs more than any other change, and that work belongs in your plan.
To count runs from your own playbooks, export the current workflows and list every action per trigger path. Multiply each action by the expected alerts per day over a representative period, then add retries and scheduled polling. Use a week of real alert data from your SIEM, not an estimate. Compare the result with the limits of the open-source and enterprise editions. Since v2.1.1, those limits are actively enforced, so a count that exceeds the open-source limits means you need the enterprise edition or a different design. Confirm the current limits in the Shuffle configuration documentation before you sign anything.
What moves the comparison most
Cortex XSOAR and self-hosted Shuffle price differently on different units: one charges for the platform and its content, the other for executed actions and the infrastructure under it. The drivers below show which side each factor pushes toward, so you can size both options against your own volumes before asking for a quote.
Alert and execution volume
Shuffle's licensing is priced on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, while users, apps and workflows are unlimited. Higher alert volume that reaches automated actions raises the Shuffle run count, so measure how many actions per day your playbooks execute, then ask XSOAR's vendor how its license scales with the same volume.
Integrations to build and maintain
Shuffle ships premade apps for many security tools and builds new ones from OpenAPI specifications in its App Creator or with the Python SDK. Each custom integration then needs an owner for versioning and credential rotation. XSOAR's certified content catalog may cover more of your tools out of the box, so count the integrations you need and how many already exist as maintained apps.
Analysts and playbook editors
Shuffle does not charge per user, so adding analysts or playbook authors leaves its license unchanged. The cost moves into staff time for training and workflow review. Check how XSOAR prices user seats in your contract and how many people will build or edit workflows, since that count drives the seat line on the XSOAR side.
Availability requirements
Shuffle's docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files across several backends, a scaled backend and frontend, and more than one Orborus node so workflows keep running if one fails. Each of these adds servers, storage and monitoring effort. If your response playbooks must run during an outage, the self-hosted side carries that redundancy cost directly, while XSOAR's vendor-managed SaaS shifts some of it into the subscription.
Data volume in OpenSearch
Shuffle stores its workflow executions, results and app configuration in OpenSearch, so storage grows with execution history and retention settings. Plan disk, snapshot and backup capacity from your expected run history, and remember that losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks all saved app authentications. Ask XSOAR's vendor which data stays in its service and which you must retain yourself.
Internal skills and support hours
Self-hosting moves operating, upgrading and troubleshooting work onto your team or a support partner. That covers Docker or Kubernetes administration, OpenSearch tuning and app development. Estimate the monthly hours your engineers can spare for these tasks, and compare them with the vendor support tier included in an XSOAR subscription, using a written scope for any outside help.
How to build the comparison with your own numbers
This sequence turns the renewal quote and your alert volume into a three-year cost model for XSOAR and self-hosted Shuffle, with each cost line traced to a figure you can defend. Use it before you ask either vendor or DeployOpen for a number.
Pull the current XSOAR license and renewal terms
Ask the account owner or procurement lead for the signed order form, the license metric, the term length, the renewal uplift clause and any included capacity or support tier. Confirm whether the contract covers XSOAR 6 on premises or XSOAR 8 as SaaS or on premises, because the deployment model changes the infrastructure lines later. Done when you have one page listing the annual fee, the metric and the notice date for renewal.
Inventory playbooks, integrations and custom content
Export the custom content from the XSOAR server settings and count playbooks, scripts and integrations, marking which ones are vendor-supplied and which were written in-house. Flag any JavaScript integrations or logic tied to XSOAR's runtime, since those will need rebuilding rather than copying. Done when every item has a row with its owner, its connected system and an estimated complexity rating you can explain to a second reviewer.
Estimate monthly app runs from alert volume
Shuffle's pricing metric counts app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Pull your SIEM alert volume for a representative month, then multiply the alerts that reach each workflow by the number of executed actions per path. Test the estimate by running a sample of alerts through a trial workflow and counting the executed actions. Done when you have a monthly run figure with a low and high case, and you know the number is an estimate from your own traffic.
Size Shuffle servers and the high availability layer
The install guide sets a minimum of 4 GB of RAM and notes that the default Docker Compose setup is not scalable without changes. The architecture docs describe a single server, Docker Swarm, a hybrid with Shuffle Cloud and Orborus, and Kubernetes with Helm. For high availability, the configuration docs recommend an OpenSearch cluster, Memcached, NFS for shared files, more than one backend and more than one Orborus node. Ask your platform team to price the nodes, load balancer, shared storage and backups for the architecture you pick. Done when you have a server bill for production and for a non-production copy.
Cost OpenSearch storage for your retention period
Shuffle uses OpenSearch as its document database, so storage grows with stored workflow executions and case data. Multiply your average daily execution record size by the retention period your compliance team requires, then add replicas, snapshot storage and headroom. Confirm the retention policy with your compliance owner before you run the number. Done when you have a storage figure in gigabytes for year one and year three, along with the backup target that holds it.
Price app development per integration
Shuffle builds apps either in the App Creator from an OpenAPI specification or in Python with the app SDK, and each app runs as a versioned container. For each integration in your inventory, record whether a premade app exists, whether an OpenAPI specification is available, or whether custom Python is needed. Attach a day-rate or hours estimate from your engineers or from a fixed-scope quote, and ask for the cost of ongoing version updates. Done when every integration has a build type and an estimated effort, and the total is split into one-time build and recurring maintenance.
Add support, internal hours and the three-year view
Add the internal hours for on-call response, upgrades, SSO setup and encryption key management, since losing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks saved app authentications. Include any paid Shuffle tier or support contract, and any retainer you choose for upgrades or testing. Lay out three years of costs side by side: XSOAR renewals with the uplift applied, and Shuffle infrastructure, storage, app builds, support and staff time. Label the result as illustrative until you replace the inputs with quotes. Done when the model shows year-by-year totals for both options and a list of the assumptions you would need to change to flip the result.
Questions buyers ask before comparing cost
What does a Cortex XSOAR renewal typically include?
A Cortex XSOAR renewal is a subscription for the platform itself, and the exact contents depend on your contract, so read the order form before comparing it to anything else. Ask your Palo Alto Networks account team to confirm which deployment you are licensed for (XSOAR 6 on premises or XSOAR 8 as SaaS or on premises), how the license is measured, which integrations and content packs are included, whether support and upgrades sit inside the subscription, and what the term and renewal uplift clauses say. Also check whether your version is still in support, since XSOAR 6.12 and 6.13 reach end of life on June 30, 2026. Infrastructure, storage and the staff who run the platform are usually not in the renewal line, so add them separately.
Can a team run Shuffle without a partner?
Yes, a team with Linux, Docker or Kubernetes, and OpenSearch experience can install and run Shuffle without an outside firm. The install guide covers Docker and Kubernetes, and the architecture docs describe a single-server Docker Compose setup, a Docker Swarm layout, a hybrid with Shuffle Cloud and Kubernetes with Helm charts. The harder parts are usually high availability, credential encryption key handling, SSO configuration and building apps for tools your SOC uses. Whether you need help depends on how many people you can spare and how quickly you must go live. A partner is one option for a fixed scope, and you can also keep the work in-house and use outside testing for review.
How long does a migration take, and what drives it?
The duration depends on the number of playbooks, the number of integrations you must rebuild, and how many use cases must run side by side with XSOAR. No timeline applies to every environment, so ask for an inventory before you commit to dates. The main drivers are how much custom content exports cleanly, how many integrations exist as OpenAPI specifications or need a Python app, the complexity of incident triggers from your SIEM, and how long your analysts need to validate results. Teams that keep XSOAR running during the change usually plan a period of parallel operation for each use case.
What work must our own team provide after go-live?
Your team must own the playbook logic, the platform administration and the app catalog. Playbook owners decide how cases are handled and approve changes. Someone must administer OpenSearch, including backups, capacity, index health and the upgrade path, because Shuffle stores its data there. Your engineers maintain the apps, which means updating them when vendor APIs change and testing them before each release. Also plan for the SHUFFLE_ENCRYPTION_MODIFIER secret, since losing or changing it breaks every saved app authentication. Ask whether a retainer covering upgrades and testing is part of the scope, and budget the internal hours either way.
How does Shuffle count app runs for licensing?
Shuffle prices on app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited under the pricing model described in the Shuffle pricing article. Your run volume therefore depends on how many automated actions each alert triggers, how many alerts reach workflows, and how often you retry failed steps. For example, an illustrative workflow that enriches each alert with three lookups and two containment actions would consume runs only for the actions that execute, not for the trigger that starts it. Model your alert volume against that rule before you assume a cost, and confirm the current terms with Shuffle.
Does Shuffle Cloud at shuffler.io change the cost comparison?
Shuffle Cloud changes the cost model by moving server operations to the vendor, but it does not remove the work of building workflows and apps. Shuffle documents a hybrid option where Shuffle Cloud is paired with a local Orborus that needs no inbound firewall ports, which can keep execution inside your network. Compare the hosted option against self-hosting by listing who runs the backend, OpenSearch, upgrades and backups, and where data and credentials are stored. If you have data residency or air-gap requirements, confirm the hosting location and the hybrid design with Shuffle before you choose the model.
What should a quote for self-hosted Shuffle include?
A useful quote lists each component as its own line so you can compare it to the XSOAR renewal. Ask for the scope of the architecture (single server, Swarm or Kubernetes), the high availability design with OpenSearch cluster sizing and more than one Orborus node, the app work (how many OpenAPI-based apps and Python apps), the SSO setup using SAML or OpenID Connect, the backup and upgrade process, and the support hours. Also ask what is one-time and what recurs, which servers and storage are assumed, and who owns the infrastructure. DeployOpen issues quotes from a written, fixed scope, so the scope conversation comes first.
Do we need a full migration to compare costs fairly?
No, a fair comparison can start with one or two use cases. Pick a workflow that runs often, such as phishing triage or endpoint containment, and cost it on both platforms: the XSOAR share of the renewal, plus the servers and OpenSearch storage for Shuffle, plus the app and playbook build hours and the ongoing support time. Running that pilot side by side shows you the operating effort and the run volume you will actually pay for. It also reveals gaps early, such as cases and analyst war room needs that Shuffle does not provide by itself.
What a migration from XSOAR adds to the first year
The one-time migration work is the cost most often missing from a first-year comparison, and it lands in the same budget year as the Shuffle servers and the first app runs. Start by inventorying what XSOAR holds. In Cortex XSOAR 8, the export path runs from Settings, then Server Settings, then Custom content, then Export all custom content, and individual playbooks can be downloaded from the content item menu. Count playbooks, scripts, integrations and classifiers separately, because each one needs a different rebuild effort. The exported files are a starting inventory, not a finished migration, since XSOAR content does not map one to one onto Shuffle workflows and apps. Confirm the export formats for your XSOAR version with Palo Alto Networks before you estimate effort.
Rebuilding integrations is the largest line item. Each XSOAR integration that you rely on has to become a Shuffle app, either generated in the App Creator from an OpenAPI specification or written in Python with the Shuffle app SDK, and each app runs as a versioned Docker container that your team must build, test, version and patch. Budget for the people who know the target systems, the credentials to rotate into Shuffle's encrypted store, and the test cases that prove each action behaves as the playbook expected. Re-creating incident triggers from your SIEM is a separate task that many plans skip. Each alert source must be pointed at a Shuffle webhook or app trigger, and the detection owners must confirm the payloads still carry the fields the workflow reads.
Running both platforms side by side per use case is the cost that stretches the first year. Keep XSOAR live for the playbooks you have not moved, cut over one use case at a time, and compare outcomes such as run success, time to first action and analyst corrections before retiring each XSOAR playbook. The sibling migration page covers the step sequence, and a fixed-scope written plan, agreed before work starts, is the practical way to cap this period. Ask any implementation partner to price the inventory, rebuild, trigger and parallel-run phases as separate line items, and ask your Palo Alto Networks account team which XSOAR licensing terms apply to the overlap months.
Further questions on Shuffle licensing and comparison
Does Shuffle charge per user or per workflow?
No. Shuffle prices its licensing on one metric, app runs, and states that users, apps and workflows are unlimited. An app run is an action that actually executes inside a workflow. A team can add analysts, connect more tools and build more playbooks without a seat-based increase in the bill, so your cost tracks how much automated work the platform performs. Ask for the quote to model a month of expected executions from your SIEM alert volume and enrichment steps, then compare that count against the run allowance and any overage terms. Confirm the current terms in writing, because the Shuffle pricing article describes the model rather than a fixed figure for your organization.
What counts as an app run in Shuffle?
An app run is an action that executes in a workflow. Triggers and skipped actions do not count toward it. This matters for cost modeling because the largest share of automation volume is usually repeated enrichment, such as looking up the same indicator in several tools for every alert. Workflow design changes the count. A conditional check that ends a branch early avoids billable actions, while a broad playbook that queries every service on every alert multiplies them. Before you commit, run your highest-volume playbook against a sample of recent alert history in a test environment and count the executed actions. Use that count, not a generic estimate, when you ask vendors and partners for a quote.
How much memory does a self-hosted Shuffle server need?
The Shuffle install guide states a minimum of 4 GB of RAM, and it notes that the default Docker Compose setup is not a scalable build without changes. Treat that minimum as a starting point for a lab or proof of concept, not a production sizing. Production memory and CPU depend on execution volume, the number of concurrent workflows, OpenSearch index size, retention settings and whether you run one server or several. Shuffle documents deployment models from a single Docker Compose server to Kubernetes with Helm charts, and each carries different hardware and operations effort. Ask your platform team to benchmark a representative workload in staging and carry the result into the infrastructure line of your cost model.
Why does Shuffle need OpenSearch and who maintains it?
Shuffle uses OpenSearch as its document database, and Elasticsearch also works. The backend and frontend store workflows, execution records and saved configuration there, so the datastore becomes a cost line you must own. The configuration documentation recommends an OpenSearch cluster for high availability, which adds nodes, storage, backups, patching and index lifecycle management. Storage cost grows with execution history, so retention policy is a cost decision as well as a compliance one. Budget an engineer who understands OpenSearch operations, because a Shuffle deployment is only as available as its datastore. DeployOpen can plan, implement, harden and back up this layer inside your environment under a written scope, but your team still needs an owner who answers for it after go-live.
Does the Shuffle open-source edition lack features compared with paid tiers?
Shuffle states that all features are available in the open-source edition. Its paid tiers differ in feature limits, scaling and support. Since version 2.1.1, the limits between the open-source and enterprise editions are actively enforced, so a deployment that exceeds a limit will hit it in the product. Read the configuration documentation to see which limits apply to your edition and whether they affect execution volume, scaling or support response. The cost question is therefore whether you need paid scaling or support. If you plan a multi-node high availability design, confirm that design sits inside the open-source limits before you rely on it, and ask the vendor for the enforcement details in writing.
What happens if the Shuffle encryption modifier changes?
Losing or changing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks every saved app authentication. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using that secret, according to the configuration docs. The effect is operational: integrations stop authenticating until each credential is re-entered or restored, and playbooks that depend on them fail. Treat the value as a tier-one secret. Store it in your secrets manager, include it in your backup procedure and document recovery steps before go-live. Test a restore in a non-production environment so you know the secret and the OpenSearch backup match. Planning time for this runbook is often missing from initial estimates, so ask for it to appear as a separate item in any scope.
Does Shuffle support SAML or OpenID Connect single sign-on?
Yes. Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, and both are available on premises and in the cloud. Per-tenant SSO enforcement is supported. Shuffle is deprecating SAML on Shuffle Cloud in favor of OpenID Connect, so a new self-hosted deployment should be designed around OpenID Connect. Confirm which identity provider features your organization uses and test the login flow with a non-admin account, including group mapping for analyst roles. Ask your identity team to confirm that the identity provider they run supports the OpenID Connect flow Shuffle expects. Settle role design before go-live, since it controls who can edit playbooks and who can view credentials. The extensions documentation covers the SSO settings.
Can our engineers build their own Shuffle integrations?
Yes. Shuffle apps are built from OpenAPI specifications in the App Creator, or written in Python with the Shuffle app SDK, and they run as versioned Docker containers. For an internal ticketing or asset system that publishes an OpenAPI description, the App Creator can produce a first integration quickly, and Shuffle ships premade apps for common security tools. Custom apps still need testing, versioning, credential handling and a named maintenance owner. Every new app adds a container image to build, scan and patch. Include that engineering time in the total cost of ownership, not only the license line. When requesting a quote, ask for the initial build, testing and ongoing maintenance to be priced separately, and list the number of integrations in scope. The apps documentation explains the build options.
How DeployOpen scopes a fixed-scope Shuffle implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Cortex XSOAR cost comparison, we start with a written scope that prices out your current subscription, servers, OpenSearch storage, app development and support hours before any build work begins.
How we scope
- Inventory your current XSOAR license terms, deployment type and renewal date before comparing costs
- List every playbook and integration in use, marking which need an OpenAPI app or a Python app
- Agree in writing which deployment architecture fits your environment and what it needs in servers
How we build
- Deploy Shuffle on Docker or Kubernetes inside your own cloud accounts, data centers or air-gapped networks
- Size OpenSearch storage, Orborus nodes and high availability settings against your agreed workload
- Build and test priority apps and workflows, then record app run volumes against the licensing metric
How we hand over
- Document the architecture, configuration keys and the SHUFFLE_ENCRYPTION_MODIFIER backup procedure
- Deliver a cost model listing servers, storage, app development and support hours as separate lines
- Train your team on workflow ownership, app updates and the upgrade path before handover closes
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends
- Keep the recurring cost of app runs, hosting and support hours visible in each retainer review
- Confirm with your team which support hours and response expectations the written scope and retainer include
