Which open-source alternatives to Splunk SOAR fit your situation
Shuffle and StackStorm are the main self-hosted candidates for replacing Splunk SOAR, with n8n as a source-available option that carries licensing limits. If your renewal, licensing change, data residency rule or lock-in concern has pushed you to look elsewhere, start by deciding whether you need a visual workflow builder for analysts (Shuffle fits that pattern more directly) or an event-driven automation engine that engineers script in Python (StackStorm is built around that model). n8n can be useful for lighter workflows, but its Sustainable Use License permits internal business use and non-commercial use only, and files marked .ee require a valid n8n Enterprise License, so confirm with your legal team whether your intended use is covered before you build on it.
Teams usually start looking because of how Splunk SOAR is deployed and where its tooling is heading. Splunk offers Splunk SOAR (Cloud) as a SaaS solution hosted and managed by Splunk, and Splunk SOAR (On-premises) for organizations that must keep the platform in their own environment. If your residency or control requirements sit between those two options, you will want to know exactly where your playbooks and case data would run. Splunk also notes that the classic playbook editor was deprecated in 2024, so any playbook authored in that editor is a rebuild candidate regardless of platform. Ask your current vendor which editor your playbooks use, and inventory them by trigger, integration and custom function before you compare replacements.
Shuffle, StackStorm and n8n compared for SOAR replacement
Each option below replaces part of what Splunk SOAR does, but they differ in license terms, runtime model and how much rebuilding your team faces. Read the licensing and install requirements before you compare playbook features, because those decide what you can run in your own environment.
Shuffle
Shuffle is the option most often compared directly with a SOAR product. Its backend is licensed under AGPLv3, while workflows, documentation, apps and app specifications fall under MIT, so check with counsel how the AGPLv3 terms apply if you modify and host the backend for others. Its app creator builds integrations from OpenAPI specifications, and it ships premade apps for common security tools. Plan for OpenSearch as its database and confirm the Docker Compose default suits your scale, because the install guide says it is not scalable without changes. The install guide also sets a minimum of 4 GB of RAM.
StackStorm
StackStorm is Apache 2.0 licensed event-driven automation, aimed at auto-remediation, incident response, troubleshooting and deployments. Its strength is code-first automation written in Python, which suits engineering teams that already maintain scripts behind Splunk SOAR playbooks. The 3.9.0 release is dated January 12, 2025, and supports Python 3.8 to 3.11. Expect to rewrite custom actions and confirm that your Python version and pymongo dependencies match the release notes. Its interface is less of a security case manager than Splunk SOAR, so plan separate handling for case records.
n8n
n8n is distributed under the Sustainable Use License, which permits internal business and non-commercial use, and it is source-available rather than OSI open source. Files marked .ee need a valid n8n Enterprise License, so confirm which features your playbooks depend on before you build around them. It fits teams that want visual, general-purpose automation with many HTTP integrations and can accept the license terms. Ask legal whether your planned use, including use by a managed service provider, stays within the license before you commit to it as a SOAR replacement.
How Splunk SOAR capabilities map to open-source options
This table compares the main Splunk SOAR capabilities with Shuffle, StackStorm and n8n, and marks where each open-source option has a gap or needs confirmation. Read each row as a question to test against the version you plan to run, since feature depth changes between releases. The main takeaway is that playbook logic and alert intake usually transfer with effort, while app coverage and case management need the most validation before you commit.
| Capability | Shuffle | StackStorm and n8n |
|---|---|---|
| Playbook authoring | Visual workflow editor; Splunk playbooks must be rebuilt as workflows, not imported directly | StackStorm uses YAML workflows and Python actions; n8n uses a visual node editor with code nodes |
| Playbook .tgz export and import | No direct import of Splunk .tgz archives; confirm current tooling before planning | No direct import of Splunk .tgz archives; expect manual translation of each playbook |
| App and integration coverage | Premade apps for common security tools; app creator builds integrations from OpenAPI specifications | StackStorm offers packs; n8n offers many connectors. Confirm coverage for each Splunk app you use |
| On-premises deployment | Docker and Kubernetes install; default Compose setup needs changes to scale; minimum 4 GB RAM | Self-hosted in your infrastructure; confirm supported platforms and sizing in current install docs |
| Cloud deployment | Hosted option at shuffler.io exists, but data residency must be confirmed against your requirements | Hosting is your responsibility unless you use a vendor-hosted option; confirm terms for n8n |
| Case and event management | Gap likely: confirm whether native case management meets your analyst workflow | Gap likely: StackStorm and n8n are not case management tools; plan a separate ticketing or case system |
| Splunk or Wazuh alert ingestion | Webhook and API triggers can receive alerts; confirm Splunk and Wazuh app support | Webhooks and API calls can receive alerts; confirm Splunk and Wazuh integration path in your version |
| Licensing for internal use | Backend under AGPLv3; workflows and apps under MIT | StackStorm is Apache 2.0; n8n Sustainable Use License limits some commercial use |
What happens to Splunk SOAR playbooks and Python custom code
Exported playbook archives are the starting inventory, not the migration. Splunk documents exporting and importing playbooks as .tgz playbook archives, and those files record the logic of each playbook: the action blocks, decision points, and the apps and custom functions they call. That logic does not translate directly into a Shuffle workflow or a StackStorm action and sensor. Shuffle builds workflows from its own apps and triggers, and StackStorm organizes automation around actions, rules and sensors, so each playbook is normally rebuilt on the target platform and then tested against the same inputs and expected outputs. Plan for the rebuild effort to be the largest line item in the project, and ask any implementer to price it from a playbook-by-playbook inventory rather than from the archive count.
Custom Python functions need a separate review. Splunk's own migration guidance for moving from on-premises to cloud states that custom code must be converted to Python 3 first, so the first check is whether each custom function already runs under Python 3 and which third-party libraries it imports. Record the function name, the calling playbooks, the external systems it reaches and its credentials. Functions that only wrap a vendor API are often easiest to replace with a Shuffle app generated from an OpenAPI specification or a StackStorm action pack. Functions that hold business logic, such as enrichment scoring or ticket routing, should move with their tests intact. Confirm the Python version each target platform uses in its install documentation before you commit to a language target.
Finally, identify every playbook that depends on the classic playbook editor. Splunk notes that the classic editor was deprecated in 2024, so any playbook built or maintained there is a candidate for rebuild regardless of platform choice. Export each playbook, record its editor type, owner, trigger, last successful run and the apps it uses, and mark playbooks that have not run in a long period as candidates for retirement instead of migration. Run the inventory against your change records so that no scheduled or event-driven playbook is missed. The output of this review becomes the scope document that sets the rebuild plan and the parallel-run period.
What the open-source route costs compared with a Splunk SOAR subscription
This table lists the cost components on each side of the decision and marks which are one-time and which recur. Use it to structure a quote request, since no price list is published for Splunk SOAR or for an implementation, and the sizing drivers show where the cost moves.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Splunk SOAR license or subscription | Splunk, through a subscription or license agreement | Recurring | Deployment model (Cloud or On-premises), entitlement scope and renewal terms. Confirm current terms in your Splunk agreement. |
| Open-source platform software (Shuffle or StackStorm) | No license fee for the core software; Shuffle's backend is AGPLv3 and StackStorm is Apache 2.0 | One-time setup, then recurring upgrades | Upgrade frequency and number of components you operate. Check the license terms for your use case with counsel. |
| Hosting infrastructure | Your cloud account, data center or internal platform team | Recurring | Shuffle needs at least 4 GB of RAM and uses OpenSearch as its database; scaling beyond the default Docker Compose setup needs changes. Ask the implementer for a sizing plan based on your alert volume. |
| Implementation and playbook rebuild | Implementation partner or internal engineers | One-time | Number of Splunk SOAR playbooks, custom Python functions and apps. Splunk requires custom code to be converted to Python 3 before cloud migration, which adds effort. |
| Integration rebuild | Implementation partner or internal engineers | One-time | Count of vendor apps needing replacement. Shuffle's app creator builds integrations from OpenAPI specifications, which can reduce custom work where specs exist. |
| Migration testing and validation | Internal SOC staff and implementation partner | One-time | Number of playbooks run in parallel with Splunk SOAR and the test coverage agreed in advance. |
| Support and maintenance | Internal platform team or a retainer with an implementer | Recurring | Hours of on-call coverage, patch cadence and whether upgrades are handled in house. Ask for response expectations in writing. |
| Internal skills and training | Your staff | One-time and recurring | Existing Python and container skills in the team. Staff turnover raises the cost of keeping the platform running. |
| Alert source (Splunk or Wazuh) | Existing tooling owner | Mostly unchanged | Whether Splunk remains the alert source. Confirm log ingestion and licensing for any data you keep sending to Splunk. |
What you give up when you leave Splunk SOAR
Leaving Splunk SOAR means accepting a different support model, a different integration catalog and a different event experience. Each card below names one area where the commercial platform is likely to do more out of the box, and the workaround most teams use to close the gap.
Vendor-maintained apps and support SLAs
Splunk SOAR apps are maintained by Splunk or partners, and a commercial contract usually sets the response times you can rely on. With a self-hosted platform, you own app upkeep, patching and the on-call path for failures. Shuffle's app creator can build an integration from an OpenAPI specification, which shortens the work for APIs that publish one. Before you leave, ask whether a retained support contract with a vendor or implementation partner covers the apps you depend on, and who fixes a broken app at 2 a.m.
Breadth of premade integrations
Splunk's catalog covers a long list of security products, and teams often assume every connector they use today has a ready-made equivalent. Shuffle ships premade apps for common security tools, but coverage for niche or internal systems is uneven. Make a list of every app and action your playbooks call, mark each as premade, OpenAPI-buildable or custom, and check the premade ones against your current versions before you commit.
Splunk-native case and event experience
Analysts working inside Splunk often rely on native notable events, correlation context and case handling that were built to sit next to the SIEM. A self-hosted orchestration layer does not replicate that tight coupling by default. Map which analyst actions happen in Splunk today and which move to a separate case tool, then decide whether alert ingestion through the Splunk API is enough or whether analysts need a second screen during the transition.
Custom packs for StackStorm environments
StackStorm is event-driven and built around Python actions and packs, so teams with engineering skills can package their own integrations and sensors. This suits environments that already run automation code, but it moves maintenance onto your developers. Plan one owner per pack, version control for every action and a test path before any pack reaches production response workflows.
n8n license limits for commercial use
n8n is distributed under the Sustainable Use License, which permits internal business and non-commercial use but is source-available rather than OSI open source. Files marked .ee require an Enterprise License. If you plan to offer automation as a service to customers, or to embed it in a product, have counsel read the license terms before you build on it. Confirm with n8n exactly which use cases your organization falls under.
How to migrate off Splunk SOAR in seven phases
This sequence moves playbooks, apps and settings off Splunk SOAR into a self-hosted target while the existing alert source keeps running, so each cutover decision rests on evidence from a parallel run. The output is a tested replacement workflow set, a documented cutover and a retired Splunk SOAR instance.
Inventory playbooks, apps and custom functions
Your team lists every playbook, installed app, custom function and scheduled action in the current Splunk SOAR instance, and records which alerts or containment actions each one serves. Mark which items are triggered by Splunk or Wazuh alerts, which are called manually by analysts, and which depend on custom code. The inventory is done when every item has an owner, a business purpose and a disposition: migrate, rebuild, retire or keep in Splunk.
Export archives and admin settings
Export each playbook as a .tgz playbook archive from the Splunk SOAR interface, and document administration settings, app configurations and custom functions separately, since the archive does not replace them. Store the archives under version control with checksums, and record which Splunk SOAR version produced them. The step is complete when every inventoried item has a stored export and a settings record that someone other than the author has reviewed. Note that classic playbook editor content was deprecated in 2024, so confirm which format each playbook uses before you plan a rewrite.
Map playbooks to target workflows
Map each playbook step to a target construct: a Shuffle workflow with its apps, a StackStorm action or rule, or another platform you have shortlisted. Custom Python code needs a decision, either a rewrite into the target's app or action format or a call to an internal API. Confirm each target integration against the vendor's current app list and API documentation, since not every Splunk SOAR app has a direct equivalent. The output is a mapping sheet that flags each gap, such as a missing connector or a feature with no open-source counterpart, with a named owner and a decision.
Pilot low-risk playbooks
Rebuild two or three low-risk playbooks, such as enrichment lookups or ticket creation, in the target platform and run them against non-production or sandboxed data. Your engineers check outputs against the Splunk SOAR results for identical inputs, and document every difference. Because Shuffle runs workflow executions through Orborus and needs a sized database, record the resource sizing you actually used during the pilot, not a number from a vendor page. The pilot is done when outputs match for the agreed test cases and the team has a repeatable build procedure.
Run in parallel against the existing alert source
Keep Splunk SOAR and the alert feed, whether Splunk or Wazuh, running unchanged while the new platform receives the same alerts. Compare which playbooks fire, what actions they take and where they diverge, but configure the new platform in a mode that cannot execute live containment until cutover is approved. Track every divergence, its root cause and its fix in a shared log. The parallel run closes when the security operations lead signs off that divergences are resolved or accepted, and the alert source has not been reconfigured for the new platform.
Cut over playbooks in controlled batches
Move production playbooks to the target platform in batches, starting with the lowest-impact group, and switch the alert routing for each batch only after its parallel run has passed. Keep a rollback path that re-enables the Splunk SOAR playbook for each batch until the batch has operated without incident for an agreed period. Record the cutover time, the approver and the rollback state for each batch. The cutover is complete when every migrated playbook runs on the target platform and the rollback paths are documented.
Decommission Splunk SOAR and archive evidence
After the last batch is stable, disable Splunk SOAR playbooks, retain the exported archives, settings, logs and parallel-run records for the period your retention policy requires, and then shut down the instance or cancel the subscription. Confirm with your contract owner and your data protection lead what happens to stored case data, and whether any export obligations apply before deletion. The step is complete when the decommission record is approved and the retained evidence is stored in a location your auditors can access.
Which open-source option fits each situation
When the main driver is keeping security telemetry, playbook data and case records inside your own network or cloud accounts, self-hosting is the direct answer. Shuffle and StackStorm both run in infrastructure you control, so no workflow data has to leave your boundary. Shuffle installs on Docker or Kubernetes, and its 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. StackStorm runs as a self-managed Python service stack that fits teams already operating their own hosts.
- Deployment target: Confirm whether you need a single node, a highly available cluster, or an air-gapped build, since Shuffle's default Compose file is not production-scalable.
- Data stores: Shuffle uses OpenSearch as its database, so that store holds execution history and must be placed and backed up inside your boundary.
- Hosted option trap: Shuffle offers a hosted cloud at shuffler.io, which would not meet a strict residency rule, so exclude it early.
- Alert source: Keeping Splunk or Wazuh as the alert source means the detection data stays where it already lives, and only orchestration moves.
- Main risk: Self-hosting moves uptime, patching and backup onto your team.
Before committing, confirm with your data protection owner exactly which fields the workflows will write to logs and databases.
Open-source cores remove per-seat or per-automation license fees, but the total cost shifts to infrastructure and labor. Shuffle's backend is AGPLv3 and its workflows, apps and app specifications are MIT, so the core software itself carries no license charge for most internal use. The recurring costs are the hosts or clusters, the database and storage, and the engineers who build, maintain and upgrade integrations. Tines offers a free edition with a cap of 3 live workflows, which can help small pilots, but growth quickly reaches paid tiers.
- One-time costs: Playbook rebuilds, integration development and initial hardening are paid once, typically to an internal team or a fixed-scope implementation partner.
- Recurring costs: Compute, storage, OpenSearch capacity, backups and on-call coverage repeat every month.
- Cost drivers: The number of playbooks, integrations and alert volume set the infrastructure size and the maintenance load.
- Quote request: Ask any partner for a line-item breakdown covering build, test, handover, and retainer support, tied to a written scope.
- Main risk: Underestimating maintenance labor makes a free core more expensive than the product it replaces.
Compare the full three-year cost of staff time and hosting against your current renewal before deciding.
Teams whose automation depends on custom Python logic, internal APIs or bespoke enrichment usually fit StackStorm best. StackStorm is Apache 2.0 licensed event-driven automation, and its 3.9.0 release, dated January 12, 2025, supports Python 3.8 to 3.11 and moved to pymongo 4.x. Actions, sensors and rules are written as code, so existing Splunk SOAR Python functions can often be ported into a repository and tested like any other software. Shuffle fits better when teams want a visual builder and prefer to generate integrations from OpenAPI specifications through its app creator.
- Language fit: Python-heavy teams can reuse much of their existing logic, but they must confirm which Python version their functions need.
- Exported playbooks: Splunk SOAR playbooks are exported as .tgz archives, and these must be read and rewritten, not imported directly.
- Version control: Keeping automation in Git gives reviews, tests and rollbacks that many SOAR teams lack.
- Visual versus code: Analysts who build playbooks visually may find StackStorm's code-first model slower until they learn it.
- Main risk: Custom code becomes a maintenance burden if the original author leaves and documentation is thin.
Check your largest custom functions first, since they set the real rewrite effort.
In banking, healthcare, public sector and critical infrastructure, the question is less about features and more about evidence. Open-source platforms can support controls over access, logging, change management and vendor risk, but they do not arrive with an audit report. Confirm the license obligations first: Shuffle's AGPLv3 backend has copyleft terms that your legal team should review if you modify and expose it, while n8n's Sustainable Use License is source-available rather than OSI open source and restricts some uses. Plan the evidence set with your auditor before the build begins.
- License review: Have counsel confirm the terms of each component, including MIT, Apache 2.0, AGPLv3 and any source-available license.
- Evidence needs: Ask the auditor which records, such as change logs, access reviews and backup tests, they will require from the platform.
- Hardening scope: Access control, secrets handling, audit logging and patch cadence should be documented as controls.
- Assessment body: Independent auditors and certification bodies issue reports, not implementation partners.
- Main risk: Discovering a license or evidence gap after go-live can force a rebuild.
Agree the control list and license position with your auditor and counsel before any integration work starts.
Questions teams ask before replacing Splunk SOAR
How long does it take to migrate away from Splunk SOAR?
No supplied figure gives a fixed duration, so the honest answer is that the timeline is set by what you have to move. The main drivers are the number of playbooks, how many use custom Python code, how many apps and custom functions are in use, and how many integrations must be rebuilt and tested against live tools. Splunk documents that moving from Splunk SOAR (On-premises) to Splunk SOAR (Cloud) requires converting custom code to Python 3 first, so teams with large custom codebases should expect that step to dominate. Ask any provider for a written scope that inventories playbooks, apps and custom functions before agreeing a schedule. Phased cutovers, where low-risk playbooks move first and critical response paths move last, usually take longer but reduce operational risk.
Can our team migrate from Splunk SOAR without outside help?
Yes, a capable internal team can migrate without an outside partner, but the decision depends on your capacity and the size of your estate. A small set of standard playbooks with few custom integrations is a reasonable internal project. Larger estates with many custom functions, compliance evidence requirements or high availability needs tend to benefit from outside help with planning, hardening and testing. If you engage a partner, DeployOpen works under fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list, so a quote follows from that written scope.
What skills do our staff need to run a self-hosted SOAR platform?
Your staff need skills in container or server operations, database administration, identity and secrets management, and Python or JavaScript for playbook logic, depending on the platform you choose. Shuffle installs through Docker or Kubernetes, and its install guide notes that the default Docker Compose setup is not scalable without changes and needs a minimum of 4 GB of RAM. Shuffle uses OpenSearch as its database, with Elasticsearch also supported, so someone must operate that data layer. StackStorm is built around Python, which means Python 3.8 to 3.11 support in its 3.9.0 release, so Python developers must own its actions and rules. Confirm each platform's current requirements against its documentation before sizing your team.
Can Splunk or Wazuh remain our alert source after we replace Splunk SOAR?
Yes, the alert source and the response platform are separate decisions, so you can keep Splunk as your SIEM while moving response workflows elsewhere. The new platform needs a reliable way to receive alerts from Splunk, typically through the Splunk API or alert actions that send events to a webhook, which you must test end to end. Wazuh can serve the same role as an alert source, and it is commonly paired with open-source orchestration. Confirm the exact integration method for your Splunk version and your Wazuh deployment with the vendor and with the platform's integration documentation, and test alert volume, deduplication and field mapping before cutover.
How does licensing differ between Shuffle and n8n?
Shuffle and n8n license their code differently, and the difference matters for commercial use. According to the Shuffle GitHub repository, Shuffle's backend is licensed under AGPLv3, while its workflows, documentation, apps and app specifications are licensed under MIT. n8n is distributed under the Sustainable Use License, which permits use for internal business purposes or non-commercial or personal use, and files marked .ee require a valid n8n Enterprise License, so n8n is source-available rather than OSI open source. Have your legal team review the license text for your exact use, including whether you plan to offer workflows to customers or modify the code.
Can we import our Splunk SOAR playbooks directly into an open-source platform?
No, you should not expect a direct import. Splunk documents exporting and importing playbooks as .tgz playbook archives, which is useful for inventory and reference, but those archives are built for Splunk SOAR's own execution model. Splunk also notes that the classic playbook editor was deprecated in 2024. In practice, each playbook's logic is read, mapped to the target platform's workflow model and rebuilt, and each integration is recreated with its credentials and tests. Shuffle's app creator can build integrations from OpenAPI specifications, which can reduce the work for tools that publish specifications. Plan to rebuild rather than convert, and keep the original archives as the reference for expected behavior.
What does a migration cost, and what recurs after it?
Costs fall into one-time work and recurring operations. One-time costs include discovery, playbook and integration rebuilds, custom code conversion, testing, cutover and any hardening or documentation you need. Recurring costs include infrastructure to host the platform, database and backup operations, upgrades, licenses where applicable, and staff time for maintenance. The main cost drivers are the number of playbooks, the amount of custom Python, the number of integrations, and your availability and compliance requirements. Ask any provider to split the quote into discovery, build, testing and ongoing support, and to state what is included in the fixed scope and what would be a change request. Infrastructure figures should come from your own cloud or data center pricing, since no supplied source gives them.
Should we consider a hosted option instead of self-hosting?
A hosted option can be appropriate if your main goal is to reduce operations, but it changes where your data and control sit. Shuffle offers a hosted cloud service at shuffler.io as an alternative to self-hosting, and Tines lists a Free edition with 3 live workflows along with paid editions that offer flexible deployment options, with hosting options available on request according to its pricing FAQ. If you have data residency, air-gap or control requirements, self-hosting inside your own accounts or data centers is the reason most teams take this path. Confirm which deployment models meet your data handling rules before comparing costs.
Keeping Splunk or Wazuh as the alert source during the move
Replacing the SOAR layer does not require replacing the SIEM or detection layer. Your existing Splunk searches or Wazuh rules can keep producing alerts while the response workflows move to a new platform. The practical work is connecting those alerts to the new orchestrator, so that each alert type reaches the right workflow with the fields the workflow expects. In a Splunk environment, this usually means keeping the saved searches and alert actions that currently call Splunk SOAR, then pointing them at a webhook or API endpoint on the new platform. In a Wazuh environment, it means keeping the existing rules and the integration that forwards alerts, then confirming the payload structure the new platform receives.
Before cutover, confirm three things in each option's integration documentation. First, which trigger types it accepts for inbound events (webhook, API polling, or a dedicated app), and whether authentication uses a token, a header, or mutual TLS. Second, how it maps incoming JSON fields to workflow variables, because Splunk and Wazuh alert payloads differ in field names and nesting, and a field renamed during the move will silently break branching logic. Third, whether it can deduplicate or throttle repeated alerts, since a noisy correlation search can open many duplicate cases if the new platform does not handle repeats the way the old one did. Test each alert type with a replayed sample event in a non-production instance before you change the live alert action.
Plan for a period where both platforms receive the same alerts. Run the old and new workflows in parallel, compare case counts and enrichment results for a defined window, and record every alert type that produces a difference. Keep the Splunk SOAR or Wazuh forwarding configuration documented and reversible until the parallel run is signed off. Ask your implementation partner, and confirm with each platform's vendor, how the new system authenticates back to Splunk or Wazuh if a workflow needs to close an alert or update its status, since write-back permissions are often the last item to be scoped and the first to be questioned in a review.
