When Google SecOps SOAR or a self-hosted Shuffle fits your SOC
If your SOC already runs Google Security Operations and you are facing a renewal, an ingestion-based pricing change, a data residency rule or a requirement to remove remote agents, the right option depends on what you need to keep. Google SecOps SOAR fits best when the SIEM, the case wall and the cloud-delivered integrations are working for your team and the main problem is cost or contract terms rather than architecture. A self-hosted Shuffle fits when playbooks must execute inside your own network, when you want the automation layer to be a separate decision from the SIEM, or when you can accept that your team will install, patch and operate the platform itself.
The decision turns on four questions. First, does the SIEM stay with Google? If it does, you will still pay for it, and moving SOAR alone changes how alerts reach Shuffle, not what they cost. Second, must playbooks reach internal systems without a cloud-side proxy? Shuffle's hybrid model, where a local Orborus needs no inbound firewall ports, is one way to keep execution local, so confirm with your network team whether outbound connections from your environment satisfy your policy. Third, how many people will build and maintain workflows? Shuffle workflows are visual, but credentials, app versions and workflow logic will need an owner, so name that person or team before you commit. Fourth, can your platform team operate OpenSearch, the backend and the worker containers at the availability you require? If not, budget for a managed partner or keep the cloud option.
Which option is the better fit for each scenario
This table compares Google SecOps SOAR with self-hosted Shuffle across the situations that usually drive the decision. Read each row's condition first, because the advantage on either side only matters when that condition holds in your environment.
| Scenario | Better fit | Why |
|---|---|---|
| Keeping the SIEM and SOAR both on Google | Google SecOps SOAR | Bundled SIEM and SOAR share ingestion, case data and alert sources, so the cost of moving nothing is lowest when you intend to stay on the Google platform. |
| Moving only SOAR | Shuffle | Shuffle can take over playbook execution while your SIEM stays where it is, provided alert ingestion can be repointed to Shuffle and you accept losing the bundled case wall. |
| Automation must run where remote agents cannot reach | Shuffle | Self-hosted Shuffle can run entirely inside your network, so the remote agent model is unnecessary if your security rules forbid outbound task pulls to a cloud service. |
| Small team with few automation engineers | Google SecOps SOAR | A managed cloud service removes the patching and scaling work of running Shuffle, so this suits teams without spare platform capacity to own the server stack. |
| Team that needs Google case and cloud features | Google SecOps SOAR | Case management, analyst views and native links to Google data are part of the managed product, and replicating them in Shuffle takes custom build work. |
| Team that wants to avoid per-ingestion pricing | Shuffle | Shuffle's licensing is based on app runs rather than data volume, so cost depends on automation activity, provided you confirm the current metric and limits before you commit. |
Capability differences between Google SecOps SOAR and Shuffle
This table compares the SOAR side of Google Security Operations with self-hosted Shuffle across playbooks, integrations, execution, cases, sign-on, credential handling and licensing. Where a Google capability is not covered by our researched facts, confirm it with Google before you rely on it in a migration plan.
| Capability | Google SecOps SOAR | Self-hosted Shuffle |
|---|---|---|
| Playbooks and blocks | Playbooks built from blocks in the Google SecOps case interface; confirm current block types and limits with Google | Workflows built in the Shuffle visual editor, with each action running an app; no playbook or block import path is assumed, so plan a rebuild |
| Integrations | Google-supported integrations and connectors; confirm the current catalog and custom integration options with Google | Premade apps for security tools, apps built from OpenAPI specifications in the App Creator, and apps written in Python with the Shuffle app SDK |
| Execution model | Google runs the service and reaches internal systems through remote agents that pull tasks over the Publisher proxy | Orborus polls the backend for jobs, starts a worker per workflow execution, and the worker starts app containers on infrastructure you operate |
| Case management | Case handling is part of the Google SecOps SOAR product; confirm how case history exports and what it retains during a move | Shuffle provides workflow execution history in its own OpenSearch store; confirm whether it covers your case model and retention needs |
| Single sign-on | Confirm the identity options for your Google Security Operations tenant with Google | SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, available on-premises and in the cloud, with per-tenant enforcement |
| Credential encryption | Stored in the Google-managed service; confirm the encryption and key management details with Google | Saved app credentials and API keys encrypted with AES-256 in OpenSearch using the SHUFFLE_ENCRYPTION_MODIFIER secret; losing or changing it breaks saved authentications |
| Licensing | Commercial cloud subscription sold in ingestion-based packages with SIEM and SOAR bundled | Backend under AGPLv3; workflows, documentation, apps and app specifications under MIT |
What changes for data location, hosting and compliance
Moving SOAR from a Google-hosted service to Shuffle moves playbook execution, credentials and logs into your own boundary, and that shifts who operates, secures and evidences them. The cards below cover where data sits, how Shuffle can be hosted, how sign-in works, what backup duties follow from encryption, and where compliance responsibility stays with you and your auditor.
Where execution and credentials live
In Google SecOps SOAR, playbook execution and integration connections run in Google's cloud, with remote agents reaching internal systems. With self-hosted Shuffle, the backend, the OpenSearch document database and the Orborus runtime all run where you deploy them, so workflow executions and saved app credentials stay in your environment. Check which systems still call out to external APIs, and where your SIEM alerts are stored once they are no longer bundled with SOAR.
Hosting models and their operating duties
Shuffle supports a single server on Docker Compose, distributed Docker Swarm, Kubernetes with Helm charts, and a hybrid where Shuffle Cloud coordinates with a local Orborus that needs no inbound firewall ports. The hybrid model keeps execution in your network but depends on the cloud control plane. Choose the model that matches your data residency rules, and confirm whether your team will run the high availability setup of OpenSearch, shared storage and multiple Orborus nodes.
Identity and single sign-on options
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, both available on-premises and in the cloud, with per-tenant enforcement. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so new integrations should target OpenID Connect. Confirm that your identity provider, session lifetimes and role mapping meet your access control standard before analysts move off the Google console.
Backing up the encryption secret
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret. Losing or changing that secret breaks every saved app authentication, and the encrypted values cannot be recovered without it. Store the value in a separate secrets vault, record who may read it, and test a restore on a non-production instance before you retire Google SecOps connections.
Compliance responsibilities after the move
Hosting SOAR yourself moves logging, access control, patching, backup and change records into your assessment scope, where a cloud vendor's attestations previously covered part of them. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Your auditor decides whether the design meets your frameworks, so raise the scope question with them before cutover.
Which Shuffle deployment fits your environment
This model suits a pilot, a lab, or a small team that wants Shuffle running quickly on one host with the whole stack. The install guide states that the default Docker Compose setup is not a scalable build without changes, and it needs a minimum of 4 GB of RAM. Everything (frontend, backend, OpenSearch and Orborus) shares one machine, so a single failure stops automation.
- Single point of failure: one host runs every component, so a host outage halts all workflows.
- Scaling limits: the default file is not a scalable build, so growth requires changes you design and test.
- Data durability: you own backups of the OpenSearch volume and of the encryption secret.
- Upgrades: you pull the tag you choose, such as the latest stable Docker tag or nightly for experimental changes, and test before production.
- Operations: the team patches the host, the containers and the OpenSearch instance.
Confirm with the Shuffle docs whether a single-node build meets your recovery targets before using it for production response.
Docker Swarm spreads Shuffle across several servers, which suits teams already running Swarm and wanting more capacity without moving to Kubernetes. The configuration docs recommend an OpenSearch cluster, an optional Memcached instance for a shared cache, and NFS for shared files when several backends run. Backend and frontend are scaled across all servers, and more than one Orborus node keeps workflows running if one fails.
- OpenSearch cluster: plan for multiple data nodes instead of a single database instance.
- Memcached (optional): adds a shared cache across backend instances.
- NFS for shared files: required when several backends need the same files, so the NFS service becomes a dependency to protect.
- Multiple Orborus nodes: a failed node should not stop executions, provided others are healthy.
- Secrets handling: every node must receive the same SHUFFLE_ENCRYPTION_MODIFIER value, since changing it breaks saved app authentications.
Confirm the Swarm topology, NFS design and OpenSearch sizing against the configuration docs before you commit to a layout.
Kubernetes with the Helm charts suits platform engineering teams that already run clusters, have standard ingress, storage and monitoring, and want Shuffle managed like other workloads. The same high availability pattern applies: an OpenSearch cluster, optional Memcached, shared file storage for multiple backends, and more than one Orborus. The cluster scheduler handles restarts and placement, but the security team still owns the application configuration.
- Helm deployment: the Shuffle charts provide the starting point, and you own the values files and their version history.
- Persistent storage: OpenSearch and shared files need storage classes that meet your durability requirements.
- Network policy: restrict which pods can reach the backend and the systems Orborus workers call.
- Cluster operations: the platform team owns cluster upgrades, node patching and capacity planning.
- Secrets: store the encryption modifier and app credentials in your cluster secret management, not in plain values files.
Confirm which chart version matches the Shuffle release you plan to run, and test upgrades in a non-production cluster first.
The hybrid model keeps the Shuffle control plane in Shuffle Cloud while a local Orborus runs workflows inside your network. Because the local runtime polls outward, it needs no inbound firewall ports, which can ease approval for internal systems. This option sits outside the fully self-hosted model, so review it against your data residency and sovereignty requirements before choosing it.
- Data location: confirm which workflow data, case records and credentials are stored in the cloud service and which stay local.
- Local Orborus nodes: run more than one so executions continue if a node fails.
- Network path: the local runtime needs outbound access to the cloud backend, which your egress policy must allow.
- Service terms: the shuffler.io service is an alternative to self-hosting, so review its terms and support model.
- Operations: your team still operates the Orborus hosts, their container runtime and the internal app connections.
Confirm in writing where data is processed and stored before you adopt a hybrid design for regulated workloads.
What changes when SOAR is no longer bundled with the SIEM
Moving only the SOAR side means alert ingestion, detection content and SIEM retention stay with Google. Shuffle will not receive alerts on its own, so the first decision is the delivery path: a webhook or API call from the SIEM side into a Shuffle workflow trigger, a scheduled pull from Shuffle against the Google APIs, or a forwarder that sends normalized alerts to Shuffle from your own collection layer. Each option moves a different set of credentials and data flows, and each has different failure modes when a token expires or a queue backs up. Before you commit, confirm with Google which export, alert and API routes your current contract and product edition include, because the bundled SOAR may have relied on internal connections that do not exist once the SOAR is removed from the picture. Ask for the answer in writing, along with any rate limits and data retention terms that apply to alerts you export.
Case history is the item most teams underestimate. Cases, comments, assignments and timelines created in Google SecOps stay in Google unless you export them, and the export options differ from playbook exports, so the migration plan needs a separate line for case records. Decide what must remain searchable for audits or incident reviews, and whether that means an archive in your own storage or a link back into Google. Shuffle's own execution history will hold workflow runs from the point you start using it, which is not the same record. Confirm with your incident response and compliance leads how long each record must be kept and who can read it after cutover.
Dashboards and reports that relied on the bundled SOAR view also need an owner. Any metric that counted playbook runs, case closure times or analyst actions inside Google will stop updating for Shuffle activity, and any dashboard built on the SIEM will still show alert volume that no longer has a response record next to it. In your environment, list every dashboard, scheduled report and ticket queue that reads from the SOAR side, then decide whether it moves to a self-hosted reporting stack, is rebuilt from Shuffle's execution data, or is retired. Confirm which of these views you need to keep for the same stakeholders, because a gap here usually appears in management reporting first.
What you pay for on each side
Google SecOps charges for SOAR as part of an ingestion-based package, while self-hosted Shuffle moves cost into licensing tiers, infrastructure, migration and people. Each card below names who is paid, whether the cost is one-time or recurring, and what to request before comparing totals.
Google ingestion-based package
Google Security Operations sells SIEM and SOAR as one ingestion-based package, so SOAR has no separate line item today. If you keep the SIEM and move only SOAR, the question is how Google prices SOAR on its own, and whether the SIEM price falls. This is a recurring cost tied to ingested data volume. Ask Google to split the quote into SIEM, SOAR and any remote agent or Publisher components, and to state the term and renewal rules in writing.
Shuffle open-source edition and paid tiers
Shuffle states that all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between the two editions are enforced, so a workflow that runs on the open-source edition may still hit a cap as volume grows. Treat the paid tier as a recurring cost to test against your expected load. Ask the vendor which limits apply to your deployment before you commit to a design.
App-run pricing metric
Shuffle prices licensing on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Your recurring cost therefore depends on how many automated actions run each month, so a noisy alert source or a fan-out playbook raises the bill. Model a typical week of executions from your current SOAR logs and ask the vendor to confirm how retries and loops are counted.
Servers, storage and OpenSearch operation
Shuffle needs compute for the frontend, the Go backend, Orborus and the app containers, plus an OpenSearch document database. The install guide sets a minimum of 4 GB of RAM and warns that the default Docker Compose setup is not scalable without changes. High availability adds an OpenSearch cluster, shared cache, NFS and extra Orborus nodes. These are recurring infrastructure costs, and staff time to patch and back up OpenSearch is recurring too. Ask your team to size the cluster against peak execution volume.
Migration and workflow rebuild
Moving playbooks and blocks to Shuffle is a one-time project. Each playbook must be rebuilt as a Shuffle workflow, each integration replaced with a Shuffle app or an app built from an OpenAPI specification in the App Creator, and each alert source repointed. Cost rises with the number of playbooks, custom Python integrations and remote agents to retire. Ask any implementation partner for a fixed-scope quote that lists the playbook inventory, the apps to build, and the cutover steps.
People who maintain workflows
Someone must own the Shuffle platform, update the apps and keep credentials valid, which is an ongoing staff cost. Shuffle credentials are encrypted with a secret named SHUFFLE_ENCRYPTION_MODIFIER, and losing or changing it breaks every saved app authentication, so key custody needs a named owner. Budget recurring time for upgrades and for workflow changes as your tools change. Ask whether your team or a retainer will cover on-call response, and what each option costs in staff hours.
How a move from Google SecOps SOAR to Shuffle proceeds
The sequence inventories what Google SecOps SOAR holds, rebuilds it in a self-hosted Shuffle environment, and ends with alert ingestion moved and remote agents retired. Each phase closes with a check the team can verify before the next phase begins.
Inventory playbooks, blocks and connectors
The SOAR administrator lists every playbook, block, connector and scheduled job in Google SecOps, along with its owner, the alert types that trigger it and the external systems it calls. Mark which items are live, which are stale and which only the SIEM depends on. The output is a spreadsheet that maps each live playbook to the tools it touches, so nothing is discovered for the first time during cutover. Ask Google which objects your tenant can list in full, because the export routes determine what you can verify.
Export playbooks through Google's routes
Use the ZIP export or GitSync to pull playbook definitions, blocks, connectors and jobs out of Google SecOps, following the export guidance for your tenant. Confirm what each route includes by opening a sample export and comparing it against the inventory. Expect that case history, analyst notes and alert data may not travel with the definitions, so record those separately if you need them. Confirm with Google whether the exported files can be used outside its platform, then store them in version control that you control.
Stand up a Shuffle test environment
The platform team installs Shuffle on the chosen architecture, using Docker or Kubernetes and following the install guide. Plan for at least 4 GB of RAM, the guide's stated minimum, and do not treat the default Docker Compose setup as a production build without changes. Set SHUFFLE_ENCRYPTION_MODIFIER and store it in your secrets manager before configuring any app, because losing or changing it breaks every saved app authentication. The step is done when the test instance runs, an Orborus node picks up a test workflow, and a verified backup of the secret exists.
Rebuild playbooks as Shuffle workflows
Automation engineers rebuild each live playbook as a Shuffle workflow, starting with the highest-volume alert types from the inventory. Treat each export as a reference for the rebuild and test every workflow before anyone relies on it. Keep a mapping table that shows which source step corresponds to which Shuffle action, so reviewers can check the logic line by line. The step is done when each rebuilt workflow produces the same case outcome as the original on replayed test alerts, and the SOC lead signs off on the results.
Replace integrations with Shuffle apps
For each connector in the inventory, the integration owner selects a premade Shuffle app for that security tool if one exists. If none fits, the owner builds an app in the App Creator from the vendor's OpenAPI specification, or writes one in Python with the Shuffle app SDK. Each app runs as a versioned Docker container, so pin versions and record which one each workflow uses. Credentials are recreated or migrated through a secure channel, never pasted into tickets. The step is done when every connector has an app, a tested credential and a named owner.
Repoint alert ingestion from the SIEM
The detection engineer changes where alerts are sent so they reach Shuffle workflows instead of Google SecOps. Map each alert source, including any SIEM rules that currently forward alerts into SOAR, and confirm field mappings in the test environment. Keep the SIEM in place unless the organization has decided to replace it, because only the SOAR component moves in this sequence. The step is done when a test alert from each source arrives in Shuffle with the expected fields and starts the matching workflow.
Run both platforms in parallel
Both platforms receive the same alerts for an agreed period, and the SOC compares case outcomes, actions taken and failed runs. Record execution failures and missing data from each side, and fix the gaps in Shuffle before cutover. During this period, review Orborus and OpenSearch health, and confirm that more than one Orborus node is in place so workflows keep running if one node fails. The step is done when the comparison shows no unexplained differences in outcomes and the SOC lead signs off.
Cut over and retire remote agents
Move the SOC's case queue and automation to Shuffle and disable the matching Google SecOps playbooks. Keep read-only access to the old platform for historical lookups. Then decommission the remote agents that pulled tasks into your network, and remove their network paths and stored credentials. Confirm with the vendor how your subscription scope changes. The step is done when no live alert depends on Google SecOps for response and the remote agent inventory is empty.
Questions buyers ask before choosing Shuffle or hiring help
What drives the cost and effort of moving off Google SecOps SOAR to Shuffle?
The cost is driven by how many playbooks, blocks and custom integrations you have, how many alert sources must be repointed, and how many people are needed to rebuild and test workflows. Shuffle's open-source edition is the software line item, so the larger costs are usually servers, staff time, migration work and ongoing maintenance of workflows and apps. Ask any provider to split a quote into one-time work (inventory, rebuild, testing, cutover) and recurring work (upgrades, backups, support retainers). Ask what is excluded, especially SIEM costs if only SOAR moves, since Google SecOps packages bundle the two.
How long does a Shuffle migration take?
No duration can be stated without a written scope, because the timeline depends on the size of your automation estate and the complexity of each workflow. The main factors are the number of playbooks and blocks to rebuild as Shuffle workflows, how many integrations need a replacement app, whether custom Python logic must be rewritten, and how many alert sources must be repointed from the SIEM. Ask for a fixed-scope plan with milestones before work starts, and ask which parts run in parallel with your current SOC operations.
What does the migration need from our own team?
Your team needs to supply access and knowledge: owners for each playbook, the business logic behind decisions, credentials for each integration, and people who can approve changes to alert routing. Security engineers should also plan the deployment target, network boundaries and how the SHUFFLE_ENCRYPTION_MODIFIER secret will be stored, because losing or changing it breaks every saved app authentication. Expect your analysts to test rebuilt workflows against real case examples before cutover.
Can our team migrate to Shuffle without outside help?
Yes, if you have engineers who can run Docker or Kubernetes, write and test workflows, and maintain OpenAPI-based apps. Shuffle's install guide describes Docker and Kubernetes installation, and its App Creator builds integrations from OpenAPI specifications. The default Docker Compose setup is not scalable without changes, and high availability needs an OpenSearch cluster and more than one Orborus node, so plan that work honestly. Outside help is most useful for the cutover window, hardening, backup design and the first workflow rebuilds, which is where errors are costly.
Do we need Shuffle's paid tiers for the features a SOC uses?
Shuffle states that all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced, so the question is whether your volume stays within open-source limits. Shuffle's pricing article says licensing is measured by app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Confirm the current limits in the configuration docs and ask Shuffle directly how your expected run volume maps to each edition.
What happens to case history and alert sources during the move?
Playbook logic can be exported and rebuilt, but case history stored in Google SecOps generally does not transfer as automation definitions, so plan to keep the old system readable for the retention period your policy requires. Alert sources must be repointed from the SIEM to Shuffle's triggers, which means testing each source for field mapping, duplicates and missed alerts. Ask for a cutover plan that runs both paths side by side for a defined period, and for an inventory listing every source and its owner.
Is Shuffle Cloud an option if our policy refuses self-hosting?
Shuffle does offer a hosted cloud service at shuffler.io as an alternative to self-hosting. Shuffle's architecture also documents a hybrid model in which Shuffle Cloud runs with a local Orborus that needs no inbound firewall ports, so workflows can execute inside your network. Confirm with Shuffle where data is stored, how credentials are held, and which SSO options apply, since SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Your data residency and compliance requirements should decide between the options, and an independent assessor should review the final design.
How DeployOpen helps evaluate, implement and migrate
DeployOpen plans, implements, hardens and supports self-hosted Shuffle inside your own cloud accounts, data centers or air-gapped networks. We start with the written scope, so the decision about which Google SecOps SOAR playbooks, integrations and remote agent paths move to Shuffle is made on your evidence.
How we scope
- Inventory your Google SecOps SOAR playbooks, blocks, connectors and the alert sources that feed them today
- Agree which workflows move to Shuffle, which stay in Google SecOps, and which need a new integration
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts
How we build
- Choose a deployment model with you: Docker Compose, Docker Swarm, Kubernetes with Helm, or a hybrid with a local Orborus
- Rebuild priority playbooks as Shuffle workflows and create app integrations from OpenAPI specifications where needed
- Test each workflow against sample alerts and document the results before it runs on live incidents
How we hand over
- Deliver architecture notes, runbooks, workflow inventories and a record of every integration and credential handling step
- Document the SHUFFLE_ENCRYPTION_MODIFIER secret handling and backup procedure, so saved app authentications survive maintenance
- Walk your operations and security teams through running, changing and troubleshooting workflows on their own servers
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Plan Shuffle version upgrades and high availability changes against the written scope and your change process
- Confirm with the vendor and your own environment which editions, app run limits and features apply before you decide
