What the Wazuh and Shuffle SOAR integration does for your SOC
The Wazuh and Shuffle integration sends selected Wazuh alerts to Shuffle workflows through the Wazuh integrator, and the alert level and rule filters you choose decide how many alerts reach those workflows. Many security teams already see Wazuh alerts in the dashboard but still copy them into a ticket, look up an indicator in a threat feed, or isolate a host by hand. This section explains what each side owns so you can decide which alerts should trigger automation and which should stay with an analyst.
Wazuh remains the detection layer. Agents collect endpoint data, the Wazuh server decodes it and applies rules, and the Wazuh indexer stores the resulting alerts for search. Analysts still review the evidence in the Wazuh dashboard. The integrator forwards only the alerts that pass your filters, so an event that no rule raises, or that a filter drops, never reaches Shuffle. Custom rules and decoders stay in Wazuh, and a change there alters what Shuffle receives. Confirm with your Wazuh administrators who approves rule changes, because a tuned rule can quietly change workflow volume.
Shuffle runs the response. Shuffle is an open-source SOAR platform that started in mid-2019 for the CERT and SIRT community, and its code is licensed under AGPL-3.0. Ask your legal team to review that license against your planned use before you build custom apps on top of it. In Shuffle, a workflow starts from a trigger, runs actions through apps, and records each execution. The backend and OpenSearch store workflows and saved credentials, while Orborus starts a worker and app containers for each run. Your team owns the workflow logic, the enrichment sources and the credentials used to reach ticketing or containment tools.
The integration is only as good as its filters. A broad severity threshold or a rule group that matches routine informational events can send a large volume of alerts into workflows that each call external services. That load lands on your ticket queue, your API quotas and your Shuffle runtime. Start with a narrow set of high-severity rules tied to a clear response, measure how many runs each produces over a representative period, and widen the scope only when analysts agree the output is useful. Check that each workflow handles repeated alerts for the same event, since one incident can trigger more than one run. Confirm the exact filter options in the Wazuh version you deploy before you write the design.
Prerequisites before the Wazuh and Shuffle SOAR integration starts
These checks settle the versions, architecture, network and trust decisions that every later step depends on. Work through them with the team that will run the Wazuh manager and the Shuffle platform, and record each decision in writing before you install anything.
Wazuh release line and patch level
Confirm which Wazuh 4.14 patch the manager runs before you build the integration, because alert formats and API responses should be tested against that exact version. The latest supplied patch is 4.14.9, released on 14 October 2026, and 4.14.8 followed on 23 September 2026. Wazuh has shipped 4.14 patches roughly every one to two months, so record the tested version and plan a retest before you adopt each new patch.
Shuffle release and image tag
Shuffle v2.3.0 was published on GitHub on 28 September 2026. The Shuffle docs recommend the latest Docker tag for stable use and the nightly tag only for experimental changes, so pin the tag you test and record it in the change ticket. Ask your Shuffle contact or implementation partner to confirm that the chosen tag supports the app and workflow features your playbooks depend on.
Deployment architecture choice
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. Choose one before the network design, because it sets which components you host, how many servers you run and whether you need an OpenSearch cluster and several Orborus nodes for high availability. Name the team that will operate the chosen model after go-live.
Network path from manager to Shuffle
Map every connection the Wazuh manager must make to the Shuffle webhook or API endpoint, including the port, DNS name, any proxy and each firewall rule between the two networks. The hybrid model needs no inbound firewall ports at your site, because the local Orborus connects out to Shuffle Cloud, so the firewall design changes with the architecture. Confirm the required endpoints in the Shuffle architecture docs before you request rules.
TLS certificate trust between systems
Decide how the Wazuh manager will trust the certificate presented by the Shuffle endpoint. If your certificates come from an internal certificate authority, install its trust chain on the manager and confirm the certificate name matches the hostname the manager calls. Plan renewal and rotation on both sides, since an expired certificate can stop alerts from reaching workflows and may appear only as failed deliveries.
Encryption key and stored credentials
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. Generate the value before the first login, store it in your secrets manager and back it up with the rest of the platform configuration. The Shuffle docs warn that losing or changing it breaks every saved app authentication, so treat it as a recovery-critical secret.
How Wazuh alerts reach Shuffle workflows
The alert path has four hops, and each one is a point where volume can be reduced or lost. A Wazuh agent on an endpoint collects events and forwards them to the Wazuh server. The server runs decoders to extract fields from each event, then applies rules that assign a severity level and classify what happened. Alerts that match a rule are stored by the Wazuh indexer, which the dashboard reads. The integrator, a Wazuh integration mechanism, forwards selected alerts to an external system, and in this design that system is a Shuffle workflow trigger. Only the alerts the integrator passes on can start a workflow, so the Wazuh side decides how much work reaches Shuffle at all.
Two Wazuh-side decisions control that volume before any workflow starts. The first is the alert level threshold. Rules carry levels, and the integrator should forward only the levels your playbooks are built to handle. The second is rule scope, meaning the rule IDs or rule groups known to produce frequent but low-value alerts, such as routine authentication events or scheduled tasks on specific hosts. Confirm the exact integrator configuration keys, their syntax, and whether level and group filtering happens in the integrator or in the server rules, against the Wazuh documentation for the versions you run. Do not copy keys from older guides or forum posts without checking them against current documentation.
On the Shuffle side, the Go backend API listens on port 5001 and keeps its workflow and execution data in the OpenSearch document store. Orborus, the runtime component, polls the backend for jobs. When a workflow execution begins, Orborus starts a worker for that execution, and the worker starts the app containers that carry out each action, for example (illustrative) a reputation lookup followed by a ticket creation. Confirm which Shuffle trigger type accepts integrator output for your release, and whether it is an HTTP endpoint that the Wazuh server must reach on port 5001 or through a proxied path. That answer determines firewall rules, TLS termination, and whether the Wazuh server, the Shuffle backend, or both need network access to each other.
Plan for load as well as logic. Confirm whether each forwarded alert starts its own workflow execution. If it does, a burst of alerts becomes a burst of workers and app containers on the runtime side. The Shuffle configuration documentation recommends more than one Orborus node so workflows keep running if one fails, so check how many nodes your architecture runs and how they are scaled. Before connecting production alerts, send a controlled test alert through the integrator path, confirm the execution appears in Shuffle, and record the time from agent event to workflow start. Use that measurement to set level thresholds and rule filters, and repeat the test after each Wazuh or Shuffle upgrade.
Step-by-step setup for the Wazuh and Shuffle SOAR integration
This sequence connects a self-hosted Shuffle instance to the Wazuh manager so that a controlled set of alerts starts a workflow. Each step ends with a check you can run before you widen the alert filter or add response actions.
Deploy and verify the Shuffle backend
The platform team deploys the Shuffle frontend, the Go backend API and the OpenSearch document database in the architecture chosen for the environment, such as the single-server Docker Compose option or a Kubernetes deployment with Helm charts. Confirm that the backend API answers on port 5001, that OpenSearch reports a healthy state and that you can sign in to the frontend as the first administrator. Use the latest Docker tag for stable releases, as the Shuffle documentation recommends. Check: the frontend loads, the backend responds to an authenticated API call, and the OpenSearch health check passes. Confirm the compose file, image tags and health endpoints in the Shuffle configuration documentation before you start.
Start Orborus and confirm it runs jobs
Start Orborus, the runtime component that polls the backend for jobs, starts a worker for each workflow execution and launches app containers. Point it at the backend and read its logs for a successful connection and regular polling activity. In a hybrid setup with Shuffle Cloud, the local Orborus needs no inbound firewall ports, so confirm outbound connectivity instead. Check: the Shuffle environment shows Orborus as active, and a simple test workflow that uses a built-in action starts and completes. Plan for more than one Orborus node if the workflows must keep running through a single node failure, as the configuration documentation describes.
Create the webhook trigger and record its endpoint
Create a workflow that starts with a webhook trigger, name it for the alert source and environment, and save the generated endpoint. Keep the workflow in a non-production state until the tests in the later steps pass. Treat the endpoint as a secret, because anyone who holds it can start the workflow, and record it in your secrets manager. Check: a manual request with a sample JSON body sent to the endpoint creates an entry in the workflow execution log. If no entry appears, confirm that the trigger is running and that Orborus is active before you change anything on the Wazuh side.
Store credentials with the encryption modifier
Add each credential the workflow needs, such as ticketing or chat API keys, through Shuffle's authentication settings and keep secret values out of workflow step text. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. Set that secret before the first credential is saved, and store a copy in a controlled location. The documentation warns that losing or changing it breaks all saved app authentications, so any later change needs a planned re-entry of credentials. Check: a test action that uses the saved credential returns a successful response. Confirm how the modifier is injected into your deployment using the configuration documentation.
Configure the Wazuh integrator with a narrow filter
On the Wazuh manager, add an integration block that sends alerts to the webhook endpoint as JSON. Start with a high minimum alert level and a single rule group or agent group so that only a small, known set of alerts reaches Shuffle. Triggers are not counted toward app runs, but every action that executes is, so a broad filter drives both workflow noise and usage. Restart or reload the manager as the Wazuh documentation describes for integration changes. Check: the integration logs show the integrator starting without errors. Confirm option names, the alert level scale and the reload procedure for your Wazuh version before you apply them.
Send a controlled test alert
Generate one test event on an enrolled lab agent that matches the filter, using a method your team has approved for the test. Confirm the alert appears in the Wazuh dashboard and in the manager's alert output before you investigate the integration. Then confirm the alert reaches Shuffle with the fields your workflow needs, typically the agent name, rule ID, rule description, alert level, timestamp and full log. Field names depend on the alert format your Wazuh version produces, so check them against a saved sample alert before you write mapping steps. Check: the webhook execution contains the expected fields and no unrelated alerts arrived.
Confirm the workflow run and app-run count
Open the workflow execution log and confirm one execution for each test alert, with the trigger input matching the sample alert and every action showing a completed status. Then check the app-run count in your Shuffle usage or licensing view and compare it with the number of actions you expected to run. Triggers and skipped actions are not counted, so a difference usually points to an unintended or failed action. Check: execution count equals test alerts sent, no unexpected executions appear, and app runs match the expected action count. Record these numbers as the baseline for any later filter change.
Choosing alert levels and rule filters so workflows are not flooded
Begin with a high alert level so that only the most significant Wazuh alerts reach Shuffle at first. Each Wazuh rule carries a level that reflects its assessed severity, and the integration can forward alerts at or above a chosen level. Lowering the threshold is a measured step, not a default, because every extra alert that passes the filter can start a workflow and its actions.
A practical sequence looks like this:
- Enable one workflow at a high threshold and record how many alerts arrive per day for a representative period.
- Review a sample of those alerts to confirm they are worth an automated action.
- Lower the threshold one step at a time, measuring volume and analyst feedback at each step.
- Stop lowering when the added alerts stop producing useful investigations.
- Document the threshold and the reason for it in the workflow record.
Before sizing anything, check how your Wazuh version and integration configuration express the level filter, because the option names and behavior should be confirmed in the documentation for the release you run. Ask the implementation team to show the measured volume at each threshold you considered.
Level alone is a blunt tool because a single level can contain alerts for very different events. Wazuh rules are organized into groups, and selecting groups lets each workflow receive only the event families it was designed for. An authentication enrichment workflow and a file integrity ticketing workflow should not share the same input stream.
Typical pairings include:
- Authentication rule groups feeding an enrichment workflow that adds user, host and geolocation context to the alert.
- File integrity monitoring events feeding a ticketing workflow that opens a change or investigation record.
- Vulnerability or inventory alerts feeding a workflow that assigns patching work to the owning team.
- Configuration or policy violations routed to a compliance review queue.
For each pairing, write down the group, the workflow it feeds, the owner who receives the output and the action that is allowed to follow. Groups should be confirmed against the rule set in your own deployment, since custom rules may add or change group membership. Ask the team to demonstrate that a test event from one group does not reach an unrelated workflow.
Some alerts repeat because of a known and approved cause, such as a backup job that reads many files, a vulnerability scanner that authenticates to hosts, or a service account that logs in on a schedule. Excluding these alerts removes volume without reducing visibility, provided the exclusion is narrow and documented. A broad exclusion can hide the activity that the rule was written to catch.
When building exclusions:
- Tie each exclusion to a specific rule, agent or source and a named business owner.
- Confirm the benign cause with that owner and record the evidence.
- Limit the match to the expected host, account or path rather than the whole rule.
- Set a review date so exclusions are checked when the scanner, job or account changes.
- Keep a count of suppressed events so the team can see whether the exclusion is still doing its job.
Exclusions belong in version-controlled configuration where changes are reviewed. Ask your implementation partner how exclusions will be tested, and ask for the process that removes an exclusion when its cause no longer exists.
Enrichment and response workflows have different risk profiles, so they should be separated even when they start from the same Wazuh alerts. An enrichment workflow reads data from other systems and adds context to an alert. A response workflow changes something, such as disabling an account, isolating a host or blocking an address. Mixing the two means a noisy alert can trigger a change in production, which is a much larger consequence than a wasted lookup.
A workable separation:
- Run enrichment on a wider set of alerts, because its actions are read-only and cheap to repeat.
- Restrict response to a narrow set of rule groups and a higher threshold.
- Require approval steps or a human decision before any response action that changes an identity or a system.
- Give each workflow its own credentials, scoped to the minimum actions it needs.
- Log each run so responders can trace which alert started which action.
This split also helps tuning, since enrichment can run broadly while response stays conservative. Ask for the list of response actions that can run without approval and confirm that each one has been tested in a non-production environment.
Shuffle says its open-source and paid editions offer the same features, with differences in feature limits, scaling and support. On its pricing model, licensing is based on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, while users, apps and workflows are described as unlimited. This means unfiltered alert volume can increase cost, because every alert that starts a workflow path with executing actions adds to the metric.
What to check before sizing:
- Confirm the licensing metric for the edition and tier you intend to run, since the pricing article and your contract are the authoritative sources.
- Estimate how many executing actions each enrichment and response path performs per alert, and identify branches that run on every event.
- Compare measured alert volume at each filter threshold against the expected action count.
- Note that since version 2.1.1, limits between the open-source and enterprise editions are actively enforced, so confirm which limits apply to your deployment.
- Ask for a written quote that states the metric, what counts toward it, and whether the rate changes with volume.
Treat the metric as a design input. Ask your partner to show the expected app-run count per day for each workflow at the proposed thresholds before the filters are finalized.
Mapping Wazuh alert fields to Shuffle workflow inputs
This table maps the Wazuh alert fields most workflows need to Shuffle workflow inputs, with how each one is used and filtered. Confirm the exact field names from a sample alert captured from your running Wazuh version before you build any mapping. The main takeaway is that rule ID and rule level should gate a workflow early, before enrichment or response steps run.
| Wazuh field | What it means | How the Shuffle workflow uses it | Filtering note |
|---|---|---|---|
| Rule ID | Identifier of the Wazuh rule that produced the alert | Branches the workflow so each known rule routes to its own enrichment or ticket path | Allow-list the rule IDs the workflow handles and drop the rest before any action runs |
| Rule level | Severity score the rule assigns to the alert | Gates ticket creation and response actions, so only alerts above the threshold proceed | Set a minimum level in the integration, then lower it only after reviewing volume in a test environment |
| Rule description | Human-readable text describing what the rule detected | Becomes the ticket title and the summary in chat notifications | Use text matching only as a secondary check, since wording can change between rule updates |
| Agent name and ID | Endpoint or agent that reported the event | Looks up the host in your asset inventory to choose the owner and the response target | Scope workflows to production agent groups and exclude test or lab hosts |
| Source and destination fields | Network or user identifiers, present only for rules that extract them | Passes addresses to threat intelligence or directory lookups when the field exists | Run lookups only when the field is present, and skip private addresses for external services |
| Timestamp | Time the event was recorded, including its time zone | Sets the ticket time and the query window for lookups in other tools | Confirm the format and time zone in the sample, and use it to group repeats within a window |
| Full alert JSON | Complete alert record, including the decoded log content | Attached to tickets as evidence and parsed for fields used in later steps | Keep it out of broad chat channels, since the raw log content can include sensitive data |
Security settings for the Wazuh and Shuffle SOAR integration
These controls protect the path from Wazuh alerts to Shuffle workflows, where an alert can trigger actions that change endpoints, accounts and firewalls. Each card names a setting to design before go-live and a check to run afterward. The encryption secret and the response action permissions decide whether the integration keeps working and who can trigger changes.
Back up the Shuffle encryption secret
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 fails, including the credentials the Wazuh integration depends on. Store the secret in your secrets manager with a tested restore copy. Do not rotate it without a written plan that re-enters each saved credential. Ask your team to confirm the restore procedure in a non-production copy before go-live.
Restrict who can edit workflows
Workflows that run response actions can disable accounts, isolate hosts or call external APIs, so edit rights are a privilege. Limit edit access to a named group, and keep people who build workflows separate from those who approve changes to them. Place every workflow triggered by Wazuh under change control, with a named owner. Review the list of users with edit rights on a schedule your security team sets, and remove access that no longer matches a current role.
Use SSO for Shuffle and Wazuh administrators
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, both available on premises, with per-tenant SSO enforcement. Wazuh supports SAML single sign-on alongside its internal user database. Choose the protocol each platform will use, enforce SSO for administrators, and keep one documented break-glass local account. Shuffle's docs say SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so confirm the option your self-hosted version supports before you design the identity flow.
Limit dashboard and frontend exposure
The Wazuh dashboard and the Shuffle frontend are administrative interfaces and should not be reachable from the open internet. Publish them on an internal network, or behind a VPN or reverse proxy that enforces the SSO check. Keep the Shuffle backend API on port 5001 off public networks. If you use the hybrid model with a local Orborus, confirm the firewall rules it requires, since Shuffle's docs say that model needs no inbound firewall ports. Verify exposure with an external scan after each change.
Pin image tags and set an upgrade cadence
Shuffle's docs recommend the latest Docker tag for stable releases and the nightly tag for experimental changes. Nightly images should not run production workflows that take response actions. Pin each Shuffle and Wazuh image to a specific version tag, record it in your change log, and test updates in staging first. Wazuh shipped six 4.14 patch releases between March and October 2026, roughly every one to two months, so schedule a recurring review of release notes and an upgrade window.
Treat response actions as privileged changes
Active response and Shuffle actions can alter endpoints, accounts and firewall rules, so they need the same controls as administrative access. Add an approval step before destructive actions such as host isolation, account disablement or file deletion, and route the approval to someone outside the workflow's builders. Give each app a service account with the smallest scope it needs, and log each execution with the triggering alert ID. Test the approval path in a tabletop exercise before enabling it in production.
Testing the integration before workflows go live
Before any Wazuh alert reaches a production workflow, run the integration through a written test plan and record the results at each filter level. Replay a fixed set of known alerts, including some that should match and some that should not, against each alert level and rule filter you intend to use. For every replay, confirm that the integrator forwards only the alerts that should match, then open the Shuffle workflow execution and note which actions ran. Compare that count with the expected app-run count. Shuffle meters licensing by app runs, which are actions that actually execute, so triggers and skipped actions do not add to the count. A workflow that runs more actions than the plan predicts usually has a filter or branching problem, and it should be fixed before go-live.
Next, test the failure paths on purpose. Point one test action at an endpoint that does not respond, and confirm that the execution fails visibly, that the failure reaches the workflow owner, and that no step retries into a ticketing or containment system. Then expire or revoke the credential for one saved app in a non-production tenant and confirm that the error is logged and that the integrator does not keep resending the same alerts. Also verify that the SHUFFLE_ENCRYPTION_MODIFIER value on the test server matches the value your team has documented. The Shuffle configuration docs warn that losing or changing it breaks every saved app authentication, so a restore test should check this as well. Ask the vendor how retries behave in the version you run.
The Shuffle configuration docs recommend more than one Orborus node so workflows keep running if one fails. During the test window, stop one Orborus node while replays are in progress. Watch whether the remaining node picks up the queued jobs, how long the affected executions take to start, and whether any execution runs twice. Record the outcome and decide whether a single node is acceptable for the workflows in scope. If the answer is no, add a second node before go-live and repeat the test. Also confirm that the stopped node rejoins cleanly when it is started again. The documentation describes the design intent, but it does not give timing for failover in your environment, so measure it yourself and keep the results with the change record.
Label every test alert so it cannot create tickets or trigger containment in production systems. Use a dedicated test rule identifier or a test agent group, and make the first step of each workflow check for that label and stop when it is present. Confirm in the Wazuh server configuration which fields the integrator filter can match, and exclude the test label from production integration blocks before any live alert flows. Finally, write a rollback path and rehearse it once. The path should disable the integrator block in the Wazuh server configuration, apply the change through your normal change process, confirm that no new executions appear in Shuffle, and decide what happens to queued jobs. Name one owner for the rollback, and record the exact steps so that an on-call engineer can follow them at night.
Common failures in the Wazuh and Shuffle SOAR integration
This table maps the failures teams most often see when Wazuh alerts feed Shuffle workflows, with the likely cause and a fix for each. Start with the symptom you observe, then check the cause in the order listed, since the first causes are the cheapest to rule out. Confirm every parameter name against the current Wazuh and Shuffle documentation for your versions before changing production settings.
| Symptom | Likely cause | Fix |
|---|---|---|
| No alerts reach Shuffle: filter too strict | The level or rule group filter in the Wazuh integration block excludes the alerts you expect to see. | Lower the level temporarily in a test environment, trigger a known test alert, and confirm it arrives before restoring the filter. |
| No alerts reach Shuffle: wrong endpoint | The hook URL points to the wrong host, port or webhook path, often the Shuffle backend on port 5001 or a stale workflow webhook. | Copy the webhook URL from the workflow's trigger in the Shuffle interface, then confirm the Wazuh manager can reach that exact address. |
| No alerts reach Shuffle: certificate trust | The Wazuh manager does not trust the certificate presented by the Shuffle endpoint, usually a private or internal certificate authority. | Install the internal CA certificate in the trust store the Wazuh manager uses, then check the manager log for TLS errors after restart. |
| No alerts reach Shuffle: firewall path | A host firewall, network security group or proxy blocks traffic from the Wazuh manager to Shuffle. | Test connectivity from the Wazuh manager host to the webhook address, then open only the required source and destination pair. |
| Workflows flooded with alerts | The alert level threshold is set too low, or broad rule groups pull in routine events such as successful logins. | Raise the level threshold, filter by specific rule groups or rule IDs, and review a day of matched alerts before enabling the workflow. |
| Workflows fail after a credential change | The SHUFFLE_ENCRYPTION_MODIFIER secret was changed or lost, so saved app credentials in OpenSearch can no longer be decrypted. | Restore the original secret from your secrets store and restart the backend. If it cannot be recovered, re-enter each app credential and record the new secret. |
| Runs stop when one Orborus node fails | Only one Orborus node is running, so no worker starts when that node goes down. | Run at least two Orborus nodes as the Shuffle high availability guidance describes, and test failover by stopping one node during a scheduled run. |
| Unexpected app-run cost on paid tiers | Unfiltered alert volume triggers many actions that execute, and each executed action counts as an app run. | Filter alerts before the first executing action, and confirm with Shuffle how app runs are counted for your edition before scaling volume. |
| Version drift after an upgrade | The Wazuh integration script or Shuffle app field names changed, so the workflow reads keys that no longer exist. | Compare field names in a sample alert and the app specification against the release notes, then update the workflow in a test instance before upgrading production. |
Questions buyers ask before hiring help with the Wazuh and Shuffle SOAR integration
What drives the cost of a Wazuh and Shuffle integration project?
The cost follows the written scope, and four factors move it the most: the number of workflows, the design of the alert filters, the Shuffle deployment architecture, and the high availability and testing required. Each workflow needs a trigger, enrichment steps, ticketing or response actions, and error handling, so more workflows means more build and test time. Filter design sets how many alerts reach Shuffle at all, which shapes workflow logic and later tuning. A single server running Docker Compose is a smaller build than a distributed Docker Swarm, Kubernetes or multi-node high availability setup. Software is a separate line. Wazuh is open source with no license fee for self-hosting, and Shuffle's open-source edition includes all features, while its paid tiers differ in feature limits, scaling and support. Ask for the build, testing, infrastructure and any licensing costs to be itemized in the quote.
How long does the work take for our environment?
The duration depends on the scope, and no single figure applies to every environment. The main variables are how many workflows you need, how many enrichment and ticketing systems must be connected, whether Shuffle runs on one server or in a high availability design, and how much testing and change control your organization requires. A pilot on one server with a few workflows is a different project from a multi-node build with approval-gated response actions. Because the answer depends on those inputs, ask for a fixed-scope timeline with milestones, the dependencies on your access approvals and change windows, and the acceptance tests that close each phase. Most DeployOpen engagements are fixed-scope, so the agreed scope and timeline are written down before work starts. Confirm who owns delays on your side, such as slow access grants or late approvals.
Which costs are one-time and which recur after go-live?
The build is one-time work, while several items recur after go-live. One-time costs include design, the initial Shuffle and integrator setup, the first set of workflows, filter design and acceptance testing. Recurring work includes upgrades, filter tuning and app maintenance. Wazuh shipped 4.14 patch releases roughly every one to two months in 2026, so plan for regular patching of the manager, indexer, dashboard and agents. Shuffle publishes new versions as well. Its v2.3.0 release was published on September 28, 2026, and its docs recommend the latest Docker tag for stable releases. Filter tuning never fully ends, because alert volume changes as agents, rules and environments change. Custom Shuffle apps also need maintenance when the external APIs they call change. Ask whether upgrades, tuning and app support are offered as a retainer, and what each one includes.
What must our team provide before the integration work starts?
Your team provides the access and decisions the build depends on, so name them before kickoff. You need access to the Wazuh manager with rights to change the integration configuration, Shuffle administrator rights to create workflows, apps and credentials, and credentials or API access for each target ticketing and enrichment system. Assign an approver for response actions, someone who can confirm which automated steps are allowed, such as isolating a host or disabling an account, and who receives escalations when a step fails. Also provide a non-production environment for testing, a change window for production cutover, and a named contact for security and infrastructure questions. Confirm how secrets will be stored, because Shuffle encrypts saved app credentials with a secret you must keep safe. Access requests are often the longest step, so start them first and list each item in the scope document.
Can our own team build this integration without a partner?
Yes, for a small pilot on a single server, a capable in-house team can build the integration if it already knows both Shuffle and Wazuh well enough to operate them. The decision depends on that experience more than on the tools themselves. Check whether your engineers have built Shuffle workflows, managed its OpenSearch document store and backend, run Orborus runtime nodes and handled secrets, and tuned Wazuh rules and alert levels. A team new to either product should expect a learning curve, and early workflows often need rework once real alert volume and edge cases appear. Consider a partner when you need several workflows, high availability, a distributed architecture, test evidence for an assessment, or a handover your staff can run afterward. Some organizations split the work, with their own team building the core workflows and a partner reviewing filters and architecture before production.
How do we stop Wazuh alerts from flooding Shuffle workflows?
Filter at the source, then widen the scope in stages. Start by choosing which alerts reach Shuffle at all, using alert level thresholds, rule IDs and rule groups in the integrator configuration. Begin with a narrow set, such as high-severity alerts from a few critical hosts, and expand only after you have measured the volume each workflow produces. Each workflow should have a clear trigger, an early exit for alerts that need no action, and a deduplication or rate step so one noisy host cannot start a large number of runs. Test with sample or replayed alerts in a non-production Shuffle instance before enabling response actions. Shuffle's paid licensing counts app runs, so unnecessary runs also affect cost on paid tiers. Review volume often during the first month after go-live, and record every filter change so you can explain why an alert started or stopped reaching a workflow.
Which Shuffle architecture suits a high availability requirement?
A single server with Docker Compose suits a pilot, while high availability requires a multi-node design. Shuffle documents four architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid of Shuffle Cloud with a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. For high availability, Shuffle's configuration 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 servers, and more than one Orborus node so workflows keep running if one fails. Each choice adds build and test effort. Plan for the encryption secret too. Shuffle encrypts saved app credentials in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value, and losing or changing it breaks every saved app authentication. Store it in your secrets system and test a restore before go-live.
What should a quote for this integration include?
A useful quote shows the written scope, not only a total. Ask for the number and purpose of each workflow, the alert filters and levels to be configured, the Shuffle architecture and whether high availability is included, and the enrichment and ticketing systems in scope with their access method. Confirm the response actions and approval steps, the testing covered, including non-production runs and acceptance criteria, and the documentation and handover sessions. The quote should name the Wazuh and Shuffle versions the work targets and list what is excluded, such as software licenses, infrastructure or changes made by external API providers. Ask for the timeline with milestones, which items are one-time, which are offered as a retainer for upgrades, tuning and app maintenance, and how scope changes are priced and approved. DeployOpen does not publish a price list, so the quote follows from the written scope.
How DeployOpen scopes, builds and supports this integration
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Wazuh and Shuffle SOAR integration, the Wazuh integrator, alert filters and Shuffle workflows are designed together and run in your cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- The written scope names the Wazuh agents, endpoints and log sources feeding the integration.
- Alert levels, rule groups and filters are agreed up front, with the expected alert volume per workflow recorded before build.
- Engagements are fixed-scope, and ongoing support for the integration can be added as a retainer.
How we build
- Wazuh forwards only the alerts in scope to a Shuffle webhook through the integrator configuration.
- Shuffle workflows are built for enrichment, ticketing and response steps, each tested against replayed sample alerts.
- Shuffle's encryption secret is set and backed up before any app credentials are saved.
How we hand over
- Handover includes the configuration, workflow definitions and filter rules, documented for the team that runs them.
- Runbooks cover workflow failures, alert volume spikes and the rules for changing the Shuffle encryption secret.
- Your team receives access to the test cases and a list of open items, agreed in writing.
How we support
- Support can cover upgrades to Wazuh and Shuffle, checked against release notes before each change.
- Retainers can include tuning of alert filters as log sources and rule sets change over time.
- Continuous security testing of the workflows and APIs can be scoped alongside the support agreement.
