Open-source alternative to Google SecOps SOAR

Open-source alternative to Google SecOps SOAR: the short answer

If your Google Security Operations renewal, a pricing change or a data residency requirement has made you look at the SOAR features bundled into your package, Shuffle is the self-hosted open-source SOAR option that covers playbook-style automation, integrations and case handling. Shuffle is a separate product from the SIEM, so it does not replace the detection and log search side of SecOps on its own. Its code is licensed under AGPL-3.0, and it started in mid-2019 for the CERT and SIRT community, which is why its workflow model and app catalog lean toward incident response work.

You do not need to switch the SIEM and SOAR at the same time. Google SecOps can keep ingesting logs and raising alerts while Shuffle takes over the response steps, such as enrichment, ticket creation and containment actions, in your own infrastructure. The SIEM side is often paired with Wazuh, which is the detection and endpoint option most commonly used alongside Shuffle in this topic, and it can be evaluated in parallel. This page covers what Shuffle does, where it falls short and what the work needs from your team.

The main gaps are operational. Shuffle's server side runs a Go backend, a frontend and an OpenSearch document database, and its runtime uses Orborus nodes that start a worker for each execution, so someone must own hosting, upgrades and high availability. Its docs describe single-server, Swarm, hybrid and Kubernetes layouts, and you should confirm which one fits your residency and uptime needs. Before you commit, check the app coverage for your existing integrations, plan the SHUFFLE_ENCRYPTION_MODIFIER secret as carefully as any production key, and confirm the edition limits and paid features against your current SecOps contract.

Which SOAR capabilities map to Shuffle and where to confirm gaps

This table lists SOAR capabilities typically bundled in Google SecOps packages and names the open-source component that covers each one in a self-hosted stack. Read the coverage notes as starting points for your own evaluation, and treat the rows marked for confirmation as open questions to settle against your SecOps configuration and Shuffle's current documentation before you commit.

Capability	Shuffle or open-source component	Coverage note
Playbook automation	Shuffle workflows	Workflows chain app actions and triggers. Confirm that each SecOps playbook step has an equivalent app action or a custom app.
Integrations with detection sources	Wazuh alerts as workflow triggers, plus Shuffle apps	Wazuh alerts can start workflows. Confirm the trigger and field mapping for each detection source you route, including any Google-native sources.
Custom integrations	Shuffle apps built from OpenAPI specifications or the Python app SDK	Apps are built from OpenAPI specs in the App Creator or written in Python, and run as versioned Docker containers. Estimate effort per integration before scoping.
Threat intelligence enrichment	Shuffle apps for threat intelligence lookups	Enrichment is built as app actions inside workflows. Confirm which feeds your team uses and whether an existing app or a custom app covers each one.
Case handling	Confirm in Shuffle's current docs	Case management is not confirmed in the supplied facts. Check whether Shuffle covers your case lifecycle or whether a ticketing or case system must be integrated.
Google-specific SecOps features	Confirm against your SecOps configuration	Features tied to Google Cloud or SecOps, such as native case views or built-in enrichment, have no confirmed equivalent. List them from your own configuration and map each one.
Access control and SSO	Shuffle SAML or OpenID Connect single sign-on	Shuffle added SAML in version 0.9.16 and OpenID Connect in 1.0.0, with per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect.
Audit of automated actions	Shuffle workflow execution records in OpenSearch	Confirm the retention, export format and fields you need for audit evidence. Store app credentials carefully, since losing the SHUFFLE_ENCRYPTION_MODIFIER secret breaks saved authentications.

Which open-source options fit a SOAR replacement and when

A SOAR replacement is rarely one product. Shuffle handles playbooks and case-driven response, while a detection source, a search store and a case tool supply the data and records it works on. Each card below names one role, when it fits, and what your team must confirm before committing.

Shuffle as the SOAR platform

Shuffle replaces the playbook layer of Google SecOps SOAR with workflows built from apps and triggers. Its open-source edition includes all features, and since v2.1.1 the limits between the open-source and enterprise editions are actively enforced, so confirm which limits affect your planned execution volume, scaling and support needs. Check that each integration you rely on, such as your ticketing system, identity provider or threat intelligence feed, exists as a Shuffle app or can be built from an OpenAPI specification.

Wazuh as the alert source

Wazuh produces the alerts that Shuffle workflows respond to, covering log analysis, file integrity monitoring and vulnerability detection from its agents. It fits teams whose SOAR playbooks start from endpoint or host events and need compliance dashboards for frameworks such as PCI DSS and GDPR. Confirm that your log sources can reach Wazuh through agents or syslog, and plan who writes and tunes the rules that replace the detections your SecOps rules currently provide.

OpenSearch as the data store

OpenSearch holds the alerts Wazuh writes through its indexer and serves the search needs of Shuffle, which stores its own documents there. It fits teams that want to size retention and storage themselves rather than rely on contract-defined retention. The trade-off is that you operate the cluster, backups and capacity planning yourself. Confirm the cluster sizing for your alert volume and whether your investigators need query features that your current SecOps search provides.

Existing case management tool

If your SOC already runs a case or ticketing tool, keep it as the system of record and have Shuffle create and update cases through its app integration. This fits organizations where audit trails and approvals already live in ITSM or case software. Confirm that the tool offers a documented API with the actions your playbooks need, and decide which system owns case status so that analysts do not work the same incident in two places.

What changes for the SOC when SIEM and SOAR become separate products

In a bundled Google SecOps package, detections, alert queues and playbooks sit in one console and share one identity model, so an analyst moves from alert to response without crossing a product boundary. A split stack changes that. Wazuh raises alerts, and Shuffle picks them up only when a trigger is configured and a workflow is built to act on them. The team now owns that boundary: which alerts start which workflows, how case data is passed back, and who can edit either side. Before cutover, document each trigger, the alert fields the workflow depends on, and the roles that can change them.

Playbook logic also moves. Instead of a vendor-managed playbook library, the team builds workflows in Shuffle and maintains them like other production code: versioning, review and testing become SOC responsibilities. Each app connection stores credentials and API keys in OpenSearch, encrypted with AES-256 under the SHUFFLE_ENCRYPTION_MODIFIER secret. The Shuffle documentation warns that losing or changing that value breaks every saved app authentication, so the secret belongs in your secrets store and in your backup procedure, and a restore test should confirm that saved credentials still work after recovery.

A failure between Wazuh and Shuffle is a new monitoring item that a bundled product did not require. A trigger can stop firing, a workflow can fail on an expired token, or an Orborus runtime can go down, and none of these shows up as a SIEM alert by default. Add health checks for the trigger path and for workflow execution failures, and decide who is paged. Confirm how your chosen deployment handles Orborus redundancy, since the Shuffle configuration docs recommend more than one node so workflows keep running if one fails.

Choosing a Shuffle deployment architecture for your environment

A single server with Docker Compose suits a team that is starting with Shuffle, has a modest number of workflows, and wants the smallest set of moving parts. Everything, including the frontend, the Go backend API, the OpenSearch document database and the Orborus runtime, runs on one host, so the team is responsible for one machine, its patching, its backups and its capacity.

Operating model: Your team maintains one host, the Compose file, Docker images and the OpenSearch data directory.
Backend API: The Go backend listens on port 5001, so plan how analysts and the SIEM reach it.
Encryption secret: Set SHUFFLE_ENCRYPTION_MODIFIER before saving any app credentials, because losing or changing it breaks saved authentications.
High availability: This layout has no redundancy. A host failure stops all workflows until you restore the server.
Growth path: Moving later to a multi-server layout requires planning the OpenSearch cluster and shared storage.

Confirm sizing against your own alert volume and workflow load, and test restores of the OpenSearch data before relying on this architecture for production cases.

Kubernetes with Helm charts suits a platform engineering team that already runs clusters, has standard practices for ingress, storage and secrets, and wants Shuffle managed like other workloads. The team deploys the components as Kubernetes resources and uses the Helm charts documented by Shuffle as the starting point.

Platform fit: Your team uses existing cluster controls for upgrades, resource limits and network policy.
OpenSearch and storage: Provide persistent volumes for the OpenSearch cluster and plan backup and restore for them.
Shared files: Where several backends need shared files, the storage class must support shared access, as with NFS in the Swarm pattern.
Runtime nodes: Run multiple Orborus instances across nodes so a node failure does not stop every workflow.
Secrets: Store SHUFFLE_ENCRYPTION_MODIFIER in your cluster secret store and keep it out of chart values files in version control.

The team operates the cluster, the Helm releases, storage and upgrades. Confirm sizing against your own alert volume and workflow load, and confirm with the Shuffle architecture and configuration docs which chart version matches the Shuffle release you plan to run.

Running Shuffle beside Google SecOps during the transition

During a transition, Shuffle usually sits beside Google SecOps rather than replacing it on day one. The cards below cover the integration points that connect the two, who owns each one, and where duplicate actions are most likely while both platforms can act on the same alert.

Pulling alerts and case context from SecOps

A Shuffle workflow can call the SecOps API to fetch alert and case details, then route them to the right queue or responder. The integration owner is usually the SOC engineering team, who holds the API credentials and writes the Shuffle app or OpenAPI-based integration. Keep the credentials in Shuffle's encrypted store and record who can edit them. Confirm the current SecOps API endpoints, authentication method and rate limits before building, and check whether a ready-made Shuffle app exists or whether you need to write one.

Sending Wazuh alerts to Shuffle

When Wazuh runs as the detection source for endpoints or firewalls, Shuffle can receive its alerts and run response steps such as enrichment, ticket creation or host isolation requests. SecOps stays the SIEM of record in this model, so the same event may be visible in both places. Agree on which platform owns each alert type before turning on automated actions. Confirm the Wazuh alert format and the Shuffle trigger options available in your deployed version.

Enriching indicators with your threat intelligence platform

Enrichment workflows query a threat intelligence platform for reputation and context on hashes, IPs, domains and URLs before an analyst sees the alert. The team chooses the platform, so the enrichment app and its API keys belong to the threat intelligence owner, while Shuffle runs the lookups. Enrichment results can be written back to a case in SecOps or to a Shuffle case, which is where duplicate tags and verdicts can appear. Confirm which platform has a Shuffle app and how each verdict is written back.

Notifying ticketing and chat tools

Notifications to ticketing systems and chat channels are the most common step to build first, and the most likely to duplicate work. If SecOps already opens a ticket or posts to a channel for the same alert, a Shuffle workflow can create a second one. The integration owner is usually the SOC lead, who defines the message format and the channels. Before parallel running, list every notification SecOps sends and mark which ones Shuffle will suppress. Confirm current Shuffle app availability for your ticketing and chat tools.

Keeping a parallel run for comparison

A parallel run keeps SecOps as the authoritative response path while Shuffle workflows execute the same steps in a dry-run or notify-only mode. Analysts compare the outcomes, such as enrichment results, ticket counts and time to triage, before any action is handed over. The owner is the SOC manager with the SOC engineering lead, and the main risk is that a workflow with live actions runs against the same host or account as SecOps. Set a written exit criterion for each playbook and disable write actions until it is met.

How to move SOAR playbooks from Google SecOps to Shuffle

This sequence turns the playbooks bundled with Google SecOps into Shuffle workflows that your team has tested against sample alerts and can switch over one group at a time. The effort depends on how many playbooks and custom integrations you run today, so the first step is an inventory.

Inventory playbooks, triggers and case history
Your SOAR lead or SOC engineer lists every SecOps playbook, the alert types or manual actions that start it, and the integrations each one calls. Record the logic of each playbook step by step, including conditions, approvals and error handling, because the platform export may not carry all of it. Export case history and the playbook definitions you can reach while the subscription is still active, and confirm with Google which exports your contract and edition allow. The step is done when every playbook has a written entry and the exports are stored on your own systems.
Sort playbooks by integration dependency
Group the inventory by the integrations each playbook depends on, such as your SIEM, endpoint tools, ticketing, identity and threat intelligence feeds. Mark which integrations have an existing Shuffle app, which need an app built from an OpenAPI specification, and which need a custom Python app written with the Shuffle app SDK. Playbooks that use only common, already-supported integrations are the first candidates for rebuilding. The output is a ranked list with a clear reason for each rank and an owner for each integration gap.
Rebuild priority workflows in Shuffle
Platform engineers and SOC engineers rebuild the highest-value playbooks as Shuffle workflows, starting with alert triage and enrichment flows that run often. For integrations without an existing app, create one from an OpenAPI specification in the App Creator or write a Python app, and run it as a versioned Docker container. Confirm the Shuffle architecture you deploy, since a single Docker Compose server and a high availability layout differ in how workers are placed. The step is complete when each workflow has a reviewed definition and its apps are versioned in source control.
Store and test app credentials
Enter each integration credential or API key into Shuffle and confirm the encryption secret, SHUFFLE_ENCRYPTION_MODIFIER, is set before any credential is saved. Shuffle encrypts saved app authentications in OpenSearch with AES-256 using that secret, and the configuration documentation warns that losing or changing it breaks all saved authentications. Store the secret in your existing secrets manager with a documented recovery process and restrict who can read it. Test each app action against a non-production target and record the result. The check passes when every authentication works from a clean test run and the secret recovery steps are written down.
Run workflows in parallel on sample alerts
Feed sample or replayed alerts into both the SecOps playbooks and the matching Shuffle workflows, and compare the actions taken, the enrichment returned and the tickets or cases created. Shuffle runs actions through Orborus and worker containers, so check that the runtime can reach each integration endpoint and that jobs are not queued. Record every difference and decide whether it is a rebuild defect or an intended change. The step is done when each workflow produces the same outcome on the agreed sample set, and the differences are logged with an owner.
Cut over one playbook group at a time
Switch alert routing for one integration group at a time, starting with the group that passed parallel testing and carries the lowest operational risk. Keep the SecOps playbook for that group available as a fallback until the SOC lead signs off on the first week of live alerts. Confirm that Shuffle's high availability settings, such as more than one Orborus node and a scaled backend, are in place for production groups before cutting them over. The step is complete when each group has a signed cutover record and a documented rollback path.
Retire SecOps playbooks and archive records
After every group has run in production on Shuffle, disable the SecOps playbooks and archive the exported definitions, case history and test evidence in your own storage. Update runbooks so analysts know which platform owns each action and who maintains each app. Review your Shuffle license tier against the app run volume you now generate, since the paid metric counts executed actions. The output is a retirement record, an updated runbook set and a maintenance owner for each workflow and app.

Where the cost of a self-hosted SOAR actually sits

The first cost change is the SecOps package fee. Google Security Operations is sold on ingestion, and the SOAR capabilities sit inside that package, so a self-hosted Shuffle deployment removes that share of the fee but adds costs that were previously invisible. Shuffle's own licensing is priced on a single metric, app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Ask the vendor to show, in writing, how app runs are counted for your planned playbooks, and to estimate the monthly run volume from your alert history. Because the metric follows executed actions, a noisy detection that fires many playbooks will move the license cost more than the number of analysts does.

Infrastructure is recurring and sits with you. Shuffle's server side needs the frontend, the Go backend and an OpenSearch document database, and the runtime side needs Orborus nodes that start a worker and app containers for each execution. The Shuffle configuration docs recommend an OpenSearch cluster, a shared cache, NFS for shared files when several backends run, and more than one Orborus node for high availability. Each of these is a machine, storage or staff hour you own. Also budget for the one-time setup of the SHUFFLE_ENCRYPTION_MODIFIER secret handling and backups, since losing or changing that value breaks every saved app authentication. Engineering time is the largest variable: building playbooks, testing them against Wazuh alerts and threat intelligence feeds, and reviewing them after changes is ongoing work that a bundled SecOps SOAR may have partly absorbed.

Maintenance and the support tier decide the long-term figure. Each app is a versioned Docker container, so someone must track app updates, rebuild or retest integrations when an upstream API changes, and rotate stored credentials. Shuffle states that all features exist in the open-source edition, while paid tiers differ in feature limits, scaling and support, and since v2.1.1 those limits are enforced. Decide early whether you need enterprise scaling or a support contract, because that decision is a recurring fee, and check which limits you would hit at your expected scale. In the quote, ask for the license tier and its limits, the app-run counting method, the infrastructure sizing you assume, the fixed-scope engineering hours for playbook build and test, and the retainer terms for upgrades and monitoring. No prices are estimated on this page; each figure must come from the written scope and the vendor's terms.

Questions teams ask before replacing SecOps SOAR

What does it cost to replace SecOps SOAR with self-hosted Shuffle?

The software license is not the main cost. Shuffle's open-source edition includes all features, so the recurring costs are the servers and storage that run Shuffle, the OpenSearch cluster behind it, the staff who maintain playbooks, and any paid Shuffle tier you choose for higher limits, scaling or support. The one-time costs are planning, playbook translation and testing. Ask any implementation partner for a quote that separates infrastructure, licensing if you select a paid tier, and labor for each playbook. Compare these lines with the SecOps package fees and any Unit overages on your current contract, since those depend on your ingestion and product bundle rather than on SOAR alone.

How long does a SecOps SOAR migration take?

The duration depends on how many playbooks you run, how many integrations they call, and how much of your response process is documented. A small set of enrichment and notification playbooks moves faster than a set of automated containment workflows that touch identity, endpoints and ticketing. Testing against sandboxed or non-production systems usually takes the most time, and running old and new automation in parallel for a period adds to it. Shuffle's architecture is simple to start with on a single Docker Compose server, but high availability adds work. Ask for a written schedule that lists playbooks in waves, with acceptance criteria for each wave.

What does the internal team need to provide for the migration?

You need people who understand your response process, the systems each playbook touches, and the approval steps that protect production. Typically this means a SOC lead who can confirm the decision logic, an engineer who can manage the Docker or Kubernetes hosts and the OpenSearch backend, and owners for each integration with Wazuh, your ticketing system and threat intelligence sources. Someone must also hold the credentials for every connected system and approve changes to them. Before work starts, list these owners and their time commitments in the scope so the plan does not stall on access or approvals.

Can our own team replace SecOps SOAR without outside help?

Yes, many teams do, provided they have the engineering skills to run containers, a search cluster and identity integration, and they have time to rebuild and test playbooks. Shuffle publishes its architecture and configuration documentation, and its apps are built from OpenAPI specifications or the Python SDK, which keeps the work visible to engineers. Outside help is most useful for hardening, high availability design, playbook translation under time pressure, and documented evidence for an assessment. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your environment under a written scope, and it does not issue audit reports or certifications.

How does Shuffle licensing count app runs?

Shuffle prices its paid licensing on one metric, app runs, which means actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. The open-source edition includes all features, but since version 2.1.1 the limits between the open-source and enterprise editions are actively enforced. Before you size a deployment, confirm with Shuffle which limits apply to the edition you select, how run counts are reported in your instance, and how they change when you add playbooks that run on every alert. Model your expected alert volume against those counts instead of assuming unlimited execution.

Does Shuffle SSO work with our identity provider?

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 per-tenant SSO enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. For a self-hosted deployment, OpenID Connect is the safer choice for new work because it is the direction of the platform. Confirm three things with your identity team: that your provider supports the protocol you choose, which claims Shuffle needs for role mapping, and how group membership maps to Shuffle roles. Test sign-in and role assignment in a non-production tenant before enforcing SSO for every user.

Must we back up the Shuffle encryption secret?

Yes. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, using the SHUFFLE_ENCRYPTION_MODIFIER secret. The documentation warns that losing or changing this value breaks all saved app authentications, so every integration must be reconfigured by hand. Store the secret in a managed secrets vault with restricted access and a recorded owner, and include it in your backup and restore runbook alongside the OpenSearch data. Test a restore in a separate environment to confirm that saved credentials still decrypt. Treat any change to this value as a planned change with a rollback path.

What happens to our playbooks if Google deletes SecOps data at subscription end?

Playbook logic and the data it acts on are separate things, and you should export both before the contract ends. Playbook definitions in SecOps SOAR are not the same as Shuffle workflows, so you must rebuild or translate them; the export gives you the decision logic, conditions, and the integrations and fields each one uses. Alert history, case records and the log data that triggered playbooks need separate export, and BigQuery export is an Enterprise Plus feature. Ask Google which of your SOAR artifacts it will return and in what format, and keep a written inventory of playbooks and their owners so you can rebuild them in Shuffle and verify the results.

How DeployOpen scopes and delivers a SOAR replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a SOAR replacement, that means starting from your current SecOps playbooks and case flow, then building Shuffle workflows and integrations in your environment under a written, fixed scope.

How we scope

We inventory the SecOps playbooks, response actions and connected tools that the new Shuffle workflows must replace.
The written scope names which Wazuh alert sources, threat intelligence feeds and ticketing systems each workflow connects to.
Scope sets out deliverables, timelines and out-of-scope items before any build work starts, since most engagements are fixed-scope.
We confirm with you which Shuffle edition, deployment architecture and identity provider the scope assumes.

How we build

We deploy Shuffle in the architecture you choose, such as Docker Compose, Docker Swarm, a hybrid setup or Kubernetes with Helm.
We rebuild priority playbooks as Shuffle workflows, wire in apps and credentials, and store the encryption secret in your secrets process.
We test each workflow against sample alerts from Wazuh in a non-production environment before connecting it to live alert streams.
We set up single sign-on and high availability settings the scope requires, including OpenSearch cluster and extra Orborus nodes.

How we hand over

You receive documentation covering workflow logic, app versions, credential handling, backup steps and the upgrade procedure.
We walk your analysts and engineers through running, editing and troubleshooting workflows and handling failed executions.
Each playbook is mapped to its original SecOps behavior, so reviewers can confirm which response steps carried over and which did not.
We deliver the evidence and configuration records that your internal or external assessors may ask to see for these controls.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, so the scope can continue past go-live.
Retainers can cover Shuffle and Wazuh version upgrades, which you should plan around the published release cadence and your change windows.
Security testing of the automation layer, including the APIs and app integrations, can be scoped alongside the platform work.
Ask each proposal to state how support hours, response paths and upgrade testing are defined, since these change the total cost.

Open-source alternative to Google SecOps SOAR