What SOAR costs when you build, partner or buy SaaS
SOAR cost depends on who builds and maintains the playbooks, the worker infrastructure and the connectors, not on a license line alone. A security team choosing between open-source Shuffle, a partner-built deployment and a commercial SaaS should compare these three components across each option, because the license is often the smallest part of the first-year total. Shuffle's code is licensed under AGPL-3.0, and its documentation states that all features are available in the open-source edition. Its paid tiers differ in feature limits, scaling and support, and its licensing is priced 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. Tines lists a free edition with unlimited users, spaces and connectors but only 3 live workflows, so a team that expects more than three production playbooks will be looking at a paid edition from the start.
Several costs sit outside any license. Your team or a partner pays for playbook engineering and testing, for building or adapting Shuffle apps from OpenAPI specifications or the Python SDK, and for storing and rotating the credentials those apps use. You also pay for infrastructure: the Shuffle server, its OpenSearch database, and the Orborus runtime nodes that start a worker for each execution. High availability, which Shuffle's configuration documentation recommends with an OpenSearch cluster and more than one Orborus node, adds hosting cost that recurs every month. The largest recurring item is usually connector maintenance, because each vendor API change can break a playbook. Ask any partner or SaaS vendor to show who fixes a broken connector, how fast, and whether that work is in the quote or billed separately.
No price is estimated here. DeployOpen does not publish a price list, and a quote follows from a written scope that names the alert sources, the first playbooks to automate, the connected tools, the approval gates for destructive actions, the expected app-run volume and the hosting model. Ask each option to state one-time build costs, recurring run costs and the cost of a major connector change separately, and to say how run volume would be measured and what happens when a limit is reached. Confirm current Shuffle edition terms and Tines plan limits directly with each vendor, since pricing can change between your evaluation and your purchase.
Cost components by approach: in-house, partner and SaaS
This table compares the cost components of running SOAR as in-house Shuffle, partner-built Shuffle and a commercial SaaS platform, showing who receives each payment and whether it is one-time or recurring. Read each row as a question to put to vendors and partners, because the largest recurring costs are usually staff time and connector upkeep rather than the license line.
| Cost component | In-house Shuffle | Partner-built Shuffle | Commercial SaaS |
|---|---|---|---|
| Software license | Shuffle is AGPL-3.0 licensed, so the code is free to run; paid tiers add app-run licensing if you buy them | Same license terms as in-house, paid to the partner only for their services | Recurring subscription to the vendor, often priced by a metric the vendor sets; confirm the metric and tier in writing |
| Worker and server infrastructure | Recurring cloud or data center cost for backend, frontend, OpenSearch and Orborus nodes, paid to your infrastructure provider | Same infrastructure cost, usually billed to you directly; ask whether the partner resells it | Often included in the subscription, but hosting options must be confirmed with the vendor, as flexible hosting is available on request |
| App-run licensing | Applies only if you buy a paid Shuffle tier; counts actions that execute, not triggers or skipped actions | Applies only if the paid tier is chosen; ask the partner to model run volumes before quoting | Not applicable in the same form; check how the SaaS vendor meters workflows and executions |
| Integration build | One-time internal engineering to build Shuffle apps from OpenAPI specifications or the Python SDK, paid through internal salaries | One-time fixed-scope fee paid to the partner, with deliverables and acceptance agreed in writing | Vendor-supplied connectors where available, plus one-time internal or partner work for gaps and custom tools |
| Playbook engineering | One-time and ongoing internal time to design, write and tune playbooks; cost sits in existing security staff | One-time build fee for agreed first playbooks, then optional recurring work for new ones | Vendor templates reduce initial build, but custom playbooks still need internal or partner time |
| Connector maintenance | Recurring internal effort each time a monitored tool changes its API, credentials or version | Recurring retainer if the partner maintains apps; confirm response times and what is excluded | Vendor maintains its own connectors, but your custom connectors and credential changes remain your cost |
| Testing and change control | Recurring internal staff time for test workflows, approvals and change records before production | Testing scope and change process defined in the statement of work; ask who approves changes | Vendor release cycle drives some testing; your change control for automated response actions remains internal |
| Staffing for on-call response | Recurring cost of internal analysts and on-call rotation, unchanged by the platform choice | Partner may monitor or triage for an added fee, but accountability for decisions usually stays with you | Same internal on-call cost; SaaS does not remove the need for people to approve destructive actions |
What moves SOAR cost up or down
For a self-hosted Shuffle deployment, cost is set less by the software than by how much work the platform does, how many tools need custom code, and how much infrastructure keeps it available. The cards below cover the levers that change the quote, and each one is a question to settle before you compare build, partner and commercial options.
App run volume per playbook
Shuffle's licensing is priced on app runs, which count actions that actually execute in a workflow. Triggers and skipped actions do not count. A playbook that enriches every alert against five services will consume far more runs than one that only enriches high-severity alerts, so the same alert volume can produce very different bills. Ask a partner to model runs per playbook at your expected alert volume, and separate routine enrichment from destructive response steps that run rarely.
Custom apps for unsupported tools
Shuffle apps are built from OpenAPI specifications in the App Creator or written in Python with the Shuffle app SDK. Each tool your playbooks touch that lacks a maintained app becomes build work, and each custom app must be tested, versioned and kept current. Count the tools in your alert sources and response paths, mark which already have apps, and ask whether the partner estimate covers writing, testing and documenting each one. Internal engineering time for this work is a cost even when no invoice appears.
Worker nodes and OpenSearch sizing
Shuffle's backend stores records in OpenSearch, and Orborus nodes poll for jobs and start a worker for each workflow execution. The high availability guidance calls for an OpenSearch cluster and more than one Orborus node so workflows keep running if one fails. Each extra node and cluster member adds hosting, patching and monitoring work, which is paid for in your cloud or data center. Ask for the node count, storage estimate and the failover test plan as separate line items in any quote.
Credential handling and encryption key
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. The documentation warns that losing or changing this value breaks every saved app authentication. Cost follows from the controls you must build around it: secure storage of the modifier, a rotation and recovery procedure, and a plan for re-entering credentials if the value is lost. Confirm who holds custody of this secret and whether a partner's handover includes documented recovery steps.
Change frequency of connected tools
Every connector depends on the API of the tool behind it. When a SIEM, identity provider or ticketing system changes its API, endpoints, authentication or fields, the affected apps and playbooks need updates and retesting. Tools that release often or change their APIs without notice create recurring maintenance work. Ask a partner how many connectors they expect to revisit each year, who monitors upstream changes, and whether maintenance is covered by a retainer or billed per change.
Approval gates on destructive actions
Steps that isolate hosts, disable accounts or block indicators need human approval before they run, and each approval gate adds workflow design, testing and on-call coordination. Gates also reduce risk of an automated mistake affecting clinical, payment or production systems. A playbook with several gates costs more to build and test than one that acts automatically, but it may avoid far larger recovery costs. Ask which actions require approval, who approves them out of hours, and how the gate is tested before production use.
How app runs, workers and connectors drive recurring cost
Shuffle's licensing meter counts app runs, and that meter is where most recurring cost for a self-hosted or hybrid deployment starts to show up. An app run is an action that actually executes in a workflow. When a workflow runs, the Orborus runtime picks up the job, starts a worker for that execution, and the worker starts the app containers needed for each action. Each action that executes counts toward the app run total. Triggers do not count, and neither do actions that are skipped because a branch condition was not met. A playbook that enriches every alert with five lookups costs more than one that only enriches high-severity alerts, so the design of conditions and early exits is a cost decision as well as an engineering one. Ask any partner to model expected app runs per month from your real alert volumes, and to show which actions sit in front of the lookups that fire most often.
Connector upkeep is the recurring cost that tends to be missed in early estimates. Shuffle apps are built from OpenAPI specifications or written in Python with the Shuffle app SDK, and each app runs as a versioned Docker container. When a vendor changes an endpoint, deprecates a field or rotates an authentication method, the app needs to be updated, retested and re-deployed. The people doing this work are usually the ones who built the playbooks, so the cost is labor that recurs for as long as the tools in the playbooks keep changing. Confirm with any partner who owns each app after go-live, how vendor API changes are detected, and what the notice period is for a broken connector in production.
Pin stable Docker tags and plan upgrades as a scheduled activity. Shuffle v2.3.0 was published on September 28, 2026, and the Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag only for experimental changes. Treat the nightly tag as a test-environment choice, and pin the production image to a specific release tag so a playbook does not change behavior between restarts. Set a recurring review of Shuffle releases, test each upgrade against a copy of your workflows and saved app credentials, and record the effort in the quote. Also check that the SHUFFLE_ENCRYPTION_MODIFIER value is backed up before any upgrade, because the docs warn that losing or changing it breaks all saved app authentications.
How to build your own SOAR cost estimate
This sequence turns a vague question about SOAR spend into a comparable model for each option. It sizes the work by alert source, tool, action volume and deployment pattern, so build, partner and SaaS quotes can be read against the same inputs.
List alert sources and first playbooks
Your security lead or SOC manager lists the alert sources that will feed the platform first, such as SIEM detections, endpoint alerts, identity provider events and mailbox reports. For each source, name the first two or three playbooks, such as phishing triage, account disable or malware host isolation. Each playbook should have a written trigger and a written end state. This step is done when every playbook on the list has a trigger, a set of actions and an owner who can approve its scope.
Count tools that need apps or connectors
For each playbook, list every system the workflow must read from or write to, such as the ticketing system, identity provider, endpoint platform, threat intelligence service and email gateway. Note whether each tool already has a maintained Shuffle app, needs an app built from an OpenAPI specification, or needs custom Python written with the app SDK. Mark which tools are vendor-hosted and which sit inside your network, because that affects connectivity and hosting. This step is done when each tool has one of three labels and the total count of build items is written down.
Estimate monthly action volume per playbook
Shuffle's pricing counts app runs, which are actions that actually execute in a workflow, while triggers and skipped actions are not counted. For each playbook, estimate how many alerts it handles per month and how many executed actions each alert triggers, including enrichment lookups and notifications. Ask each vendor to state how it counts runs in its own model so the figures can be compared. This step is done when you have a monthly action count per playbook, a peak-month figure and a note on which actions are conditional.
Size the deployment pattern
Choose the Shuffle deployment pattern that matches your hosting rules. Shuffle documents a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. The platform team estimates the servers, storage and network paths each pattern needs, and confirms where worker containers will run relative to the tools they call. This step is done when one pattern is chosen for the first phase and its infrastructure list is written out.
Decide the high-availability tier
Decide how much downtime the automation can tolerate. The Shuffle configuration 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. The engineering lead records which of these components are required for the chosen tier and which are optional, then adds their hosting and support costs to the model. This step is done when the tier and its component list are signed off by the security and platform owners.
Assign owners for connector upkeep
Name a person or team for each app and connector, and record who updates it when a vendor changes its API, retires a field or rotates a credential. Confirm where saved app credentials live and who holds the encryption secret used to protect them, since the Shuffle docs warn that losing or changing that secret breaks all saved app authentications. Estimate the recurring hours for upkeep and testing in your own terms. This step is done when every connector has a named owner and an upkeep line item exists in the model.
Request written scopes on identical assumptions
Send the same inventory, action counts, deployment pattern, availability tier and upkeep owners to each option: in-house build, a partner that builds and maintains playbooks, and a commercial SOAR. Ask each respondent to separate one-time build work from recurring fees, infrastructure, support and connector maintenance, and to state what changes if volumes double. Read the quotes side by side only after each uses the same assumptions. This step is done when three written scopes exist with matching inputs and every gap between them is explained.
Which approach fits which team
This fits a security engineering or platform team that already writes automation, can run containers and expects to own playbooks for years. Shuffle's core features are available in the open-source edition, so the main recurring costs shift from licences to people, server capacity and the time spent maintaining integrations. The cost is mostly one-time build effort followed by steady maintenance, paid through internal salaries rather than vendor invoices.
- Licence cost: Shuffle states that all features are available in the open-source edition, so the paid tiers mainly add feature limits, scaling and support.
- Run-based metering: Shuffle's pricing counts app runs, meaning actions that execute in a workflow, so chatty playbooks raise cost even on the open-source path where paid tiers apply.
- Infrastructure: Plan for the server layout, OpenSearch, and more than one Orborus node if workflows must keep running after a failure.
- Connector upkeep: Your staff owns every app and OpenAPI definition, and must update them when a vendor changes its API.
- Credential custody: Losing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks all saved app authentications, so key handling becomes an internal operational duty.
Before committing, ask your team how many engineer-weeks per quarter it can spare for connector maintenance, since that figure drives the true cost of this model.
This fits a team with a small security staff, or one that needs playbooks quickly and cannot hire automation engineers. A partner such as DeployOpen can plan, build, document and hand over Shuffle playbooks under a written, fixed scope, and can offer ongoing support or upgrades under a retainer. Cost is paid as an engagement fee for build work, followed by a separate recurring fee if you want continued maintenance, so the split between one-time and recurring spend depends on the scope you agree.
- Build fee: Scope covers the alert sources, the first playbooks, the apps needed and the test evidence, and is set out in writing before work starts.
- Recurring support: A retainer covers connector updates, upgrades and playbook changes after handover, and should be priced separately from the build.
- Handover risk: Confirm who owns the workflow exports, app code and documentation at the end of the engagement.
- Knowledge concentration: If only one partner engineer understands a playbook, maintenance cost rises at the next change, so ask how the work is documented and peer reviewed.
- Infrastructure stays with you: Hosting, OpenSearch capacity and secret storage remain in your environment and your budget.
Request a quote that separates build, handover, retainer and infrastructure lines, and ask the partner what happens to playbooks if the retainer ends.
This fits a team that wants a hosted product, vendor support and fast onboarding, and accepts that the vendor sets the licence model. Tines is a useful reference point: its Free edition includes unlimited users, spaces and connectors, but only 3 live workflows, so any production use beyond that point requires a paid edition. Paid editions include unlimited workflows and flexible deployment options, while Tines' pricing FAQ says flexible hosting options are available on request. Cost is mostly a recurring subscription, plus internal effort to build and maintain the workflows.
- Live workflow limit: The Free edition allows 3 live workflows, so a production playbook set will require a paid plan. Confirm the limit that applies to your plan.
- Hosting model: Tines' pricing FAQ says flexible hosting is available on request, so confirm in writing whether it meets your data residency and network rules.
- Subscription terms: Ask how the price scales with users, workflows, runs or connectors, since these metrics differ between vendors.
- Lock-in: Ask for an export path for workflows and credentials, and check whether the export is usable outside the product.
- Internal labour: Building and maintaining workflows still takes staff time, and the vendor does not carry that cost for you.
Before signing, confirm the hosting model, the live workflow allowance for your planned playbook count, and the exit terms in writing.
SOAR cost questions buyers ask before hiring help
What drives the cost of a SOAR build?
Most of the cost comes from the people who design, build and maintain playbooks, not from the software itself. The main components are the internal or partner labor to map each alert source to a playbook, the time to build and test each connector, the worker and server infrastructure that runs the automation, and the recurring effort to repair connectors when a vendor changes an API. Costs rise with the number of alert sources, the number of tools each playbook touches, the number of approval gates for destructive actions, and the regulatory evidence the case record must hold. Ask any partner to split its quote into one-time build work, infrastructure you pay for directly, and recurring maintenance so you can compare approaches on the same basis.
Is Shuffle free to run in production?
Shuffle is free to download and run under AGPL-3.0, and according to its open source article, all features are available in the open-source edition. The paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are actively enforced. You still pay for the infrastructure that hosts the server, the OpenSearch document database and the workers, and for the staff who run it. Confirm with Shuffle which limits apply to your planned scale before you assume the open-source edition covers production volumes.
How does Shuffle count app runs for licensing?
Shuffle's pricing article uses a single metric, app runs, which means actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. To plan, estimate how many actions your playbooks execute per day, including enrichment lookups that fire on every alert, because those lookups usually drive the count more than response actions do. Ask the vendor how runs are measured in its current tier and how overages are handled, and test a representative set of playbooks in a non-production environment to measure actual run volume before you commit.
How long does a first SOAR integration take?
The duration depends mostly on the number of tools, how each one exposes an API, and how many decisions the playbook needs from your security team. A first integration usually takes longer than later ones because the team sets up the platform, credential handling, logging and approval patterns once. Shuffle apps are built from OpenAPI specifications in the App Creator or written in Python with the app SDK, so a tool with a clean, current API is faster to connect than one that needs custom code. No fixed timeline applies to every environment, so ask any partner for a written schedule tied to a named list of integrations and playbooks.
What does a SOAR build need from our internal team?
The build needs named people who can decide how each alert should be handled, approve destructive actions and check results against real incidents. Expect to provide access to the source tools, a test tenant or staging copy where possible, service accounts with least privilege, and a change control process for live playbooks. Your identity team usually needs to support single sign-on for the Shuffle console and secure storage for connector credentials. Plan for an internal owner who will review playbook changes, because automation that nobody owns tends to drift as tools change.
Can our own team maintain the playbooks after handover?
Yes, if you have engineers who can read Python, understand OpenAPI definitions and run a small change process, but the ongoing work is continuous. Each connector depends on a vendor API that changes over time, and each playbook depends on the logic your analysts agreed to. Ask for documentation of every app version, workflow, credential and approval gate, plus a test set that proves each playbook still works after an upgrade. Shuffle's configuration warns that losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks all saved app authentications, so key handling belongs in the handover plan. If the team cannot staff this work, a retainer for upgrades and testing is a common alternative.
How DeployOpen scopes and delivers a fixed-scope SOAR build
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the cost of a Shuffle build can be set out before work starts. Most engagements are fixed-scope, and we tie every line of the quote to a written scope that separates one-time build work from recurring support.
How we scope
- We list the playbooks, alert sources and connected tools that the written scope covers, with each one named.
- We record the expected app-run volume, worker placement and deployment model so run-based costs can be checked against the quote.
- We state which connector maintenance is included in the build and which is handled under a retainer.
How we build
- We deploy Shuffle in your cloud account, data center or air-gapped network, using the architecture that matches your scope.
- We build and test each integration against your tools, storing app credentials in Shuffle's encrypted store with managed secrets.
- We test workflows before production and document each playbook's inputs, outputs, approval gates and run consumption.
How we hand over
- We deliver architecture notes, runbooks, playbook documentation and a connector inventory with owners and versions.
- We walk your team through the encryption modifier, backup, upgrade and worker-scaling steps so no one depends on us alone.
- We confirm acceptance against the written scope before the engagement closes, with the open items listed.
How we support
- Ongoing support, upgrades and connector updates are available as a retainer, sized to the number of tools you run.
- We track vendor API and app changes that break connectors and agree the update cycle in writing.
- Retainers can cover continuous security testing of the automation platform itself, scoped separately.
