Shuffle SOAR implementation plan and cost

What a Shuffle SOAR implementation involves

A Shuffle SOAR implementation is a fixed set of work: scoping the priority security use cases, deploying the Shuffle server side and at least one runtime, integrating the security tools those use cases depend on, building and testing workflows, and handing everything over with documentation your team can maintain. The server side is a frontend, a Go backend API on port 5001 and an OpenSearch document database. The runtime side is Orborus, which polls the backend for jobs, starts a worker for each workflow execution, and the worker starts app containers. Confirm early which of the documented deployment architectures fits your environment: a single server with Docker Compose, Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus, or Kubernetes with Helm charts.

Teams usually start this work for one of three reasons: a SOC still runs its triage by hand, automation lives in scripts and cron jobs that nobody wants to own, or an existing SOAR is being retired. Each trigger changes the scope. A manual process needs a use-case inventory before anything is built. Scripts and cron jobs need a review of what they actually do, including credentials they hold. A retiring SOAR needs its playbooks mapped and parallel runs planned, which is covered in the migration section of this page.

On in-house versus partner: most teams with Shuffle experience can build simple workflows themselves. A partner is usually chosen for the harder parts: integrating tools with non-standard APIs, hardening the runtime so app containers and credentials are controlled, and testing workflows at the volume your alert queue produces. Ask any provider which of those three they will own, and what they will leave for your team to run afterward.

All Shuffle features are available in the open-source edition, so the cost of a project does not come from a license fee alone. It comes from the work (use cases, integrations, testing and documentation), from the runtime (where workers run, how many, and how they are kept available), and from ongoing operation. Ask for a quote that separates one-time build effort from recurring infrastructure and support, and confirm with Shuffle which limits apply if your app-run volume grows, since its paid tiers differ in feature limits, scaling and support.

What the work includes

A fixed-scope Shuffle engagement is split into workstreams that each end in a named deliverable. Ask for the deliverable list in the written scope so you can check what you receive against what you paid for.

Use-case selection and workflow design

We rank candidate security processes by volume, manual effort and risk, then agree which ones become Shuffle workflows in the first phase. The output is a workflow inventory with trigger, decision points, approvals and the apps each step calls. Check that every in-scope process has a named owner and a written acceptance condition.

Frontend, backend and OpenSearch deployment

We deploy the Shuffle frontend, the Go backend API on port 5001 and the OpenSearch document database in your infrastructure, using the architecture you chose. The deliverable is a running environment with documented versions, image tags and configuration. Confirm where OpenSearch data and backups live before go-live.

Orborus runtime setup

Orborus polls the backend for jobs and starts a worker for each workflow execution, and the worker starts app containers. We configure at least one runtime location and document where workers run, which networks they reach and how capacity is set. Confirm the runtime location matches where your SIEM, EDR and directory services sit.

Integration of named security tools

Each tool in scope is connected through a built-in Shuffle app or a custom app, selected per tool after checking app coverage. Custom apps are built from OpenAPI specifications or the Python SDK and versioned as Docker containers. The deliverable is a list of app definitions with versions, endpoints used and known gaps.

Secrets handling for saved app credentials

Saved app credentials and API keys are encrypted in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. We set that secret, store it outside the application, define a rotation procedure and create least-privilege API keys for each integration. Losing or changing the encryption secret breaks every saved app authentication, so confirm your backup and recovery steps for it.

Playbook testing and documentation

Each workflow is tested against representative inputs, including failure paths such as an unavailable app or an expired credential. The deliverables are test records, a short runbook for operating the environment, and maintenance notes so your team can change workflows later. Confirm who signs off on test results and who owns runbook updates after handover.

What drives cost and duration

This table lists the scope factors that change Shuffle implementation effort, why each one moves the estimate, and how to keep it manageable.

Driver	Why it changes effort	How to keep it down
Number and priority of use cases	Each playbook needs design, build, failure-path handling, testing and handover. Ranking the list shows which workflows must be production-ready first and which can wait.	Start with a short list of high-volume, well-understood alerts. Park edge cases until the first set runs in production.
Number and type of tool integrations	Shuffle ships prebuilt apps, but each integration still needs credentials, permissions, field mapping and error handling. Vendor APIs that are poorly documented take longer to verify.	Reuse existing apps where they fit and confirm their versions. Limit the first phase to the tools that the top-priority use cases require.
Custom apps from OpenAPI specifications or Python	Custom apps need an accurate specification or code, versioned container builds, tests and documentation so your team can maintain them after handover.	Ask for a current OpenAPI specification from the vendor. Keep custom logic thin and push business rules into the workflow where they are easier to review.
Number of runtime locations	Each location needs its own Orborus, network path, container host and monitoring. Locations multiply testing because each one must be verified separately.	Consolidate runtimes where network policy allows. Add a location only when a use case truly requires access from that network.
Runtime locations in private networks	Reaching internal SIEM, EDR or directory services from inside a private network requires firewall rules, service accounts and change approvals that add lead time.	Request network diagrams and access paths early. Confirm whether Shuffle Cloud with a local Orborus, which needs no inbound firewall ports, suits the requirement.
Deployment architecture	A single Docker Compose server is the simplest path. Docker Swarm and Kubernetes with Helm add cluster setup, image registries, storage classes and more operating procedures.	Choose the simplest architecture that meets the availability and scale requirements. Confirm the cluster platform your organization already operates.
High availability requirements	Redundancy needs an OpenSearch cluster, several backends and frontends, more than one Orborus, shared file storage and recovery testing. Each addition is built, configured and tested.	Define in writing which outages the automation must survive. Phase redundancy in after the core workflows are proven.
Expected app-run volume	Volume affects worker capacity, concurrency settings, sizing of OpenSearch and the licensing metric, since paid licensing counts app runs that execute in a workflow.	Measure current alert and automation volume before design. Remove noisy triggers and skipped actions that add load without value.
Number of environments	Each environment (for example development, test and production) needs its own configuration, secrets, app versions and deployment steps. Promotion must be repeatable.	Keep environments as close to identical as possible and manage configuration as code. Limit the number of non-production copies to what testing requires.
Compliance evidence needs	Assessors may ask for records of change approval, access reviews for API keys, encryption key handling, backup tests and logs of workflow executions. Producing this evidence adds documentation and testing work.	Agree the evidence list before the build starts. Ask which controls your auditor expects and design logging and change records to produce them.
Open-source or paid edition features	All features are available in the open-source edition, while paid tiers differ in limits, scaling and support. Paid features add licensing decisions and configuration effort on top of the base build.	Confirm which features the use cases actually need against the current edition terms. Verify limits in the configuration documentation before committing to a design.

Project phases and outputs

The sequence moves from agreed use cases to a tested, documented Shuffle environment that your team can run and maintain.

Rank use cases and confirm scope
We review your candidate playbooks with your SOC and engineering leads, rank them by operational value and integration effort, and agree which tools each one touches. The output is a signed-off use-case list with named owners, which becomes the basis of the written scope.
Decide architecture and runtime locations
We document the deployment model, the server and OpenSearch layout, and where Orborus runtimes will run relative to your SIEM, EDR and directory services. The output is an architecture decision record covering network exposure, secrets handling and the image versions you will pin.
Build the environment
We install and configure the Shuffle frontend, backend, OpenSearch and runtime components in the infrastructure you choose, with encryption secret handling set up before any app credentials are saved. The output is a working environment that your team can log into and inspect.
Integrate tools and build apps
We connect each in-scope tool, using OpenAPI-based apps where a specification exists and Python apps where it does not, and configure least-privilege API keys for each integration. The output is a tested set of apps with versioned containers and documented authentication for each tool.
Build and test workflows in staging
We build the ranked playbooks as workflows, run them against staging data and test cases that cover success, failure and partial-failure paths, and review each result with your analysts. The output is tested workflows with a record of test results and known limits.
Run in parallel, cut over and hand over
Where a legacy process exists, we run the Shuffle workflows alongside it and compare outcomes before switching live duties over. We then deliver runbooks for operations, upgrades and recovery, and train your team. The output is a production cutover record and a handover package your team owns.

One-time and recurring cost components

This table lists the cost components of a Shuffle SOAR project, who is paid for each, whether it is one-time or recurring, and what to request in a written quote.

Component	One-time or recurring	What it covers	What to ask for in a quote
Implementation fee	One-time	Installing Shuffle in your chosen deployment architecture, configuring the frontend, backend, OpenSearch and runtime, and handing over documentation	Fixed scope listing deployment architecture, environments, handover items and acceptance criteria
Custom app development	One-time, with later updates	Building apps from OpenAPI specifications or in Python with the Shuffle app SDK, packaged as versioned Docker containers	Number of apps, source of each API specification, versioning and documentation deliverables
Integration work	One-time	Connecting SIEM, EDR, ticketing, directory and other tools in your stack, including credential setup and network paths to each system	List of target systems, access each one needs, and who supplies test accounts and credentials
Playbook build and testing	One-time	Designing workflows for priority use cases, building them, and testing them against representative inputs before production use	Number of workflows, test cases per workflow, and what counts as acceptance
Test environments	One-time to set up, recurring to run	A non-production Shuffle stack with its own OpenSearch and runtime so changes are tested before promotion	Whether the environment is provided by you or DeployOpen, its sizing, and who maintains it after handover
Server infrastructure for the backend, frontend, OpenSearch and worker hosts	Recurring	Compute, memory, storage and network for each server role, plus additional Orborus nodes if you need redundancy	Your own hosting cost or a sizing recommendation; confirm app-run volume and workflow concurrency before sizing
Paid Shuffle edition or support tier	Recurring, if chosen	Limits, scaling and support differ by tier, and app-run based licensing applies to the paid model according to the Shuffle pricing article	Current tier, app-run volume assumptions and whether the vendor price is quoted separately from DeployOpen services
Playbook upkeep	Recurring	Updating workflows and apps when source systems or APIs change, and reviewing failed executions	Whether upkeep is covered by a retainer, response times and which changes are in or out of scope
Upgrade work	Recurring, per upgrade	Moving frontend, backend and worker images to a newer release, updating apps afterward and retesting critical workflows	Which releases are covered, whether testing is included, and how a rollback is handled

What usually goes wrong

Most delays and surprises in a Shuffle SOAR project trace back to a few early decisions. Each card names the failure, the prevention step and the item to confirm in the quote.

Lost or changed encryption secret

Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing it breaks every saved app authentication at once. Prevention: store the value in your secrets manager, back it up alongside OpenSearch data, and place any change under change control. Confirm in the quote who owns this secret and how it is restored in a recovery test.

Underestimated app-run volume

Shuffle licensing counts app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, so volume estimates built from alert counts are often wrong in either direction. Prevention: measure executed actions from a pilot, multiply by the planned use cases and add expected growth. Confirm in the quote which volume assumptions the plan uses and how additional volume is handled.

Workflows built without staging tests

Playbooks built against production tools can close tickets, disable accounts or send notifications while they are still being developed. Prevention: run a separate staging Shuffle instance with test accounts and sandboxed integrations, and require a documented test pass before any workflow is promoted. Confirm in the quote whether staging is included, who writes the test cases and what evidence is delivered at acceptance.

Single Orborus or OpenSearch node

Orborus polls the backend for jobs and starts a worker for each workflow execution, while OpenSearch stores the documents that the platform depends on. A single instance of either is a single point of failure for automation. Prevention: plan more than one Orborus node and an OpenSearch cluster from the start, then test failover before go-live. Confirm in the quote whether high availability design, shared file storage and recovery testing are in scope.

Running a version older than v2.1.1

Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced, so older installs also need a licensing review. Prevention: inventory the frontend, backend and worker image versions and place the upgrade in the first project phase. Confirm in the quote whether the upgrade and app updates are included.

Integrations that need inbound access

Some integrations depend on webhooks or callbacks that require inbound connections the network team may not approve. Shuffle's hybrid model with a local Orborus needs no inbound firewall ports, but cloud-triggered flows and some apps still depend on reachable endpoints. Prevention: map the traffic direction of each integration during scoping and agree on an approved pattern with the network team. Confirm in the quote which runtime location each use case assumes.

How the work changes by starting point

A single server running Docker Compose is the smallest footprint, with the frontend, backend, OpenSearch and an Orborus runtime on one host. Scope stays narrow, but the main drivers are the capacity of that one machine and the lack of built-in redundancy.

Drivers: host sizing for OpenSearch and the app containers that workflows start, plus backup frequency for OpenSearch data.
Extra scope: a documented rebuild procedure for the host, and a restore test that proves the backups work.
Client provides: a Linux host with Docker, a DNS name and TLS certificate, network paths to the tools you plan to connect, and a backup target.
Confirm: whether a single host meets your recovery expectations before any high availability work is requested.

What you need to provide

Scoping cannot close until you give us a small set of inputs. The most important is a ranked list of use cases, each with a named business owner who can approve the expected behavior of the playbook. Rank them by operational pain or risk, not by how interesting the automation looks. Alongside that list, provide an inventory of the security tools each use case touches (SIEM, EDR, ticketing, identity, email, threat intelligence) with the API access we would need: service accounts, API keys with scoped permissions, and test tenants or sandbox instances where we can run playbooks without touching production data.

Network access determines where Orborus runs and which apps can reach which systems. Document the network paths between the runtime locations you plan to use and each internal system, including firewall rules, proxies and DNS names. Make a hosting and sizing decision early: which environment hosts the frontend, backend and OpenSearch, whether runtime locations sit in private networks, and what capacity you expect. Shuffle's architecture options (single server, Docker Swarm, a hybrid with local Orborus, or Kubernetes) carry different network and operations requirements, so confirm which one you intend to run.

Name an owner for the encryption secret, SHUFFLE_ENCRYPTION_MODIFIER, and the key storage where it will live. Shuffle encrypts saved app credentials with it, and losing or changing it breaks every saved authentication, so this owner must agree to the storage, backup and rotation approach before installation. Also identify the change approval windows for production, since we will need time for testing and cutover that your change board recognizes.

Finally, name an internal operator who will run Shuffle after handover. This person does not need to build playbooks, but must be able to read workflow logs, manage upgrades, rotate keys and triage failed executions. On the decision side, expect to settle the edition (the open-source edition offers all features with limits that are enforced on paid tiers), the deployment architecture, and which playbooks go first. Confirm these with the vendor's current documentation and your own licensing position before the written scope is signed.

Frequently asked questions

How much does a Shuffle SOAR implementation cost?

The cost depends on the written scope, and DeployOpen does not publish a price list. The main drivers are the number of priority use cases, how many tools need integration, how many runtime locations you need, how complex each playbook is, and how much testing the workflows need before go-live. Costs fall into two groups. One-time costs cover scoping, building, testing and handover. Recurring costs include infrastructure for the OpenSearch database and workers, any paid Shuffle tier you choose, and optional support or upkeep. Ask for a quote that itemizes these groups and states its assumptions about tool access and volume.

How long does a Shuffle SOAR implementation take?

Duration follows from the scope, so no fixed timeline applies to every project. The biggest factors are how many use cases you prioritize, whether a tool needs a custom app built from an API specification, and how much network access the runtime needs into private systems. Approval cycles, change windows and the availability of your tool owners also set the pace. A hybrid design with an on-premises Orborus node or a high availability layout adds planning and testing time. The written scope should give a schedule with milestones, and the quote should name the dependencies on your side.

Is the open-source edition of Shuffle enough for our team?

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, those limits are actively enforced between the open-source and enterprise editions. Whether the open-source edition fits depends on your required scale, the support model you need, and any feature limits that affect your design. Confirm the current edition limits in Shuffle's configuration documentation and against your expected workflow volume before you choose an edition. Your quote should state which edition the design assumes.

How does app-run licensing for Shuffle scale with our alert volume?

Shuffle prices its licensing on one metric, app runs, which count actions that actually execute inside a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Your licensing cost therefore depends on how many actions run, which is shaped by alert volume, how early workflows filter out noise, and how many enrichment steps each case triggers. Playbook design choices, such as filtering before enrichment, directly affect this volume. Ask for an estimate of monthly app runs based on your alert and case data, and confirm current terms with Shuffle before committing.

What does our team need to provide for a Shuffle project?

Your team typically provides a named owner for each priority use case, access to the security tools to be integrated, and API credentials with the least privileges each integration needs. You also need network paths from the runtime to those tools, sample alerts or test data, and approvers for playbook changes that act on live systems. Plan for review time during testing and a change window for go-live. Hosting decisions, such as where the Shuffle server and runtime run, need sign-off from your infrastructure and security teams. List these inputs in the written scope so gaps are visible before work starts.

What do we receive at handover from a Shuffle implementation?

The handover contents are set in the written scope for each engagement, so confirm the exact list before work starts. In general, expect the Shuffle environment deployed in infrastructure you control, the workflows and any custom apps with their source code, and the tests that cover them. You should also receive documentation of runtime locations, the credential and encryption secret handling process, configuration records and runbooks for routine operations. Knowledge transfer sessions for your engineers are normally included or priced separately, depending on the scope. Ask for a written handover checklist and sign-off criteria in the quote.

How DeployOpen delivers Shuffle implementations

DeployOpen plans, builds, documents and supports self-hosted Shuffle inside your own infrastructure, so the cost you approve follows from a written scope covering use cases, integrations and runtime locations. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we scope

We agree a written scope covering priority use cases, tool integrations and the runtime locations each workflow needs.
We estimate app-run volume from your existing alerts and automations so licensing and runtime sizing are discussed before the build.
We list which one-time items (design, builds, testing, handover) and which recurring items (infrastructure, licensing, support) apply to your environment.

How we build

We deploy the chosen architecture, whether single-server Docker Compose, Docker Swarm, hybrid with a local Orborus, or Kubernetes with Helm.
We build playbooks and custom apps from OpenAPI specifications or Python, with versioned containers and tested workflows.
We configure secrets handling, including protection of the app credential encryption secret, and test each workflow against your tools before go-live.

How we hand over

We document architecture, workflows, apps, credentials ownership and the recovery steps for the encryption secret and OpenSearch data.
We walk your team through running, changing and testing workflows so they can maintain them without us.
We confirm the hand-over checklist against the written scope and record any items your team still needs to confirm with vendors.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing separately from the implementation.
Retainers can cover aligning frontend, backend and worker versions after upgrades and updating apps that depend on changed APIs.
Before a retainer starts, we agree which Shuffle versions your environment must run, since older releases are no longer supported.