Which SOAR fits your team: FortiSOAR or self-hosted Shuffle
Choose FortiSOAR if your SOC already runs on Fortinet, you want the vendor to own the product and its support, and FortiGuard-linked licensing is acceptable to your procurement and security teams. Choose self-hosted Shuffle if you need an open-source core, want control over where the platform runs, and have staff or a partner who can operate it. Picture a team facing a FortiSOAR renewal, a licensing change, or a data residency rule that requires alert and case data to stay inside a named country or network. In that situation, the question is less about features and more about who holds the license, who runs the servers, and where the data sits.
Four questions should drive the decision. First, connector coverage: list every tool your playbooks call today, then check each one against Shuffle's premade apps. For anything missing, confirm whether the App Creator can build it from an OpenAPI specification or whether a Python app is needed. Second, multi-tenancy: if you run an MSSP model, confirm that tenant separation and per-tenant single sign-on meet your contracts. Third, licensing: Shuffle's paid tiers meter app runs, while users, apps and workflows are unlimited, so ask Fortinet and Shuffle for quotes that model your actual alert volume. Fourth, maintenance: decide who will write, test and version playbooks after go-live.
Before committing, run a pilot on your three most-used playbooks. Shuffle's install guide says the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM, so plan the production topology early. Note that Shuffle stores saved app credentials encrypted with the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing it breaks every saved authentication, so the key must sit in your secrets process from day one. Use the Shuffle install guide to test a single-node build, then confirm high availability requirements with your own architects before you retire any FortiSOAR component.
Which option fits which scenario
This table maps six common SOC and MSSP scenarios to the platform that usually fits better, the reason for that fit, and the condition that would reverse the answer. Test each condition against your own requirements in a proof of concept. The main takeaway is that FortiSOAR tends to lead on vendor coverage and support, while Shuffle tends to lead on data control and licensing flexibility, with operating effort as the trade-off.
| Scenario | Better fit | Why | Reverses when |
|---|---|---|---|
| Fortinet-centric SOC | FortiSOAR | Existing Fortinet products and vendor-maintained modules reduce integration work and keep support in one vendor. | Most alert sources are non-Fortinet tools with OpenAPI specs that your team can wrap as Shuffle apps. |
| MSSP needing tenant separation | FortiSOAR, after testing | FortiSOAR offers a multi-tenant option. Confirm isolation, per-tenant reporting and billing against your client contracts. | Shuffle's per-tenant SSO enforcement and separate deployments meet your isolation and reporting model in testing. |
| Data must stay in your own network | Shuffle | Runs self-hosted on Docker, Kubernetes or a hybrid setup where local Orborus needs no inbound firewall ports. | Your team has already validated FortiSOAR's offline license handling and deployment in closed networks. |
| No in-house automation engineers | FortiSOAR | Vendor product support reduces the operating load on your team, and day-to-day playbook upkeep is simpler to hand off. | A partner operates Shuffle under a written scope, or your team already runs OpenSearch and container platforms. |
| Dependence on a large vendor connector catalog | FortiSOAR | A vendor-maintained catalog covers more products out of the box, with fewer custom integrations to maintain. | Your required tools are already covered by Shuffle's premade apps or can be built quickly from their OpenAPI specifications. |
| High availability with in-house platform skills | Shuffle | Documented pattern includes an OpenSearch cluster, several Orborus nodes and shared NFS, under your own control. | Your team lacks capacity to run and test that HA design, so a managed or vendor-run option is safer. |
Where the data lives and who controls the platform
Both platforms can run inside your own environment, but the operating model differs. The cards below cover where each product runs, where case and credential data is stored, how identity is wired in, and what evidence you will need for a compliance review.
Hosting models on each side
FortiSOAR is available as vendor-managed or self-managed software, so you need to confirm which model your contract covers and who patches the platform. Shuffle is self-hosted through Docker Compose, Docker Swarm, or Kubernetes with Helm charts, or in a hybrid model where Shuffle Cloud runs the server and a local Orborus runtime executes actions in your network. Ask FortiSOAR's sales team to name the deployment options in writing, and confirm which Shuffle architecture fits your network zones.
Hybrid mode and firewall exposure
In the hybrid architecture, the local Orborus component polls the backend for jobs, so it needs no inbound firewall ports. That matters for SOCs that do not want a listening service inside a production segment. Actions still reach your tools and apps from the local runtime, so map which egress paths each app needs. A fully self-hosted FortiSOAR deployment follows its own network design, and that design should be reviewed against your current segmentation.
Data residency and the OpenSearch store
Shuffle keeps workflows, execution records and saved app credentials in an OpenSearch document database that you operate in a self-hosted install. Saved credentials are encrypted with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that secret breaks every saved app authentication. Store it in your secrets manager and back up OpenSearch. Confirm where FortiSOAR keeps its records, attachments and logs, and which of those leave your environment through FortiGuard or vendor telemetry.
Identity integration and access control
Shuffle supports SAML single sign-on from version 0.9.16 and OpenID Connect from 1.0.0, with per-tenant SSO enforcement, and SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. Check that your identity provider supports OpenID Connect and that role mapping covers analysts, engineers and tenant administrators. Ask FortiSOAR which identity protocols and role models it supports in the version you run, and how local accounts are controlled.
Compliance evidence and auditor roles
Either platform can be part of a control environment, but the controls belong to your organization. DeployOpen prepares systems, configuration, logging and evidence for an assessment, while independent auditors and certification bodies issue reports. Decide early which evidence you need, such as access reviews, change records, backup restores and encryption key handling, and confirm that each platform can export it. Ask both vendors for their documentation on audit logging and retention before selecting.
What the AGPLv3 and MIT split means for licensing
The first thing to settle is that Shuffle does not carry one license across its whole codebase. The backend is licensed under AGPLv3, while workflows, documentation, apps and app specifications are licensed under MIT. That split matters because the material your team writes and shares, such as playbooks, app definitions and internal documentation, carries the permissive MIT terms, while changes to the backend server carry the copyleft obligations of AGPLv3. The project's open source material describes the code as AGPL-3.0. Read the Shuffle GitHub repository yourself and record which components your deployment touches before you rely on either summary.
Commercial terms sit on top of the open-source edition. Shuffle states that all features are available in the open-source edition, and that its paid tiers differ in feature limits, scaling and support. Paid licensing is based 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. Since v2.1.1, the limits between the open-source and enterprise editions are actively enforced, so a deployment that exceeds a limit will meet that enforcement. Pull a month of execution history from a pilot, estimate your app runs from it, and get the enforcement behavior and support terms confirmed in writing before you commit to a tier. The Shuffle pricing article sets out the metric in full.
FortiSOAR is licensed on a different basis. Its license entitlements are fetched from FortiGuard, so renewals, license capacity and operation in closed networks depend on Fortinet's entitlement process. Ask Fortinet in writing what happens when a renewal lapses, whether the platform keeps running and what the offline entitlement path involves if your network has no route to FortiGuard. For Shuffle, the AGPLv3 obligations are the item to take to counsel. Copyleft duties generally attach when you modify the AGPL-licensed backend and make it available to others, and the network-use provisions can reach software you offer to users as a service. An MSSP running Shuffle for clients should have counsel map which components are modified, who receives them and how source is provided. Counsel should review this against your actual deployment model, not rely on this summary.
What each option costs to own, by component
Ownership cost on the FortiSOAR side is driven by licensing and sizing, while on the Shuffle side it is driven by infrastructure, high availability design and the people who maintain workflows. Compare the components below line by line, and ask each vendor or partner for a written breakdown before you decide.
FortiSOAR licensing and subscription
FortiSOAR is licensed commercially, and its license and entitlement terms depend on the deployment you choose. Ask Fortinet or your reseller how the license scales with users, nodes and high availability or scale-out nodes, and whether it renews annually. Confirm whether FortiGuard entitlement checks add operational work in your environment. This is the recurring line you cannot reduce by tuning the platform.
Shuffle software and paid tiers
The Shuffle backend is AGPLv3 and its workflows, apps and documentation are MIT, so the core software carries no license fee for self-hosting. Shuffle says all features are in the open-source edition, while paid tiers differ in feature limits, scaling and support. Its pricing is based on app runs, so ask whether you need a paid tier and how often your workflows will execute.
Servers and minimum sizing
A single Shuffle node needs at least 4 GB of RAM according to its install guide, but the default Docker Compose setup is not scalable without changes. FortiSOAR's own sizing guidance for its servers is higher, so compare the two against your alert volume. Your infrastructure cost is what you pay your cloud provider or hardware budget, and it recurs unless you own the hardware.
High availability infrastructure for Shuffle
Production high availability adds cost in several places: 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 adds compute, storage and monitoring. Ask your partner which of these you truly need for your SOC uptime target before sizing the cluster.
Migration and rebuild effort
Moving from FortiSOAR is largely one-time work: inventorying playbooks, modules and connectors, rebuilding playbooks as Shuffle workflows, replacing connectors with Shuffle apps or OpenAPI-built integrations, and running both platforms side by side. Cost depends on how many playbooks and custom connectors you have and how many alert sources must be switched. Ask for a written inventory before agreeing a fixed scope.
Staff who maintain workflows
The largest recurring cost is often people: engineers who patch the platform, upgrade Docker images, rotate the SHUFFLE_ENCRYPTION_MODIFIER secret, maintain apps and keep workflows current. Loss of that encryption secret breaks every saved app authentication, so key custody needs a documented owner. Decide whether your team absorbs this work or whether a retainer covers upgrades, testing and support.
What a move from FortiSOAR to Shuffle involves
The sequence turns FortiSOAR playbooks, connectors and case data into Shuffle workflows and apps that run on your own infrastructure, and ends with alert sources pointed at Shuffle. Each step has a named owner and a check that confirms it is finished.
Inventory playbooks, modules and connectors
Your security engineers run FortiSOAR's Configuration Export wizard and list every playbook, module and connector setting it captures. They mark which playbooks are active, which connectors have live credentials, and which custom code depends on FortiGuard-tied licensing. The step is done when the inventory names each playbook, the systems it touches and the owner who signs off on keeping it. Confirm with Fortinet which parts of the export are portable before you rely on them as a complete backup.
Store the encryption secret before anything else
Before any credentials are re-entered, your security team records the SHUFFLE_ENCRYPTION_MODIFIER value in your existing secrets manager with restricted access and a documented owner. Shuffle encrypts saved app credentials and API keys in OpenSearch using this secret, and the configuration docs warn that losing or changing it breaks every saved app authentication. The step is done when a second authorized person can retrieve the value and a test restore has been run in a non-production instance.
Stand up the Shuffle environment
Your platform team deploys Shuffle in your own cloud account, data center or cluster using Docker Compose for a single server, Docker Swarm, or Kubernetes with Helm charts. The install guide notes that the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM, so size the environment against your alert volume and high availability needs. The step is done when the frontend loads, the backend answers and an Orborus node runs a test workflow.
Rebuild playbooks as Shuffle workflows
Your SOC engineers rebuild each inventoried playbook as a Shuffle workflow, starting with the highest-volume ones. FortiSOAR logic does not translate automatically, so each decision branch, data mapping and approval step is redesigned and tested against sample alerts. The step is done when each workflow produces the same case outcome as the original playbook on replayed test data, and the analyst who owns the process has approved the result.
Replace connectors with Shuffle apps
For each connector in the inventory, your integration engineers either select a premade Shuffle app or build one in the App Creator from the vendor's OpenAPI specification, or write a Python app with the Shuffle app SDK. Each app runs as a versioned Docker container, so pin versions and keep the image sources under your change control. The step is done when every production action has an app, a tested credential and a documented owner. Ask the vendor or your integrator to confirm that the API you need is covered by a specification.
Move case data and re-enter credentials
Your team decides which open cases and historical records must move, then migrates them by export and import or by recreating the essential fields in Shuffle, since record structures differ between the two platforms. Credentials are re-entered in Shuffle only after the encryption secret is confirmed, and each one is tested against its target system. The step is done when a sample of migrated cases matches the source records and every app authentication succeeds.
Run both platforms side by side
For a defined overlap period set by your change board, FortiSOAR and Shuffle process the same alerts while analysts compare outcomes for each workflow. Discrepancies are logged, fixed in Shuffle and retested until the team accepts the results. The step is done when every workflow has a recorded comparison with no unexplained differences and the rollback path is written down and tested.
Switch alert sources to Shuffle
Once parallel runs are accepted, your team repoints each alert source, such as SIEM forwarding, email intake or ticket triggers, to Shuffle one at a time, starting with the lowest-risk source. Monitoring confirms that workflows execute for each switched source, and FortiSOAR is kept read-only for reference. The step is done when all sources feed Shuffle, the last FortiSOAR trigger is disabled, and the backup and high availability settings recommended in the configuration docs are in place.
Questions buyers ask before choosing a SOAR platform
How much effort does a FortiSOAR to Shuffle migration take?
The effort depends mostly on how many playbooks, connectors and alert sources you run, and how much logic each playbook carries. The work covers inventorying playbooks and modules, rebuilding each playbook as a Shuffle workflow, replacing each FortiSOAR connector with a Shuffle app, moving case data, and running both platforms side by side until alert sources are switched over. Recurring effort is the ongoing upkeep of workflows and apps after go-live. Ask for a written scope that lists playbook count, connector count, data volume and the cutover plan before you compare figures.
Can our team run Shuffle without an implementation partner?
An internal team can run Shuffle, and Shuffle states that all features are available in its open-source edition. The install guide says the default Docker Compose setup is not scalable without changes and needs at least 4 GB of RAM, so production design is the first gap to close. A partner is most useful for architecture, hardening, integration with your SOC tools, backup design and testing. Confirm that your team has capacity for those tasks and for on-call support before you decide. Shuffle install guide lists the baseline requirements.
What skills does a team need to operate Shuffle?
Operators need container platform skills, with Docker Compose or Docker Swarm for smaller builds and Kubernetes with Helm charts for larger ones. They also need to administer an OpenSearch datastore, since Shuffle uses OpenSearch as its database. Engineers building custom integrations need OpenAPI familiarity for the App Creator and Python for the app SDK. Your analysts need working knowledge of your playbook logic. Keep a named owner for the SHUFFLE_ENCRYPTION_MODIFIER secret, because losing or changing it breaks every saved app authentication.
How long does a move from FortiSOAR to Shuffle take?
The duration is set by scope, so ask for a timeline built from your own inventory rather than a generic number. The main drivers are the number of playbooks and connectors, the complexity of case data you must move, the length of the parallel run, and how many alert sources you switch over. Ask the provider to show milestones for inventory, workflow rebuilds, testing, parallel running and cutover, along with the dependencies each milestone has on your staff and change windows. Any timeline should be written into the agreed scope.
Can we reuse FortiSOAR connectors in Shuffle?
Not as a direct swap, because a FortiSOAR connector is not a Shuffle app. Shuffle apps are built from OpenAPI specifications in the App Creator or written in Python with the Shuffle app SDK, and they run as versioned Docker containers. In practice you reuse the knowledge in each connector: endpoints, authentication model, field mappings and the logic around them. Check the license terms on any FortiSOAR connector before copying code, and confirm whether Shuffle's premade apps already cover each security tool you use. Shuffle apps docs explain how apps are built.
How does multi-tenancy work for an MSSP on Shuffle?
Shuffle's SSO supports per-tenant enforcement, but that is only one part of tenant separation. Before you commit, confirm how Shuffle separates workflows, cases, credentials and reporting between customers, and test that separation in your own environment. Two common designs are one deployment per customer and a shared platform with tenant controls. Your costs change with each choice, since the infrastructure and the app runs you pay for multiply or pool accordingly. Ask Fortinet to explain how FortiSOAR tenancy is licensed and enforced so both options are compared on the same terms.
What does high availability require in a self-hosted Shuffle deployment?
Shuffle's configuration docs recommend an OpenSearch cluster, optional Memcached for a shared cache, and NFS for shared files when you run several backends. Scale the backend and frontend across your servers, and run more than one Orborus node so workflows keep running if one node fails. The architecture docs also describe a hybrid option with a local Orborus, which needs no inbound firewall ports. Confirm sizing with a load test in your own network, and back up OpenSearch and the encryption secret as part of the design. Shuffle configuration docs list the settings.
How the choice gets tested in your environment
The right answer between FortiSOAR and Shuffle depends on four inputs that only your environment can supply: the connector list you must keep, the number of playbooks and how often they change, the tenancy model you need for customers or business units, and your licensing position with Fortinet. Start by writing down the connectors that alert sources and response actions depend on today, then mark which ones have a maintained Shuffle app, which need an app built from an OpenAPI specification in the App Creator, and which would require a Python app written with the Shuffle app SDK. That list usually decides the effort more than any feature table does.
Next, write a short evaluation scope that a named owner can sign off. It should cover a representative set of playbooks (for example, a phishing triage flow, an endpoint containment flow and one flow that touches a ticketing system), the case and incident handling steps analysts use every day, the SSO and role model you need, and the MSSP or multi-tenant layout if you serve several customers. For Shuffle, add the deployment target (single server with Docker Compose, Docker Swarm, Kubernetes with Helm, or the hybrid model with a local Orborus), the OpenSearch sizing, and the high availability design your uptime needs. Confirm the app run volume you expect, because that is the metric Shuffle's licensing uses for its paid tiers. Ask Fortinet for the licensing terms tied to FortiGuard and the node count your HA design requires, in writing.
Run the scope as a timed test against both platforms with the same inputs, and record what breaks: credential handling, failed app runs, upgrade steps and any feature you assumed was in the open-source edition but must be confirmed in the Shuffle configuration documentation. Treat the results as evidence for your decision, not as a verdict. If the test shows gaps, decide whether to close them with your own code, a paid edition or a different platform. DeployOpen can plan and run this evaluation as a fixed-scope engagement with the scope agreed in writing before work starts, but the decision, and the owner of the result, stay with your team.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For FortiSOAR vs Shuffle, we start with your playbooks, connectors, licensing position and operating model, then turn the choice into a written scope before any build work begins.
How we scope
- Inventory your current playbooks, connectors, case types and alert sources before comparing platforms.
- Agree in writing which Shuffle deployment architecture fits your environment, such as Docker Compose, Swarm, hybrid or Kubernetes.
- Define who will operate Shuffle, Orborus nodes and OpenSearch, and what support you expect after go-live.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Deploy Shuffle in your infrastructure and configure high availability with OpenSearch, shared storage and multiple Orborus nodes where required.
- Rebuild priority playbooks as Shuffle workflows and create apps from OpenAPI specifications for connectors without a premade app.
- Configure SSO through SAML or OpenID Connect and set the encryption secret handling your key management policy requires.
- Test workflows, app runs and failure behavior against the scope before any alert source is switched over.
How we hand over
- Document architecture, configuration, app versions, workflow ownership and secret rotation procedures in writing.
- Train your analysts and engineers on building, reviewing and versioning workflows and custom apps.
- Provide backup and restore procedures for OpenSearch and Shuffle configuration, with a tested recovery path.
- Prepare evidence for your own compliance assessments, while independent auditors and certification bodies issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Plan Shuffle version upgrades, including testing on the nightly or a pinned Docker tag before production rollout.
- Run security testing of workflows, apps and integrations to check credential handling and exposed endpoints.
- Review app run volume and scaling needs with you so capacity and licensing decisions stay informed.
