Does self-hosting Google SecOps SOAR cost less than the cloud package?
Self-hosting Shuffle probably removes the SOAR part of your Google SecOps bill, but it does not remove cost. It replaces a bundled subscription with servers, migration work and staff who maintain workflows, and the SIEM stays on the bill unless its log ingestion moves too. Before a renewal or packaging change, separate what Google charges for ingestion from what you pay for SOAR alone, because Google bundles the two. Ask your account team for a quote that shows each component on its own line so you can see which costs disappear if only SOAR moves.
Shuffle's open-source edition includes all features, and its licensing is priced on app runs, meaning actions that actually execute in a workflow. Users, apps and workflows are unlimited, and triggers and skipped actions are not counted. Your SOAR cost therefore depends on how many workflow executions your playbooks perform, not on headcount. Run a count from your current playbook logs for a representative month and multiply it by the paid tier pricing you receive from Shuffle, if you need the paid limits for scaling or support. The single biggest variable is the number of automated actions per alert, which often matters more than alert volume itself.
Infrastructure is the cost most teams underestimate. Shuffle's install guide sets a minimum of 4 GB of RAM for its Docker setup, but it also says the default Docker Compose configuration is not scalable without changes. Production use with high availability, as described in Shuffle's configuration docs, means an OpenSearch cluster, more than one Orborus node and shared storage. Budget for those hosts, their backups and monitoring, and the encryption key used for saved app credentials, which must be protected because losing it breaks every saved authentication. The largest recurring cost is usually the engineer time needed to upgrade, patch and troubleshoot the platform, so count the internal hours you actually have before you commit.
Which cost components move when SOAR leaves Google SecOps
This table compares each cost component of Google Security Operations SOAR, sold on ingestion with the SIEM bundled, against the components of running self-hosted Shuffle. Read the recurring rows first, since they decide the long-term difference, and use the one-time rows to size the migration. Google SecOps package prices are not stated here, so request them in writing and compare them line by line with the Shuffle rows.
| Cost component | Google SecOps SOAR (bundled) | Self-hosted Shuffle | One-time or recurring |
|---|---|---|---|
| Software licensing | Included in an ingestion-based package that also covers the SIEM, so SOAR cost is not priced separately | Open-source edition carries no license fee. Paid tiers are priced on app runs, the actions that execute in a workflow, while users, apps and workflows are unlimited | Recurring for paid tiers only |
| Ingestion and log volume | Charged on ingested data, which grows with every alert source connected | Not charged by ingestion. Volume only affects OpenSearch storage and compute you provision | Recurring |
| Servers and compute | Not provided by you; hosted by Google | Hosts for the backend, frontend, Orborus and workers, sized to your workflow load and minimum 4 GB RAM per install guide | Recurring (infrastructure) and one-time (initial build) |
| OpenSearch storage | Not applicable to you | OpenSearch is the database. Storage grows with execution history and must be sized and backed up | Recurring |
| High availability | Delivered by the provider | Requires an OpenSearch cluster, shared files, several backends and more than one Orborus node, so extra servers and engineering time | One-time design, recurring infrastructure |
| Implementation and integrations | Vendor-side integrations; rebuilding playbooks is internal effort | Building workflows, creating app integrations from OpenAPI specifications and configuring credentials, usually through a fixed-scope engagement | One-time |
| Support and upgrades | Included in the service contract; confirm scope in writing | Upgrades, patching and vendor support depend on your chosen tier or a retainer. Confirm what is covered | Recurring |
| Internal skills and workflow upkeep | Analysts maintain playbooks inside the platform | Engineers maintain workflows, app containers and credential encryption keys, so staffing must be planned | Recurring |
| SIEM if only SOAR moves | Not separable: SIEM and SOAR share one package | SIEM stays on Google SecOps or moves elsewhere, so the SIEM line remains and must be priced separately | Recurring |
What you still pay for the SIEM if only SOAR moves
Moving only automation to Shuffle leaves the SIEM cost in place. Google Security Operations is sold in ingestion-based packages that bundle the SIEM and the SOAR, so the invoice you receive does not separate them by default. If your logs keep flowing into Google SecOps for detection, search and retention, the ingestion-driven charge continues after the playbooks have moved. Before you model a saving, ask your Google account team for an itemized breakdown of the current package, showing which line covers log ingestion and retention and which covers SOAR capabilities such as playbooks, cases and remote agents. Then ask how the ingestion charge is calculated and whether it changes if the SOAR component is removed from the contract.
Repointing alert ingestion is the step that decides what you can cut. Shuffle does not read your SIEM alerts by default, so each detection source must be connected to Shuffle through a webhook or an app integration, and the existing SIEM-to-SOAR feed must be switched off or redirected. Confirm which log sources and detections still feed Google SecOps after the move, because any source you keep there continues to be billed under the SIEM side. List each alert type, its current destination and its volume, and decide per source whether it stays in Google SecOps, goes to a different SIEM, or moves to a self-hosted log platform that you run yourself.
A quote should price the SIEM and the SOAR as separate lines. Ask any vendor or implementation partner, including DeployOpen, to show SOAR platform costs, which for Shuffle include the servers, the OpenSearch database and the people who maintain workflows, apart from any SIEM or log management costs that remain on your side. If you intend to keep Google SecOps for detection, the quote should state that the SIEM invoice continues and should not net it against the automation savings. Keep a written record of the split, because it determines whether the project reduces your total spend or only changes its shape.
What moves the Shuffle total cost of ownership up or down
Self-hosted Shuffle has no per-user fee, so its total cost follows how much work the platform does, how many servers it runs on and who keeps it running. The cards below cover the drivers that move that total up or down, and the checks to make before comparing it with a Google Security Operations quote.
Workflow app runs
Shuffle's paid tiers meter a single unit: app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. A high-volume alert pipeline that calls enrichment actions on every alert will consume runs far faster than a workflow that only fires on confirmed incidents. Ask the vendor how a typical alert maps to runs in your environment, and model that count before comparing with Google SecOps, which bundles SOAR with the SIEM.
Alert volume and workflow count
Alert volume drives both compute and run counts, while the number of workflows drives maintenance. Each workflow that touches a live queue needs testing, versioning and owner review when the source system changes its schema. Map your current Google SecOps playbooks to a count of Shuffle workflows, then group them by alert source. Confirm which sources send bursts of alerts, since those set the peak load your servers and Orborus nodes must absorb.
High availability design
Shuffle's configuration guidance for high availability calls for an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when several backends run, and more than one Orborus node so workflows keep running if one fails. Each of these is an extra server or storage service to size, patch and back up. A single-host Docker Compose install is cheaper to run but is not a scalable build without changes, so the HA requirement often decides the architecture budget.
Deployment architecture and server count
Shuffle documents four architectures: a single server with Docker Compose, distributed Docker Swarm, a hybrid with Shuffle Cloud and a local Orborus that needs no inbound firewall ports, and Kubernetes with Helm charts. The hybrid option keeps the control plane in the cloud while execution stays on your network, which can lower server cost but changes what data leaves your boundary. Price each option by the servers, storage, load balancing and backup it needs, and confirm which one your data residency rules allow.
Custom apps and integrations
Google SecOps offers a catalog of prebuilt integrations, while Shuffle ships premade apps for security tools and lets you build more with the App Creator from OpenAPI specifications or the Python app SDK. Each custom app is code your team owns: it needs versioning, a container build, credential handling and updates when the vendor API changes. Count the integrations you use that are not in the premade catalog, because those are the ones that add build and maintenance hours to the total.
Skills already on staff
Internal staff time is often the largest cost in a self-hosted SOAR move, and it recurs. Someone must run OpenSearch, manage the encryption secret, patch containers and rebuild workflows after each change. Teams already running Kubernetes, OpenSearch or Python automation carry less of this load than teams starting from zero. Ask whether your staff can own the platform after go-live, or whether the work should go to a fixed-scope implementation partner with a retainer for upgrades and support.
How to build the comparison with your own numbers
This sequence turns your current Google SecOps bill and automation inventory into a three-year comparison that separates the SIEM from the SOAR, sizes a self-hosted Shuffle deployment, and prices the migration and upkeep your team would carry.
Split the current Google SecOps invoice
Ask your Google Cloud account team or finance contact for the invoices or order documents for the last twelve months, and separate the charges that buy SIEM capability (ingestion, retention, detection content) from those that buy SOAR capability (automation, case handling, remote agents). Where the contract bundles both, record the contract line items and the metric each one is billed on, and ask Google in writing how it allocates the bundle between the two. Done when you have one table with a SIEM column, a SOAR column and a bundled column, each with a source document reference.
Inventory playbooks, blocks and connectors
Export the playbook and block definitions and list every connector in use, following the export steps in the Google SecOps documentation or GitSync if your team already uses it. For each playbook, record the trigger, the number of actions, the external systems it calls, and how often it runs. Mark anything that depends on a remote agent or a custom Python integration, because those need rebuilding rather than copying. Done when every playbook has a row and every connector maps to a named system you already run.
Estimate monthly app runs against the Shuffle metric
Shuffle prices its enterprise tiers on app runs, which count actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are unlimited. Using the run frequencies from your inventory, estimate executions per workflow per month, then multiply by the actions that run each time, with a separate line for peak alert volume. Confirm with Shuffle how the open-source edition and the paid tiers apply the limits in your version, since the limits are enforced in current releases. Done when you have a monthly run estimate with a low, expected and peak case, each labeled as an estimate.
Size the self-hosted servers and high availability
Start from the documented minimum of 4 GB of RAM for a Shuffle install and the Docker Compose default, which the install guide says is not scalable without changes. For production, the configuration documentation recommends an OpenSearch cluster, optional Memcached, NFS when several backends run, scaled backend and frontend, and more than one Orborus node. Your team or implementation partner should convert your run estimate and retention needs into node counts, CPU, memory and storage, then cost them against your cloud or data center rates. Done when you have a server bill of materials with the node count for each role and the high availability option you chose.
Price the rebuild and migration work per playbook
Assign each inventoried playbook a complexity class based on its action count, custom code and connector changes, then agree an effort figure per class with the implementation partner. Add a fixed line for the work outside playbooks, including repointing alert ingestion from the SIEM, reconnecting credentials, configuring single sign-on, and testing against a parallel run. Note that Shuffle encrypts saved credentials with the SHUFFLE_ENCRYPTION_MODIFIER secret, so the key must be handled as a migration item. Done when each playbook has a line item, the fixed work is listed, and the total is traceable to a written scope.
Add recurring maintenance and upgrade time
Self-hosting moves recurring work onto your team: patching the host, OpenSearch and Shuffle, testing each release before promotion (the docs recommend the latest Docker tag for stable use and nightly only for experiments), maintaining app containers, rotating secrets, and keeping workflows current as external APIs change. Estimate the hours per month for a platform owner and for workflow maintenance, and state who covers on-call for the automation itself. Ask any retainer provider what is covered for upgrades and testing. Done when recurring hours and their owners appear as a separate annual line.
Compare three-year totals with a retained SIEM
Build one three-year table with the current Google SecOps SOAR cost on one side and the Shuffle costs on the other: one-time migration and setup, recurring infrastructure, recurring maintenance, and any Shuffle paid tier. Keep the SIEM line in the Shuffle scenario, because moving only SOAR leaves your ingestion and detection charges in place. Run a low, expected and peak scenario, and label any illustrative sample figures as illustrative. Done when the table shows both scenarios with every assumption cited, and you have a list of quote questions for Google, Shuffle, and any implementation partner.
Which Shuffle deployment changes the cost profile
The single server model runs the frontend, the Go backend, the OpenSearch database and Orborus on one host with Docker Compose. It is the lowest-cost starting point and the easiest to reason about, but Shuffle's install guide states that the default Docker Compose setup is not a scalable build without changes and needs a minimum of 4 GB of RAM. Your cost is the host, its storage and backups, and the time of whoever installs and patches it.
- Infrastructure: one virtual machine or server sized above the 4 GB minimum, plus disk for OpenSearch and backups.
- Recurring labor: OS patching, Docker image upgrades and OpenSearch maintenance fall to one administrator.
- Availability risk: a single host means a failed node stops workflow execution, so budget for restore testing.
- Scaling cost: moving beyond this model requires redesign, which is a one-time project cost.
- Staffing: one platform engineer can usually run it, but nobody else is covering incidents.
Before you commit, ask your implementation partner to confirm what changes the vendor's configuration docs require for your expected workflow volume.
The distributed Docker Swarm model spreads backend, frontend and Orborus across several servers. Shuffle's configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files when running several backends, and more than one Orborus node so workflows keep running if one fails. This raises both hardware and labor cost because each shared component is another thing to operate.
- Infrastructure: multiple nodes, a shared NFS service and a multi-node OpenSearch cluster.
- Recurring labor: cluster health, NFS permissions and OpenSearch shard management become ongoing tasks.
- Resilience: more than one Orborus node is the documented way to keep workflows running through a node failure.
- Secrets handling: the SHUFFLE_ENCRYPTION_MODIFIER value must be identical across the deployment and backed up, since losing or changing it breaks saved app authentications.
- Staffing: plan for a platform engineer with Swarm and storage experience, plus an on-call rota.
Ask for a written list of every stateful component and the failover test you will run before go-live.
In the hybrid model, the control plane is hosted by Shuffle Cloud at shuffler.io while a local Orborus runs inside your network to execute actions against internal tools. Shuffle's architecture docs state that this needs no inbound firewall ports on your side. You still run the Orborus host and the network path to internal systems, but you no longer operate the backend, frontend or OpenSearch.
- Infrastructure: smaller footprint, mainly the Orborus host and its outbound connectivity.
- Recurring cost: hosted control plane fees are paid to Shuffle, so ask how app runs are metered on that tier.
- Data location: case data and workflow state sit with the vendor, which may conflict with residency rules.
- Labor: fewer database and upgrade tasks, but you still own connector credentials and Orborus updates.
- Staffing: a smaller team can cover operations, though security review of the hosted dependency takes time.
Confirm with Shuffle which data is stored in the cloud control plane and which stays in your network before you choose this model.
The Kubernetes model deploys Shuffle with Helm charts, which suits teams that already run a cluster with monitoring, backup and autoscaling. The per-node cost depends on your existing cluster, so the marginal cost is often lower than building new hosts, but the platform team takes on the operational load of each component. Shuffle's apps run as versioned Docker containers, which map naturally onto cluster scheduling.
- Infrastructure: capacity on an existing cluster, plus any managed or self-run OpenSearch.
- One-time cost: writing values files, ingress, secret management and backup policies for the chart.
- Recurring labor: chart upgrades, cluster version changes and OpenSearch lifecycle.
- Scaling: Kubernetes makes it easier to add Orborus capacity, but only if the cluster has headroom.
- Staffing: requires engineers fluent in Helm and cluster operations, which may already be on the platform team.
Ask your partner to estimate the one-time chart work and the upgrade calendar in writing, tied to your current cluster version.
The shuffler.io hosted service is the case where most infrastructure cost moves to the vendor. You do not provision servers, OpenSearch or the control plane, and your remaining costs are the workflow runs you pay for, the integrations you connect and the internal work to keep credentials and playbooks correct. Shuffle's pricing article says licensing is metered on app runs, meaning actions that actually execute, while triggers and skipped actions are not counted.
- Infrastructure: largely eliminated on your side, with the cost folded into the vendor subscription.
- Recurring cost: driven by app run volume, so high-volume alert enrichment is the main variable to model.
- Lock-in and data: playbooks stay exportable, but confirm export formats and what happens to stored credentials at exit.
- Labor: lower operations load, with engineering time still needed for workflow design and integration upkeep.
- Staffing: a security automation engineer can own the platform without a dedicated infrastructure team.
When comparing with the self-hosted options, ask the vendor for the app run definition and the current limits in writing.
Questions buyers ask before comparing SOAR costs
Can a small security team run Shuffle on its own?
Yes, a small team can run Shuffle alone if it has people who can operate Docker or Kubernetes, maintain OpenSearch and write workflows. The simplest architecture is a single server with Docker Compose, and the install guide lists a minimum of 4 GB of RAM. The default Compose setup is not scalable without changes, so plan for that work. Check the high availability requirements early. The configuration docs recommend an OpenSearch cluster and more than one Orborus node, which adds operational load. Confirm the staffing model with a written inventory of who patches, backs up and responds when a workflow stops.
How long does a SOAR migration take, and what drives it?
The duration depends on the scope of the work, and no published timeline is available for this comparison. The main drivers are the number of playbooks and blocks to rebuild, how many integrations need a Shuffle app or a custom app, how alert ingestion from your SIEM is repointed, and how much testing your change process requires. Single sign-on, data retention rules and any air-gapped constraints also add steps. Ask any implementation partner for a written schedule tied to a defined inventory, and make sure it lists the dependencies that could move the dates.
Is the open-source edition of Shuffle enough for our workflows?
Shuffle states that all features are available in the open-source edition, and its paid tiers differ in feature limits, scaling and support. Since version 2.1.1, the limits between the open-source and enterprise editions are actively enforced, so confirm the exact limits against your planned usage before you design around them. Licensing is measured by app runs, meaning actions that actually execute in a workflow, while users, apps and workflows are unlimited. Estimate your expected run volume from current alert handling, then review the Shuffle pricing article with your vendor before committing.
What skills does a self-hosted Shuffle deployment require?
The work needs infrastructure skills for Docker or Kubernetes, Linux administration and a working knowledge of OpenSearch for the database layer. Automation work needs people who understand your incident response and detection processes, since workflows encode those decisions. Custom integrations need OpenAPI literacy for the App Creator or Python with the Shuffle app SDK. Identity work covers SAML and OpenID Connect configuration. Many teams split these roles across security engineering and platform engineering. Document which person owns each area so that knowledge does not sit with one individual.
Is Shuffle Cloud cheaper than running Shuffle ourselves?
The available facts do not show which option costs less for your environment, so compare both with the same workload. Shuffle offers a hosted service at shuffler.io and a hybrid model, where Shuffle Cloud runs with a local Orborus that needs no inbound firewall ports. Self-hosting shifts cost toward servers, storage, staff time and upgrades. Cloud shifts cost toward subscription and run volume. Data residency requirements may decide the question before price does. Ask for both options in writing, with the same app run estimate, retention period and support level.
What does a Tracecat comparison add to the Shuffle decision?
Tracecat is an alternative to evaluate alongside Shuffle when you want case management, webhook-driven workflows and AI agents with tools in one self-hosted platform. Its core is licensed under AGPL-3.0, and it documents deployment with Docker Compose, AWS ECS Fargate, Kubernetes and an air-gapped Kubernetes option. Its architecture uses Temporal and PostgreSQL, which changes the skills and backup plan. Multi-tenant workspaces, Git version control and single sign-on are Enterprise features under a separate license. Tracecat 1.2.0 was released on October 16, 2026, so check current features against the Tracecat repository before you decide.
How are Shuffle upgrades handled after go-live?
Shuffle recommends the latest Docker tag for stable releases and the nightly tag only for experimental changes. Shuffle v2.3.0 was published on GitHub on September 28, 2026, which shows how quickly releases move. Treat upgrades as a change with its own test cycle: pin the version, apply it to a staging copy of your workflows and credentials, then promote it. Watch the encryption secret, because losing or changing SHUFFLE_ENCRYPTION_MODIFIER breaks saved app authentications. Ask whether any upgrade, testing or monitoring support is included in the quote, or whether it needs a separate retainer.
When should we ask for a fixed-scope quote?
Request a fixed-scope quote once you have an inventory of playbooks, integrations, alert sources, identity requirements and high availability targets. DeployOpen does not publish a price list. A quote follows from a written scope that sets out deliverables, timelines and responsibilities before any work starts. Ask the provider to state what is one-time, such as migration and hardening, and what recurs, such as support, upgrades and continuous testing. Compare each proposal against the same inventory so that differences reflect the work, not the assumptions.
What to ask for in a fixed-scope quote
DeployOpen works from a written scope, with deliverables and timelines agreed before any work starts, and it does not publish a price list. A quote follows from that scope, so the scope is where your cost control really sits. Ask for the inventory first: every Google SecOps SOAR playbook and block, every connector and custom integration, and the list of alert sources feeding them. Require a migration line per playbook, stating whether it is rebuilt as a Shuffle workflow, retired, or deferred, along with the apps or app creator work each one needs. Without that breakdown, two quotes cannot be compared fairly.
Next, ask how the target architecture is handled. Shuffle's documentation recommends an OpenSearch cluster, a shared cache, shared file storage when several backends run, and more than one Orborus node for high availability, so the quote should say which of these are in scope and which are your responsibility. Ask who owns the `SHUFFLE_ENCRYPTION_MODIFIER` secret, where it is stored, and how it is backed up, because losing or changing it breaks every saved app authentication. Also confirm how SSO is configured, whether through SAML or OpenID Connect, and how backups and restore tests are performed and evidenced.
Finally, ask for handover and post-delivery terms. The quote should list the documentation delivered (runbooks, workflow inventory, architecture diagrams and recovery steps) and who receives training. Confirm whether ongoing support, upgrades and continuous testing are a separate retainer or excluded, since Shuffle releases move quickly and each upgrade is a maintenance cost. Check the Shuffle install guide for current minimum requirements so hosting costs are included in your own budget, not left as an assumption.
How DeployOpen scopes a fixed-scope Shuffle implementation
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Google SecOps SOAR to Shuffle, the work starts with a written scope that separates the SOAR workload from the SIEM you keep.
How we scope
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which playbooks, integrations and alert sources move, and which stay on Google SecOps.
- We ask for your current Google SecOps package and ingestion volumes so the cost comparison matches your real setup.
How we build
- We plan the Shuffle deployment on Docker, Docker Swarm or Kubernetes, sized to your environment and approved architecture.
- We rebuild priority workflows in Shuffle and wire integrations through the App Creator or premade apps, then test each one.
- We configure SSO, the encryption secret for saved app credentials and high availability settings as part of the build.
How we hand over
- Deliverables include architecture notes, workflow documentation, configuration records and a runbook for your operations team.
- We document which Shuffle app runs and workflow execution counts your licensing model will meter, so costs stay predictable.
- We agree a handover session in the written scope and confirm which artifacts your team owns after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope build.
- We can keep Shuffle upgraded and backed up on a retainer, with the frequency and coverage set in the written agreement.
- Ask us to confirm which support tasks your team keeps in-house and which we cover before you sign.
