Cortex XSOAR Community Edition end of life: free self-hosted alternatives

A paid Cortex XSOAR license is a recurring subscription, and its price comes from a vendor quote, so ask Palo Alto Networks or your reseller for the figure and the metric it is based on. The license is only part of the cost. On premises, you also pay for servers or virtual machines, storage, backups and upgrade work. In SaaS, hosting is included, but you still review data handling and integration access. The effort is often larger than the license. Your team keeps playbooks, integrations and content current, tests changes, and maintains connections to the SIEM and ticketing tools. Ask for the licensing metric, what counts toward it, the deployment options, the support tier and the migration path from XSOAR 6 if you run it on premises. Confirm these figures in writing before you compare them with open-source running costs.

No single duration applies, because the time depends on what you built. The main factors are the number of playbooks, the number of custom integrations and scripts, how many incident triggers come from your SIEM, and whether analysts depend on the war room and incident layouts. Start with an inventory. The Cortex XSOAR 8 documentation describes exporting custom content from Settings, Server Settings, Custom content, then Export all custom content, and downloading individual playbooks from the content item menu. Expect JavaScript integrations and logic tied to XSOAR's runtime to need a full rebuild. In Shuffle, apps are built in the App Creator from OpenAPI specifications or written in Python. Run the old and new platforms side by side on one use case at a time, and ask any implementation partner for a written timeline based on that inventory.

Yes, if the team has the right skills, and the skills needed depend on the target platform. Shuffle deploys with Docker or Kubernetes, and its install guide sets a minimum of 4 GB of RAM. Someone has to run containers, manage OpenSearch, handle backups and protect the encryption secret. Apps need Python or OpenAPI work, and playbook logic needs someone who understands both the response process and the code. Ask who will be on call when a workflow stops, who writes the first set of apps, and who tests each change before it reaches production. A small team with one platform engineer and an analyst who can script can often run a pilot. Production use across several tools usually needs a named owner and a documented runbook. A fixed-scope engagement can cover parts of this work and hand it over to your staff in writing.

It can, but the license terms decide the answer, not the feature list alone. Shuffle says all features are available in its open-source edition, and its paid tiers differ in feature limits, scaling and support. Since v2.1.1, those limits are actively enforced, so check which limits apply to your client count and run volume before you commit. Shuffle's pricing article describes licensing on app runs, with users, apps and workflows unlimited under that metric. Tracecat is licensed under AGPL-3.0, while multi-tenant workspace management is an Enterprise feature. Under either tool, ask your legal counsel whether running it to deliver managed services to clients is permitted. Then check that client data separation, audit trails and access controls meet each contract, and document which tenant owns which workflow.

Shuffle prices paid licensing on app runs, which are actions that actually execute in a workflow. Triggers and skipped actions are not counted under that metric. Users, apps and workflows are unlimited, so cost follows execution volume, and the number of analysts does not change it. To estimate exposure, count how many actions your playbooks run each day, including enrichment lookups. Alert volume from your SIEM usually drives this more than the number of playbooks. A playbook that enriches every alert will generate far more runs than one triggered by a weekly report. Illustrative example: a playbook with five actions that fires on 200 alerts a day produces a run count you can calculate from your own alert data. Ask Shuffle how your workload maps to its paid tiers in writing before you rely on the open-source edition for production.

Automation only works as well as the process it encodes. The SOC has to supply named playbook owners, documented triage steps, approval rules for containment actions and analysts who test changes before they go live. Shuffle has no built-in incident layouts or war room, so decide where case records will live. The options are a separate ticketing or case system, or a tool such as Tracecat that includes cases. Map your current incident types, fields, SLAs and analyst notes before you build anything. Agree on service accounts and credential rotation for each connected tool, because saved app credentials depend on the encryption secret. Plan on-call coverage for the automation platform itself, since a stopped workflow can leave alerts unhandled. Review the playbook list each quarter so that automation does not act on tools that have changed.

The default setup is usually the first problem. Shuffle's install guide says the default Docker Compose setup is not a scalable build without changes, so plan the changes before go-live. For high availability, the configuration docs recommend an OpenSearch cluster, shared files over NFS when running several backends, and more than one Orborus node so workflows keep running if one fails. Shuffle encrypts saved app credentials with SHUFFLE_ENCRYPTION_MODIFIER, and losing or changing that value breaks every saved app authentication. Store it in a secrets manager and back it up separately from the database. Test restores, not just backups. Monitor OpenSearch disk usage, because execution history grows with volume. When an upstream vendor changes its API, retest the affected apps before the change reaches production.

A fixed-scope engagement makes sense when the work has clear boundaries that you can agree in writing before it starts, such as moving a defined set of playbooks, hardening a Shuffle deployment, or setting up backups and documentation. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the deliverables list, the exclusions and the handover plan in the quote.