FortiSOAR cost vs self-hosted Shuffle

The first cost decision is topology, because the default Docker Compose setup is not a scalable build without changes, according to Shuffle's install guide. A single server with Docker Compose is the simplest way to start and is fine for evaluation, but any production plan needs a different shape. Shuffle documents distributed Docker Swarm and Kubernetes with Helm charts as alternatives, and a hybrid model in which Shuffle Cloud handles the control plane while a local Orborus node runs executions inside your network without inbound firewall ports. Each option moves cost between server hours, cluster skills and network changes, so ask your team which runtime it already operates and price that, not the lowest-effort path. The published minimum of 4 GB of RAM is a starting point for installation only. It is not a sizing for production volume, which depends on alert rates, the number of concurrent workflow executions and the apps you run. Confirm capacity with a load test in your own environment before you commit to hardware or cloud instances.

High availability is where most of the recurring infrastructure cost sits. Shuffle's configuration documentation recommends an OpenSearch cluster rather than a single node, optional Memcached for a shared cache, NFS for shared files when several backends run, backends and frontends scaled across servers, and more than one Orborus node so workflows keep running if one fails. Each of these is a component you must patch, monitor, back up and staff. Backups of OpenSearch data are the cost most often left unassigned. Decide who owns them: your platform team, a managed service you buy, or DeployOpen under a retainer. Whoever owns them must also protect SHUFFLE_ENCRYPTION_MODIFIER. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using this secret, and the documentation warns that losing or changing it breaks every saved app authentication. Store it in your secrets manager, include it in the backup runbook as a separate item, and test a restore on a non-production host before go-live.

Operations cost is the part that recurs for as long as the platform runs. Budget for on-call coverage for the automation itself, app upgrades (Shuffle apps run as versioned Docker containers), certificate and SSO maintenance, and workflow ownership. Ask any quote to separate one-time work (architecture, installation, migration, hardening and backup setup) from recurring work (upgrades, monitoring, patch windows and workflow changes), and to state which items are included in a fixed scope and which move to a retainer. The Shuffle licensing model counts app runs rather than users or workflows, so the volume of executions is a cost driver you should measure now. Quotes should also name who holds the admin credentials, who restores the cluster after a node failure and how upgrades are tested. Those answers tell you more about the true cost than the software line item.

Most of the migration cost is one-time, and it lands mainly in the first year. The work starts with an inventory: the FortiSOAR configuration export gives you the playbooks, modules and connector settings to count, and each item needs an owner who can say whether it is still in use. Rebuilding playbooks as Shuffle workflows is the largest block of effort, because logic written against FortiSOAR modules does not carry over one to one. Plan for analyst time to test each rebuilt workflow against sample alerts, not only to copy it across. Confirm with your Shuffle partner or internal team how many of your playbooks depend on connectors you already use, since that drives how much rebuilding is left.

Connectors are the second block. Shuffle builds integrations from OpenAPI specifications in its App Creator or ships premade apps for common security tools, so a FortiSOAR connector that wraps a documented REST API is usually replaced by a Shuffle app rather than by new code. Vendor APIs that are poorly documented or that rely on FortiSOAR-specific wrappers take longer, and each replacement app needs its credentials re-entered and tested. Ask for a per-connector list that marks which ones map to a premade app, which need a custom app, and which need a vendor API review before work starts.

Running both platforms side by side is the cost most often underestimated. Until each alert source is pointed at Shuffle and its output is checked, you pay for two sets of infrastructure, two sets of access controls and analysts who work in both consoles. Set a switchover order by alert source, define the acceptance test for each switch, and keep FortiSOAR in read-only mode for the records you must retain. Confirm the length of the overlap period with your own change board, because it is set by your alert volumes and risk tolerance, not by the platform. The sibling migration page covers the step-by-step process, so use this section to budget for it.

Put both options on the same term, using the same year-by-year model, so a multi-year FortiSOAR subscription is never set against a one-time Shuffle setup. Build one spreadsheet with a row for each cost component: the FortiSOAR subscription and each renewal, the servers it runs on, the Shuffle infrastructure, migration work, and the staff time spent building and maintaining workflows. Price staff time at your own loaded hourly rate, which your finance team sets, and log hours monthly so the figure reflects actual effort. Also count what FortiSOAR's price already includes. Its enterprise and multi-tenant features are part of the subscription, so if an MSSP model depends on tenant separation, confirm which tenancy features Shuffle provides in the edition you would run before you treat that gap as free.

Growth usually changes the comparison more than the starting price. Ask Fortinet for FortiSOAR pricing at your current user and node counts, then at the counts you expect in years two and three, including the nodes needed for high availability and scale-out. Shuffle prices on app runs, meaning actions that actually execute in a workflow, and its pricing article says users, apps and workflows are unlimited, so model app runs from your alert volume and the number of enrichment steps each playbook calls. Confirm which limits apply to the edition you choose, because Shuffle enforces the differences between its open-source and enterprise editions. Infrastructure grows as well. The Shuffle configuration docs recommend an OpenSearch cluster, shared Memcached, NFS and more than one Orborus node for high availability, and those servers recur every year.

Finally, record what the subscription includes that a self-hosted Shuffle deployment does not provide by default. Typically this means vendor support and escalation, FortiGuard-linked content and entitlement updates, and vendor-maintained connectors. For each item, name the replacement and its owner: a support agreement with Shuffle or a partner, an internal role that maintains apps built with the App Creator, or your own patching schedule. Mark which items recur and which are one-time, and set a review date for the comparison at each renewal so updated FortiSOAR pricing can be checked against the same assumptions. Request every quote in writing with the scope stated, so the FortiSOAR figures and your Shuffle figures describe the same workload.