Shuffle incident and case management: when a built-in workspace is enough
For a security team that runs alerts through Shuffle and tracks analyst work in a separate ticket queue, the built-in workspace can hold that work when the team is small to mid-size, most response follows playbooks, and Shuffle is already deployed and operated in-house. The fit is strongest when incidents follow known paths: an alert arrives by webhook or polling, a playbook enriches it, and a case opens with the records and observables an analyst needs. Running a second tool for the same work often creates duplicate records and a manual copy step that fails under load. The decision comes down to whether one system of record meets your volume and handoff needs.
Confirm the capabilities before you decide. The case features described here, including alert ingestion, OCSF records, observable extraction with TLP tags, and launching playbooks from a case, come from Shuffle's documentation and can change between releases. Check them against the exact release you run, and note which Docker tag you pin. Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes, so a team on nightly should expect behavior to shift. Test each step with a sample alert in a non-production instance, and confirm search, export, audit trail and analyst role settings, since you will need them during review.
The built-in workspace is a reasonable choice when a single team owns triage and response, the workflows are mostly automated with a few analyst decisions, and the platform team already backs up, patches and monitors the Shuffle deployment. Case data shares that deployment's lifecycle. Its document store is OpenSearch, so backup, restore and high availability design must cover case records, not only playbooks. Check who holds the encryption secret used for saved app credentials, because the docs warn that losing or changing it breaks existing app authentications. Those operational duties are the real cost of keeping cases in Shuffle.
A dedicated ticketing or case system should remain when other departments such as IT, legal, HR or customer support need their own queues, approvals and service levels in their own tools. It should also remain when an auditor or contract expects case-management evidence that you cannot yet demonstrate from the workspace, or when retention and access requirements need controls you have not confirmed in Shuffle. In those cases, use Shuffle as the automation layer and sync case references into the ticket system through its app integrations, so each record links to the other and neither becomes a copy that drifts.
Deployment and intake options and which one fits
This table compares the four documented Shuffle deployment architectures and the two alert intake methods, with the network requirements each creates. Read the first four rows to choose where the backend and runtime run, and the last two to choose how alerts reach a case. The main takeaway is that the hybrid model keeps the runtime inside your network without inbound firewall ports, but you still need to confirm where case data and saved credentials will be stored.
| Option | Best suited to | Network requirements | Confirm before choosing |
|---|---|---|---|
| Single server with Docker Compose | A pilot, lab or small team running everything on one host | Analysts must reach the backend on port 5001 and the frontend; no node-to-node links | Whether one host meets your availability needs, since the docs recommend clustering for high availability |
| Distributed Docker Swarm | Several servers where the backend and frontend need to scale across nodes | Swarm traffic between hosts, plus shared storage access if NFS is used for shared files | Whether your team can operate Swarm and NFS, and where OpenSearch cluster nodes will run |
| Hybrid: Shuffle Cloud with a local Orborus | Teams that want workflow execution inside their network while Shuffle hosts the management layer | No inbound firewall ports, because the local Orborus polls the backend for jobs | Whether alert data and saved app credentials may be stored in Shuffle Cloud, and which features your tier includes |
| Kubernetes with Helm charts | Organizations already running Kubernetes that manage deployments with cluster tooling | Ingress to the frontend and backend, plus pod-to-pod traffic inside the cluster | Whether your cluster, ingress controller and storage classes match the Helm chart and your upgrade policy |
| Webhook intake | Detection tools or SIEMs that can push an event to a workflow when it fires | Each source must reach your webhook endpoint through a firewall rule you open for it | Whether each source can authenticate to the endpoint and how it retries when delivery fails |
| Polling intake | Sources with an API you can query on a schedule but cannot configure to push events | Outbound API access from the Shuffle runtime to the source; no inbound rule for the source | Query rate limits, the volume returned per poll, and how missed or duplicate alerts are handled |
Choosing webhook or polling for alert intake
The choice between webhook and polling decides how quickly an alert reaches a Shuffle case and what happens when the source or the platform is unavailable. A webhook pushes each event to a Shuffle trigger endpoint as it occurs, so latency is usually the lowest. The sender must support outbound notifications, and it must be able to reach your Shuffle backend, which listens on port 5001 in the standard single-server layout. Polling reverses the direction: a scheduled workflow asks the source for new records. It suits sources that cannot push, but alert latency can be no better than the polling interval, and each poll consumes source API capacity and needs valid credentials. Decide per source, and record which method you chose and why.
Credential handling is where the two models diverge most. A webhook source typically needs only a shared secret or token configured on the sender, and you should confirm whether the sender can sign payloads so the workflow can verify them. A poller holds API credentials that Shuffle stores encrypted in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. Back that secret up outside the platform and document who can change it, because losing or altering it breaks every saved app authentication. Give each poller a dedicated service account with read-only access to alert data, and rotate both shared secrets and API tokens on your normal schedule.
Failure visibility matters more than the headline latency figure. A webhook that fails on the sender side leaves no trace in Shuffle, so an alert is lost unless the source queues and retries undelivered events. Ask each source how long it retries, whether it keeps order, whether it deduplicates, and what it does when the receiver returns an error. A poller fails visibly in execution history, but it can silently skip records if its time window or cursor is wrong after an outage. Plan a backfill procedure for both models, and alert on silence from each source, not only on workflow errors.
Runtime topology affects both paths. In a hybrid deployment with Shuffle Cloud, the local Orborus needs no inbound firewall ports because it polls the backend for jobs. That does not remove the need for inbound reachability for webhook senders inside your network, so confirm where each endpoint is hosted before you commit to push delivery. Run at least one test per source: send a sample event, simulate a backend restart, and record what arrives, what is retried and what is lost. Confirm which trigger types are available on self-hosted versus Cloud or hybrid, using the Shuffle workflow triggers and human approvals page, before you finalize the design.
How to set up case management in Shuffle
This sequence takes a self-hosted Shuffle instance from a chosen release to a working incident and case workflow. It ends with one alert flowing into a case with extracted observables and TLP tags, plus one playbook run from that case. Each step closes with a check so the team can confirm it worked before moving on.
Choose a supported release tag
The platform team selects the Shuffle release before anything is installed. Use the latest Docker tag for stable production and the nightly tag only for experimental work. Do not run versions older than v2.1.1, because the configuration docs state that support for those ended after January 31, 2026. Take the release notes from the Shuffle GitHub releases page and record the tag in your change record. Check: the tag and version are documented, and the running backend reports the same version after first start.
Deploy the chosen architecture
Pick one of the four documented architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus, or Kubernetes with Helm charts. Your choice depends on where workflows must execute and on your team's container platform skills. Deploy the frontend, the Go backend API on port 5001, and the OpenSearch document database. Check: the frontend loads, the backend answers on port 5001, and OpenSearch reports healthy before you continue.
Set the encryption modifier first
Set SHUFFLE_ENCRYPTION_MODIFIER in the server environment before anyone saves an app credential or API key. Shuffle encrypts saved app authentication in OpenSearch with AES-256 using this secret, and losing or changing it later breaks every saved app authentication. Store the value in your secrets manager with restricted access and a documented recovery copy. Check: save a test credential, confirm it authenticates an app action, then restart the backend and confirm the credential still works.
Configure single sign-on if required
If analysts must sign in through your identity provider, configure SSO before onboarding users. Shuffle added SAML in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises and in the cloud, with per-tenant SSO enforcement. The extensions docs say SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so confirm the current status with Shuffle before choosing a protocol. Check: a test user signs in through the identity provider, and a user outside the permitted group is refused.
Install and register Orborus nodes
Install Orborus and register each node with the backend. Orborus polls the backend for jobs, starts a worker for each workflow execution, and that worker starts the app containers. For resilience, run more than one Orborus node so workflows keep running if one fails. In the hybrid architecture, the local Orborus needs no inbound firewall ports. Check: every node appears as registered in the backend, and a test workflow still completes after you stop one node.
Define the case data model and TLP
Decide how alerts, cases and observables are structured before analysts work in volume. Shuffle's case records follow OCSF, so map your alert fields to those records and decide which observable types you extract. Set a TLP convention that every analyst applies the same way, including who may change a tag and whether a tag may be lowered. Confirm the TLP version with the sharing partners named in your agreements. Check: a reviewer compares a sample alert's mapping against the written standard and signs off.
Build and test one intake path
Build one alert intake path from a single source to a case. Choose webhook or polling based on what the source supports, then configure the trigger and the observable extraction. For example, an illustrative setup might connect one detection tool by webhook. Send a known test alert and confirm the case appears with the expected severity, observables and TLP tag. Check: the test alert produces exactly one case, and you record how a repeated send is handled so the team knows what to expect in production.
Run one playbook from a case
Attach one response playbook to the test case and run it from the case view. Start with a notification or read-only action until its app credentials and actions are proven. The pricing article counts app runs as actions that actually execute, so the run history shows what was billed and what happened. Check: the playbook run is linked to the case, its actions and outputs appear in the case timeline, and no action ran that you did not expect.
Security considerations for case data in Shuffle
Case records in Shuffle hold alert details, extracted observables and the credentials that playbooks use to act on them. The controls below cover how those secrets are protected, how people sign in and see cases, and where the data is hosted, so each one can be checked against your own handling rules before cases go into production.
Encryption of saved app credentials
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. Confirm that the value is set on every backend node before the first app authentication is saved, and that the encrypted OpenSearch indices are covered by your backup and access controls. The stored credentials are only as protected as the infrastructure holding that secret.
Managing the encryption secret
The Shuffle configuration documentation warns that losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks all saved app authentications. Store the value in a secrets manager with a documented owner, record it in your recovery runbook, and test a restore that includes the secret. Plan any rotation as a re-authentication exercise for every connected app, because the stored credentials cannot be decrypted with the new value.
Single sign-on with per-tenant enforcement
Shuffle supports SAML single sign-on, added in version 0.9.16, and OpenID Connect, added in 1.0.0, both available on-premises and in the cloud, with SSO enforcement set per tenant. Decide which tenants must sign in through your identity provider and confirm that local accounts are disabled for them. Shuffle Cloud is moving from SAML toward OpenID Connect, so check which protocol your deployment will rely on before you build the integration.
Access to cases with sensitive observables
Cases can contain IP addresses, email addresses, hashes and other observables taken from sensitive alerts, and an analyst who can open a case can usually read those observables. Define which roles may view, edit or run playbooks against cases that hold personal data or internal network details, and test those restrictions with a non-administrative account. Review the role model whenever you add a new tenant or integration.
Hosting model and data handling
Shuffle documents single-server, Swarm, Kubernetes and hybrid deployments. In the hybrid model, Shuffle Cloud hosts the control plane while a local Orborus node runs workflow execution, so case data and execution sit in different places. Map where case records, OpenSearch data and workflow runs are stored under each option, and assess that mapping against your data residency and handling rules before choosing a model.
Network exposure of the runtime
The architecture documentation states that the hybrid model needs no inbound firewall ports for the local Orborus node, because it polls the backend for jobs. Document every port and outbound destination your deployment uses, including the backend API on port 5001 and connections from app containers to external services. Review that list with your network team before the case workspace goes live.
Keeping case intake and playbooks running during failures
The Shuffle configuration docs describe a high availability pattern for keeping case intake and playbook execution alive when one component fails. The pattern combines an OpenSearch cluster, an optional Memcached shared cache, NFS for shared files when several backends run, the backend and frontend scaled across all servers, and more than one Orborus node. Each part protects against a different failure. The backend API on port 5001 and the frontend, when scaled across servers, keep the console and alert webhooks reachable if one host is lost. OpenSearch holds the case records, workflow definitions and execution history, so losing its only node would stop the platform from recording anything. Confirm the node count, shard replication and heap settings for your Shuffle version against OpenSearch guidance before you deploy.
NFS and Memcached each solve a narrower problem, and both can add a failure point of their own. When several backends run, they must read the same shared files, so every backend host needs access to the same NFS export. An NFS server with no redundancy becomes the single point of failure for the whole cluster, so decide early whether it runs on your existing clustered file service or a separate highly available design. Memcached is optional, and the docs present it as a shared cache, not as a store of record. Losing it should slow the platform down rather than lose case data, which you should verify in your own test. Ask who owns the NFS exports, their backups, and the permissions that apply to backend mounts.
Running more than one Orborus node is the piece most often misunderstood. Orborus polls the backend for jobs, starts a worker for each workflow execution, and that worker starts the app containers that perform each action. When one Orborus host stops, the remaining nodes should take on new jobs, but the behavior of executions already in progress depends on the worker and container state at the moment of failure. Do not assume a run finishes cleanly. Test it by stopping an Orborus node during a playbook that calls an external API, then check whether the run completes, retries or fails, and whether the case timeline shows what happened. Repeat the test with the node restored to confirm it rejoins the pool.
The encryption modifier is a dependency that high availability designs often leave out. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. If that value is lost or changed, every saved app authentication breaks, and playbooks that call ticketing, EDR or identity tools stop authenticating during the very incident they were built to handle. Store the modifier in your secrets system, apply backup controls equal to those of the OpenSearch data, and rehearse restoring it onto a rebuilt backend. Record which person or team can approve a change to it, because changing it is not a routine configuration edit.
Sizing for this pattern cannot be copied from a template, because it depends on alert volume and workflow concurrency in your environment. Measure peak alerts per hour, the number of playbooks that run at the same time, the average duration of each execution, and the number of app actions per run, which also drives licensing because Shuffle prices on app runs. Watch OpenSearch heap and disk usage during those peaks, and watch Orborus queue time. Then run three tests before you go live: stop an Orborus node during a live run, remove one OpenSearch node and confirm that case search and writes continue, and restore the encryption modifier onto a clean host. Ask the vendor and your implementation partner to document the results.
Limits and what to confirm before you commit
Shuffle's edition limits, licensing metric, support window and release history all affect what a case management build can do and what it costs to run. Work through these points with Shuffle and your implementation partner before you fix scope.
Edition limits are enforced
Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced. A limit can block a feature your case workflow depends on, so list every capability you need, including case records, observable handling and TLP tagging. Then confirm which edition covers each one, using Shuffle's pricing and open source articles, and get that mapping in writing before you commit.
Licensing counts app runs
Paid licensing uses one metric: app runs, meaning actions that execute in a workflow. Triggers and skipped actions are not counted. Estimate run volume from expected alert rates and playbook design, then ask the vendor how retries, reruns and fan-out from a single alert are counted. Those answers drive the license sizing more than the number of analysts.
Unlimited users, apps and workflows
Users, apps and workflows are unlimited under the licensing model, so headcount and playbook count do not set the license size. Sizing shifts to execution volume. Confirm that the edition you choose carries the same unlimited terms, and check whether custom apps built with the App Creator or the Python SDK change how actions are counted in your runs.
Support window for older releases
Shuffle stopped supporting versions older than v2.1.1 after January 31, 2026. If you are migrating an existing installation, record the version it runs today and plan the upgrade path in the design phase. Ask Shuffle to confirm the support window for the release you will run in production before you sign a fixed-scope agreement.
Confirm the release in use
Shuffle v2.3.0 was published on GitHub on September 28, 2026. The Shuffle docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes. Pin the exact image tag in your design, record it with the scope, and use the same tag for staging so every test runs against the release you will deploy.
Verify case workspace features
Case workspace capabilities, including OCSF records, observable extraction, TLP tags and running response playbooks from a case, should be tested against the release you deploy. Build a staging instance from the chosen tag, run one representative alert through the full case lifecycle, and record which steps pass before the build plan is approved.
Questions teams ask before running cases in Shuffle
What drives the cost of setting up Shuffle case management?
Scope drives cost most. The main inputs are the number of intake sources (webhook or polling feeds from your SIEM, EDR and mail systems), the number of response playbooks and custom apps, the identity model, and whether the platform runs as a single server or in a highly available layout. The Shuffle open source article states that all features are available in the open-source edition, so software licensing is usually not the main variable for a self-hosted build. DeployOpen fees follow from the written scope, and DeployOpen does not publish a price list. Ask for a quote that itemizes discovery, infrastructure configuration, source integrations, playbook build, testing, documentation and handover. Separate the one-time build from any retainer for upgrades, support or continuous testing, because those recur.
How long does setting up Shuffle cases take?
No single duration applies, because the timeline follows the same scope inputs as the cost. A build with one or two alert sources, a small set of playbooks and existing accounts is planned differently from one that adds OpenID Connect sign-in, a highly available OpenSearch cluster, several Orborus nodes and integrations with ticketing or threat intelligence systems. Dependencies on other teams also set the pace: access to cloud accounts or data centers, change approvals, and source system owners who must confirm field mappings and test payloads. The written scope should list the phases, the environment assumptions, the client responsibilities and the acceptance tests. Ask the proposal to show which tasks sit on the critical path, so you can see which delays come from your organization and which come from the build.
What does the client team need to provide for a Shuffle case build?
The work needs four things from your side. First, infrastructure access: a host or cluster in your cloud account, data center or air-gapped network, with DNS, certificates and outbound routes to each source. For a hybrid layout, the local Orborus needs no inbound firewall ports, which should be confirmed with your network team. Second, source system owners for each alert feed, who confirm event formats, webhook or polling credentials and sample events. Third, a written decision on TLP handling and case data rules: which TLP labels analysts apply, who may see restricted observables, how long case records are kept and what data may leave the network. Fourth, a named approver who signs off the scope, the acceptance tests and any playbook step that changes production systems. Missing items stop the schedule at the point where they are needed.
Can our internal security engineers set up Shuffle cases without a partner?
Yes, a competent internal team can build a basic case workflow, provided it already runs containers, manages secrets and can operate OpenSearch. Shuffle's documentation covers the single-server Docker Compose path, and the app SDK and App Creator are available to build integrations. The work usually slows in the parts that are easy to underestimate: mapping each alert source into consistent OCSF-based records, extracting observables reliably, agreeing TLP rules with legal and the SOC, designing high availability with shared files and several Orborus nodes, wiring single sign-on, and writing tests that show a playbook behaves correctly when a component fails. Ask whether those skills exist in-house now and who will own the platform after handover. A partner is most useful for the parts your team has not built before, and the written scope should state which tasks stay with your team.
What recurring work follows a self-hosted Shuffle launch?
Four areas recur. Upgrades: Shuffle publishes releases, its docs recommend the latest Docker tag for stable use and the nightly tag only for experiments, and versions older than v2.1.1 stopped being supported after January 31, 2026, so plan a regular test-and-upgrade cycle in staging. Credential rotation: saved app credentials and API keys are encrypted in OpenSearch, and the docs warn that changing the encryption modifier breaks saved authentications, so any rotation needs a written, tested procedure. Orborus capacity: each workflow execution starts a worker and app containers, so rising playbook volume or new sources needs monitoring and more runtime nodes. Platform care: OpenSearch backups, certificate renewal and access reviews. Confirm in the scope whether monitoring and upgrades are delivered as a retainer or handed to your team.
How do SSO and high availability change the Shuffle setup work?
They add components and testing, so they belong in the scope from the start. For single sign-on, Shuffle documents SAML support from version 0.9.16 and OpenID Connect from 1.0.0, available on-premises and in the cloud, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so confirm which protocol your identity provider should use. For high availability, the docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when running several backends, the backend and frontend scaled across all servers, and more than one Orborus node so workflows keep running if one fails. Each element adds configuration, failover testing and runbooks. Ask the quote to list which of these are in scope and how failover will be tested.
How should Shuffle encryption keys and saved credentials be protected?
Treat the encryption modifier as a root secret. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and the configuration docs warn that losing or changing it breaks all saved app authentications. In practice, generate the value once, store it in a managed secrets store with restricted read access, back it up separately from OpenSearch snapshots, and record which environments use it. A restored snapshot needs the matching value to work, so restore tests should use it too. Document who may read the secret, how it reaches the containers, and how a restore is verified. These items belong in the handover runbook and should appear as acceptance criteria in the written scope.
Which Shuffle deployment architecture suits a case management rollout?
Shuffle documents four architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus, and Kubernetes with Helm charts. A single server suits a pilot or a small SOC with a few sources and no formal availability target. Swarm spreads the backend, frontend and runtime across servers you operate. The hybrid model lets a local Orborus run without inbound firewall ports, but part of the platform sits in Shuffle Cloud, so data residency and case data rules must be decided first. Kubernetes with Helm suits teams that already operate clusters and want standard upgrade and scaling tooling. Choose based on your data boundary, your operating skills and your availability target, then confirm the choice in the written scope.
How DeployOpen scopes and delivers Shuffle case management
DeployOpen scopes Shuffle case management as a written, fixed-scope engagement covering the incident workspace, alert ingestion, playbooks run from cases, and the hosting they depend on. Delivery happens inside your own infrastructure, with testing, documentation and handover agreed in writing before work starts.
How we scope
- Written list of alert sources that create cases, whether by webhook or polling
- Agreed mapping of case fields to OCSF records, with observable and TLP tag rules defined
- Confirmed list of playbooks that can start from a case and what each one may change
How we build
- Configure the case workspace, ingestion endpoints and analyst roles on your chosen deployment model
- Build observable extraction and TLP tagging, then test each alert path from ingestion to closure
- Store app credentials under encryption with the encryption modifier kept in your secrets store
How we hand over
- Runbooks covering how cases are opened, enriched, escalated and closed, and where case data lives
- Documented ingestion sources and playbook inventory, with secret values excluded from the documents
- Walkthrough for analysts and operators, with test results delivered in writing
How we support
- Optional retainer covering upgrades, patching and playbook changes as new Shuffle releases ship
- Review of case data retention and backup coverage against your incident response policy
- Triage of failed ingestion and playbook runs, with any further changes agreed in writing
