When a free self-hosted SOAR alternative fits the Community License limits
If your team runs the free Splunk SOAR (On-premises) Community License and is nearing 100 licensed actions per day, one tenant or five open cases, the main no-license options are self-hosted Shuffle and the open-source edition of Tracecat. Both remove the Community ceilings, but they do so by moving you onto a different platform, with its own installation, playbook rewrite and operating effort. That trade-off is the core of this decision, and it should be made deliberately rather than by default.
This is a constraint page, so the limits matter more than the feature list. The Community License caps daily licensed actions, tenants and open cases, and a team that hits any one of them has to act regardless of how well the platform fits its playbooks. Before you compare products, confirm with Splunk how licensed actions are counted in your current playbooks, since loops, retries and failed runs can change the daily total. Then count your real open cases and tenants over a typical month, not a quiet week, so you know whether the ceiling is a near-term problem or a future one.
Shuffle counts app runs, meaning actions that actually execute in a workflow, and its open-source edition has no tenant or case ceilings of the Splunk kind, but its own enterprise limits are actively enforced. Tracecat's open-source edition is AGPL-3.0, while multi-tenant workspaces and SSO sit in its Enterprise Edition. Confirm the exact edition boundaries against the current documentation for whichever product you shortlist, and map which of your required features fall inside the free tier before you commit to a migration.
What the Community License limits require your team to plan for
The Community License sets three hard numbers and leaves the rest to your team. Each limit changes a different part of how you run automation, from playbook design to case intake to the monthly review. Confirm the current wording with Splunk before you build a plan around any of them.
Daily licensed action cap
The free tier allows 100 licensed actions per day. Every playbook step that counts against that figure draws from the same daily pool, so a busy alert queue or a looping playbook can use up the allowance before the working day ends. Ask Splunk exactly which steps count as a licensed action, whether the count resets at a fixed time, and what happens to playbooks that run after the cap is reached. Test your highest-volume playbook against that number before you depend on it.
Single tenant boundary
The Community License covers one tenant, so separate business units, customers or regulated environments must share one instance and one set of playbooks, assets and case data under the free terms. If a second group needs its own isolation, the team either accepts a shared access model or moves to paid terms. Confirm with Splunk how a tenant is defined, whether a separate on-premises instance would count as another tenant, and whether licensed actions are pooled across any future tenants.
Five open case limit
Only five open cases can exist at once. When a sixth incident arrives, analysts need a clear rule for triage, such as closing low-value items, merging duplicates or sending noise back to the SIEM instead of opening a case. Ask Splunk whether closing a case frees a slot immediately, whether cases created by automation count the same as analyst-opened cases, and whether any queue or overflow exists. Write the triage rule down before the limit is reached, because responders should not be inventing it during an active incident.
Watching usage against the limits
The three limits fail quietly unless someone is responsible for watching them. Assign a named owner to review the daily action count and open case total on a fixed schedule, set an internal alert threshold below each cap, and log every near-limit event with the playbook responsible. Shuffle counts app runs under its own pricing model, so do not compare its figures directly with Splunk's counts. Confirm with Splunk where usage appears in the console and whether it can send notifications.
How actions are counted and why teams miscount them
Teams that measure their Splunk SOAR Community License against the limit of 100 licensed actions per day usually count from the playbook canvas, and that is where miscounts start. A playbook with ten blocks does not guarantee ten executions, because branches, conditions and triggers decide what runs on a given day. Before estimating anything, confirm the exact counting rule in Splunk's documentation for the Community License, including how it treats a block that runs inside another action and a block that never executes. Any estimate is only as good as that definition.
Shuffle's pricing offers a useful comparison point because it meters one thing: app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted under that metric, while users, apps and workflows are unlimited, according to the Shuffle pricing article. Illustrative example: a workflow with a webhook trigger, one enrichment lookup and a conditional ticket update that is skipped on a clean alert would produce two app runs under that metric, while a team counting drawn blocks would tally four. Splunk's rule may differ, so treat the comparison as a set of questions for Splunk and do not carry any number across.
Run the test before any planning. Export a representative set of playbooks and, for each one, list every action that would execute on a typical alert, a high-volume alert and a skipped branch. Apply the Splunk counting rule to each list, then compare the totals with the daily action volume your team sees in its own logs. If the margin is thin, treat the Community License as a short-term bridge. Shuffle's open-source edition is a no-license starting point, but confirm its current limits in the Shuffle configuration docs before you rely on it.
Which free self-hosted options fit a no-license starting point
This table compares four self-hosted automation options on license, deployment model and the gaps to check before you commit. Read the license column first, because it decides whether the platform can run as an internal tool at your scale. Shuffle and Tracecat are the closest fits for SOAR-style response, while StackStorm and n8n need more validation for case handling and analyst workflows.
| Option | License | Self-hosting model | Gap to confirm |
|---|---|---|---|
| Shuffle | AGPLv3 backend, MIT workflows and apps | Docker Compose, Docker Swarm or Kubernetes with Helm. Default Compose needs changes to scale. | Users, apps and workflows are unlimited, but paid tiers enforce limits on app runs. Confirm your volume. |
| Tracecat open-source edition | AGPL-3.0 core, separate Enterprise Edition license | Docker Compose on one host, AWS ECS Fargate, Kubernetes with Helm, or air-gapped Kubernetes. | Case management is documented, but SSO and multi-tenant workspaces are Enterprise features. Confirm SSO needs. |
| StackStorm | Apache 2.0 | Self-hosted event-driven automation. Version 3.9.0 supports Python 3.8 to 3.11. | Strong for auto-remediation and sensors. Confirm analyst case views and SSO depth before adoption. |
| n8n | Sustainable Use License, source-available, not OSI open source | Self-hosted general workflow engine. Files marked .ee require an Enterprise License. | Not a SOAR product. Confirm the license covers your internal use and any service you provide to others. |
Shuffle or Tracecat as the first step off the Community License
If most of your alerts come from Splunk and you already maintain a library of Python playbooks, Shuffle is the better first step. Its app creator builds integrations from OpenAPI specifications, it ships premade apps for security tools, and its Python app SDK lets you rebuild custom functions as containerized apps. The install guide lists Docker and Kubernetes as installation options, with a minimum of 4 GB of RAM.
- Playbook export: Splunk documents exporting playbooks as .tgz archives, so you can review the logic before rebuilding anything in Shuffle.
- Custom functions: Each Python custom function becomes a Shuffle app with its own container and authentication model, so plan the rewrite one function at a time.
- Assets and credentials: Splunk assets must be recreated as Shuffle app authentications. Shuffle encrypts saved credentials with AES-256 using
SHUFFLE_ENCRYPTION_MODIFIER, so record that secret before the first save. - Alert source: Keep Splunk as the alert source and confirm the Shuffle trigger setup against your own alert format.
In a proof of concept, run your three most-used playbooks end to end, including approval steps and error handling, on your own execution hosts.
If you want case management and AI agent tooling in one platform, Tracecat is the product the facts support. It combines workflow automation, webhook triggers, case management, structured tables, custom AI agents with tools and MCP servers, and custom actions in an AGPL-3.0 open-source edition. The repository lists more than 100 prebuilt connectors and more than 50 hosted MCP servers.
- Case handling: Cases and tables sit beside workflows, so analysts can track an investigation in the same tool that runs the response steps.
- Agent tooling: Custom agents can call tools and MCP servers. Confirm what each agent may access and how its actions are logged before it touches production alerts.
- Connector coverage: The total count does not show coverage. Check that the connectors your playbooks depend on exist and work with your versions.
- Enterprise features: Authentication and single sign-on are described as Enterprise features, so include that edition in the cost comparison if your identity model requires it.
- Git integration: Custom actions synced from Git appear among the features, while Git version control integration is named as an Enterprise feature. Confirm which of these your change process needs.
In a proof of concept, take one alert from intake through an agent step to case closure, and confirm the audit trail at each stage.
When separation between customers or business units is the deciding factor, the edition question comes first. Tracecat lists multi-tenant workspace management as an Enterprise feature, so an MSSP evaluating Tracecat for separation should include that edition in its proof of concept. Shuffle documents per-tenant SSO enforcement and says its open-source edition limits have been actively enforced since v2.1.1, so confirm which isolation and scale features your model needs.
- Workspace model: Multi-tenant workspaces are an Enterprise feature in Tracecat. Do not assume the open-source edition separates customers.
- Identity per tenant: Shuffle added SAML in 0.9.16 and OpenID Connect in 1.0.0, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect.
- Edition limits: Shuffle states that all features are in the open-source edition and that paid tiers differ in feature limits, scaling and support. Get those limits in writing for your tenant count.
- Usage metering: Shuffle prices on app runs, while users, apps and workflows are unlimited. Track app runs per tenant so consumption can be charged back.
- Data isolation: Ask how credentials, cases and run logs are separated between tenants in the underlying OpenSearch or PostgreSQL stores.
In a proof of concept, set up two tenants with overlapping integrations and confirm that one tenant cannot see the other's cases, credentials or run history.
Both products can run on your own infrastructure, but their production footprints differ. Shuffle documents a single server with Docker Compose, distributed Docker Swarm, a hybrid model and Kubernetes with Helm charts. Tracecat documents single-host Docker Compose, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access.
- Shuffle high availability: The docs recommend an OpenSearch cluster, optional Memcached, NFS for shared files across several backends, and more than one Orborus node so workflows keep running if one fails.
- Shuffle hybrid model: A local Orborus needs no inbound firewall ports, which suits networks that cannot accept inbound connections from outside.
- Tracecat components: PostgreSQL, Temporal and an S3-compatible object store are separate services to back up, patch and monitor.
- Default setup: The default Docker Compose setup is not a scalable build without changes, so plan for that work before production.
- Air-gapped operation: Tracecat documents an air-gapped Kubernetes path. Ask Shuffle for its air-gapped procedure for your environment.
In a proof of concept, rehearse one backup and one restore of each data store, and ask each vendor for its reference architecture at your alert volume.
What the open-source editions leave out
The open-source editions are not identical to the paid products, so the first step is to confirm which limits apply to your scale before you commit. Shuffle states that all features are available in its open-source edition and that its paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced, so a workflow that runs fine in a test environment can hit a limit in production. Read the Shuffle open source article and the configuration documentation, then write down the execution volume, scaling and support level your team needs.
Tracecat's open-source edition is AGPL-3.0, but several capabilities are gated behind a separate Enterprise Edition license. According to the Tracecat repository, multi-tenant workspace management and Git version control integration are Enterprise features, and the Tracecat documentation describes authentication and single sign-on as enterprise features too. If your team needs separate workspaces for different business units, Git-based review of custom actions, or SSO against your identity provider, those requirements change the edition you need, not just the configuration. Confirm the current feature split in the Tracecat documentation and ask the vendor in writing which edition covers each requirement.
Before choosing either platform, map every feature your playbooks depend on against the edition documentation. List each playbook, the apps or connectors it calls, how it authenticates, whether it needs multi-tenancy or SSO, and who approves changes to it. Mark each item as included, limited or enterprise-only, and treat any unclear item as an open question. This list also feeds your quote request, because a fixed-scope implementation should name the editions, components and integrations being delivered. A feature that only appears in a paid tier is a cost to model now, not a surprise at renewal.
How to deploy Shuffle on your own servers without a license
This sequence takes a team from hardware check to a tested Shuffle deployment on its own servers, with encryption, high availability and single sign-on in place before any production playbook moves over. Each step ends with a check you can run yourself.
Confirm hardware and plan a scaled build
Confirm that each host meets the documented minimum of 4 GB of RAM, then decide whether the default Docker Compose setup is enough. The install guide says that setup is not a scalable build without changes, so a production plan needs a non-default configuration. Your infrastructure lead completes this step when the sizing and build plan are written down and reviewed.
Choose one of the documented architectures
Pick one of the four architectures Shuffle documents: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts. The choice depends on your container platform and whether execution must stay fully inside your network. The architecture decision is recorded and matches your platform team's standards.
Set up OpenSearch as the database
Deploy OpenSearch as the document database for Shuffle, with Elasticsearch as an alternative the docs also accept. For high availability, the configuration docs recommend an OpenSearch cluster rather than a single node. Your platform team confirms the cluster is healthy and that the Shuffle backend can read and write to it before continuing.
Store the encryption secret before saving credentials
Set the SHUFFLE_ENCRYPTION_MODIFIER secret in your secrets store and configure it for the backend before anyone saves an app credential or API key. Shuffle encrypts those values in OpenSearch with AES-256 using this secret, and the docs warn that losing or changing it breaks every saved app authentication. The check is a documented copy of the secret held in your secrets manager and a test credential that saves and decrypts correctly.
Add a second Orborus node for resilience
Run more than one Orborus node so workflow execution continues if one node fails, which the configuration docs recommend for high availability. Scale the backend and frontend across servers and add shared Memcached and NFS where your chosen design calls for them. Confirm success by stopping one Orborus node in a test environment and verifying that a test workflow still completes.
Configure single sign-on
Connect your identity provider using OpenID Connect, which Shuffle added in version 1.0.0, or SAML, which it added in 0.9.16 and is deprecating on Shuffle Cloud in favor of OpenID Connect. Confirm your version and the tenant-level SSO enforcement settings in the extensions docs before choosing. The step is done when an analyst signs in through your identity provider and an account without SSO access is blocked as expected.
Pilot a copy of your playbooks
Rebuild a small set of representative playbooks in a non-production Shuffle instance and run them against test alerts from your SIEM or other source. Use the App Creator for OpenAPI-based integrations and check that each app run behaves as expected. Your security engineering team signs off when the pilot results match the expected outcomes and any gaps are logged for remediation before cutover.
What reviewers ask for when automation moves off a licensed platform
Moving automation off a licensed platform leaves four evidence sets that reviewers ask for early. Each answers a different question: what the workflows do, how secrets are protected, who can change the platform, and whether the data can be restored. DeployOpen prepares this evidence in your environment, while independent auditors and certification bodies issue any assessment.
Workflow exports under version control
Keep every exported Shuffle workflow and every custom app specification in a Git repository, with the commit that changed each file and the reviewer who approved it. For a move from Splunk SOAR, this replaces the .tgz playbook archives the team exported earlier, so the record shows what ran before cutover and what runs now. Check that each workflow has a named owner, that app versions are pinned to specific container tags, and that the repository is access-controlled and backed up like any other system of record.
Encryption secret custody and rotation
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that value breaks every saved app authentication, so the custody record is the critical control. Document where the secret is stored, who can read it, how a change is approved, and which steps re-authenticate each app after a rotation. Ask whether a sealed copy is held outside the Shuffle host so that a single server failure does not end the automation.
SSO settings and administrator register
Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, with per-tenant SSO enforcement. Reviewers want the identity provider configuration showing which sign-in method is enforced, plus a current list of every person holding an administrative role. Record the review cadence for that list and the removal steps when someone leaves. Shuffle notes that SAML is being deprecated on its cloud in favor of OpenID Connect, so confirm which method your deployment will rely on before the register is finalized.
OpenSearch backup and restore records
Shuffle uses OpenSearch as its document database, and its high availability guidance recommends an OpenSearch cluster. Reviewers ask for the snapshot schedule, retention period and dated restore test results, including how long a restore took and who ran it. Confirm that snapshots are written to storage outside the cluster, and that a restore has been rehearsed in a separate environment rather than assumed. Workflow history and execution records sit in the same store, so the restore test should check them too.
What does leaving the Community License cost and take?
What are the cost components of leaving the Splunk SOAR Community License?
Leaving the Community License moves cost from one license line to five components: licenses, servers, OpenSearch storage, playbook rewrite effort, and upgrades and support. Shuffle's open-source edition includes all features and has no per-seat fee, but its paid tiers are priced on app runs, meaning actions that actually execute in a workflow, so confirm which tier you need. Servers must provide at least 4 GB of RAM according to the Shuffle install guide, and a highly available layout needs more than one node. OpenSearch storage grows with saved executions and case data. The playbook rewrite is usually the largest one-time item, because Python custom functions become Shuffle apps. Ask any provider to price each component as a separate line.
Which migration costs are one-time and which recur every year?
Setup, playbook rewrite, testing, credential re-entry and the cutover are one-time costs. Servers, storage, backups, monitoring, upgrades and support recur. The recurring share depends on how many nodes run, how much execution history you keep in OpenSearch, and how often you apply new releases. Shuffle publishes releases on GitHub and recommends the latest Docker tag for stable use, so plan regular upgrade windows and testing time. If you keep Splunk as the alert source during a parallel run, its license and infrastructure costs continue through that overlap, so include the overlap period in the budget. If you choose a paid Shuffle tier, app-run fees become a recurring line that rises with execution volume.
How many daily actions or open cases make a team outgrow the free tier?
The free Community License stops at 100 licensed actions per day, one tenant and five open cases. Teams usually outgrow it when daily action volume passes the cap, when a second business unit needs its own tenant, or when open cases accumulate faster than analysts close them. Splunk's counting rules decide what counts as a licensed action, so confirm the exact definition in Splunk's licensing documentation before you plan. Shuffle counts app runs, which are actions that actually execute, and excludes triggers and skipped actions, so the same playbook can register differently on each platform. Illustrative: a team running 150 enrichment actions a day would exceed the cap and need a plan before the volume grows further. Pull recent daily action counts from Splunk to find your own starting point.
How long does a Splunk SOAR to self-hosted migration take?
No migration duration is available for this page, so do not plan from a figure you have seen elsewhere. Ask for a written estimate that ties time to scope: the number of playbooks, custom functions to rewrite, apps and assets to reconnect, alert sources to re-point, and whether high availability is needed from the first day. DeployOpen plans most engagements as fixed scope, with deliverables and timelines agreed in writing before work starts. Ask the provider to separate firm items from assumptions, such as access to test systems and the availability of approvers. A short proof of concept on a few representative playbooks is a useful first step, and it should be quoted as its own scope so you can measure the rewrite effort before committing to the full set.
What does a migration need from our own team?
Expect your team to supply decisions and access, not only hours. Name one owner who knows each playbook and the business reason it exists. Provide exported playbook files, test environments, and credentials for every integration, plus approvers for the cutover. Infrastructure staff supply hosts, DNS, certificates, backups and network paths. Security staff must agree who holds the SHUFFLE_ENCRYPTION_MODIFIER secret, because the Shuffle configuration docs warn that losing or changing it breaks all saved app authentications. Python developers review converted custom code, and Splunk administrators confirm how alerts reach the new platform. Record this internal time as a line in the quote so it is planned and not discovered mid-project.
Can our team migrate from Splunk SOAR to Shuffle without outside help?
A capable team can migrate a small playbook set alone, but it needs Docker or Kubernetes skills, OpenSearch operations experience and Python for rewriting custom functions. Shuffle's install guide says the default Docker Compose setup is not scalable without changes, so production layouts need deliberate planning. High availability calls for an OpenSearch cluster, shared files when several backends run, and more than one Orborus node. If those skills are thin, a fixed-scope engagement can cover planning, implementation, hardening and documentation, and a retainer can cover upgrades and ongoing support afterward. Ask any provider for a written scope and compare it against your own skills inventory before you decide.
How DeployOpen moves a team off the Community License
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For teams that have hit the Splunk SOAR Community License limits, we scope a move to a self-hosted platform such as Shuffle in writing before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory licensed action volume, tenants, open cases and playbooks to size the target platform.
- The written scope names which playbooks move, which are retired and which integrations are reconnected.
- We confirm where the platform will run: cloud account, data center or air-gapped network.
How we build
- We install the chosen platform in your environment, using Docker or Kubernetes as your standards require.
- We rebuild priority playbooks as native workflows and integrations, then test each against sample alerts.
- We configure credential encryption, single sign-on and high availability settings as the scope specifies.
- Security testing of the deployed platform can be included in the written scope where your team requests it.
How we hand over
- Handover includes installation notes, workflow inventory, integration mapping and runbooks for your operators.
- We document how credential encryption secrets are stored and why changing them breaks saved authentications.
- Compliance readiness material is prepared as evidence for your own assessors, not as an audit or certification.
- Your team receives a rollback plan covering the period when the Community License workflows still run.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and upgrade cadence are set in writing, so your team can compare them with other options.
- Ask any provider to confirm how they handle backups of the platform database and its configuration.
- Ask for the written scope to list every licensed component so renewal and effort assumptions stay visible.
