Shuffle vs Tracecat: when each one fits your security team
A security team shortlisting two AGPL-3.0 SOAR platforms should expect Shuffle to fit best when the team wants to build integrations from OpenAPI specifications in the App Creator and run executions on hybrid on-premises Orborus workers that need no inbound firewall ports. Tracecat fits better when durable, Temporal-based workflows, built-in case management and custom AI agents with tools and MCP servers sit at the center of the work. Both cores are AGPL-3.0, so the license alone will not settle the choice. Confirm what each platform's enterprise edition adds for your use case before you commit.
The decision turns on three questions. First, how much Docker or Kubernetes operating work your team will accept: Shuffle documents single-server Docker Compose, Docker Swarm, a hybrid cloud model and Kubernetes with Helm, while Tracecat documents Docker Compose on one host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart and an air-gapped Kubernetes option. Second, which enterprise features are mandatory. Tracecat lists multi-tenant workspace management and Git version control integration as enterprise features and describes authentication and single sign-on the same way. Shuffle added SAML in 0.9.16 and OpenID Connect in 1.0.0, and its paid limits are enforced since v2.1.1, so verify which SSO and tenancy controls your license tier includes. Third, whether AI agents are in scope at all, since that is a core Tracecat feature and not a central Shuffle one.
Before you shortlist, run a short proof of concept on your own infrastructure with one real-world playbook from each platform. Check how SSO, tenant separation and secrets handling behave in your environment, and ask both vendors in writing which features sit behind a paid license. Keep the encryption secret for Shuffle's saved app credentials under change control from day one, because the Shuffle docs warn that losing or changing it breaks every saved app authentication. DeployOpen can plan, implement and harden either platform inside your own infrastructure under a fixed-scope agreement.
Which team should choose Shuffle vs Tracecat in each scenario
This table maps common team situations to the platform that fits better, with the supplied facts behind each call. Read each row as a starting point: where a row depends on an enterprise license or a condition you must confirm, the cell says so.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| CERT or SIRT automating enrichment across many vendor tools | Shuffle | The App Creator builds integrations from OpenAPI specifications and apps run as versioned Docker containers. Confirm that your vendors publish usable OpenAPI specs or that Python app SDK work is acceptable. |
| SOC that needs case management in the same platform as automation | Tracecat | Tracecat documents case management, structured tables and webhook triggers in one product. Shuffle's case handling is not part of this comparison, so confirm it against your ticketing needs. |
| Team building AI-assisted triage with custom agents | Tracecat | Tracecat documents custom AI agents with tools and MCP servers. Confirm that your model provider and MCP servers meet your data handling rules before go-live. |
| Team with an existing Kubernetes platform group | Tracecat | Tracecat documents a Helm chart and an AWS ECS Fargate option, and its stack adds Temporal and PostgreSQL that your platform group must run. Shuffle also offers a Helm chart, so compare operating load for OpenSearch and Orborus against Temporal and PostgreSQL. |
| Hybrid model with workers inside a restricted network and a cloud control plane | Shuffle | Shuffle documents a hybrid setup where a local Orborus needs no inbound firewall ports. Confirm whether your policy allows a cloud control plane at all, because this option depends on it. |
| MSSP running workflows for several clients | Depends on license | Shuffle prices on app runs and says users, apps and workflows are unlimited, but tenant limits sit in paid tiers. Tracecat's multi-tenant workspace management is an enterprise feature. Ask both vendors for the license terms that cover your client count and data separation. |
| Air-gapped environment | Tracecat | Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Confirm that Shuffle's Docker or Kubernetes install, and any app images you pull, can be mirrored into your enclave before choosing it here. |
How Shuffle's Orborus workers and Tracecat's Temporal workflows are built
Both platforms are open source under AGPL-3.0, but they split work across different stateful services. The cards below cover the components each team would run, how execution is handed to workers, and what high availability and sandboxing mean for the people who operate the stack.
Shuffle's frontend and Go backend
Shuffle's server side is a frontend plus a Go backend API on port 5001. The backend is the component you scale across servers when you run several instances, so the check is whether your load balancer and firewall rules expose that port only to the intended internal networks. Ask the vendor or confirm in your own environment how the frontend and backend are packaged for your chosen deployment before you size the hosts.
OpenSearch as Shuffle's document store
Shuffle keeps its data in OpenSearch, which means the search cluster is a stateful dependency your team must patch, back up and size. Shuffle also encrypts saved app credentials in OpenSearch with AES-256 using SHUFFLE_ENCRYPTION_MODIFIER, and changing that secret breaks every saved app authentication. Plan key custody and backups for both the cluster and the modifier before go-live.
Orborus polling and per-execution workers
Orborus polls the Shuffle backend for jobs, starts a worker for each workflow execution, and the worker starts app containers. This means execution capacity lives on Orborus hosts, separate from the control plane. The hybrid model lets a local Orborus run without inbound firewall ports, which matters when your automation must reach systems inside a segregated network.
Shuffle high availability dependencies
Shuffle's high availability guidance adds an OpenSearch cluster, optional Memcached for a shared cache, NFS for shared files across several backends, and more than one Orborus node so workflows keep running if one fails. Each addition is another service to monitor. Ask whether your team can operate NFS and Memcached alongside OpenSearch, since a Shuffle HA build depends on all of them.
Tracecat's FastAPI and Next.js layers
Tracecat pairs a Python FastAPI backend with a Next.js frontend. Both are application tiers that your team deploys from the same repository, and the Docker Compose, ECS Fargate, Helm and air-gapped Kubernetes paths all package them differently. Confirm which deployment option you will run, because that choice determines how much of the Kubernetes or Terraform tooling your platform team must maintain.
Temporal and PostgreSQL in Tracecat
Tracecat uses Temporal for durable workflow execution and PostgreSQL for data, so a self-hosted Tracecat deployment brings a workflow engine as well as a relational database into your operating scope. Temporal is the component that resumes runs after failures, which is the main reason to choose Tracecat for long or multi-step automations. Ask how Temporal's own persistence, upgrades and backups are handled in the deployment you pick.
S3 storage and nsjail sandboxing
Tracecat stores objects in an S3-compatible store and sandboxes execution with nsjail. Your team must provision and secure that object store, and must verify that the sandbox runs on the host and kernel configuration you intend to use, including air-gapped Kubernetes. Confirm these requirements with the vendor before you commit to an air-gapped design, since sandbox behavior depends on the host.
Shuffle vs Tracecat feature by feature
This table sets Shuffle and Tracecat side by side on license, release, integration model, workflow engine, AI features, deployment, identity and multi-tenancy. Where a supplied fact does not settle a row, the cell says what to confirm with the vendor, so the table can be used as a checklist during evaluation.
| Capability | Shuffle | Tracecat |
|---|---|---|
| License | AGPL-3.0 for the code, with workflows and modular app content under MIT | AGPL-3.0 for the code, with packages/tracecat-ee and enterprise feature gates under a separate paid Enterprise Edition license |
| Current release | 2.3.0, published September 28, 2026 | 1.2.0, released October 16, 2026 |
| App or integration model | Apps built in the App Creator from OpenAPI specifications or written in Python with the Shuffle app SDK, run as versioned Docker containers | More than 100 prebuilt connectors, webhook triggers and custom actions synced from Git |
| Workflow engine | Go backend with Orborus polling for jobs and starting a worker per workflow execution; OpenSearch stores data | Temporal for durable workflow execution; PostgreSQL for data; nsjail for sandboxing |
| Case management | Confirm the current capability and its edition limits with Shuffle | Included in the platform, alongside structured tables |
| AI agents and MCP servers | Confirm whether Shuffle offers agents or MCP server support with Shuffle | Custom AI agents with tools and more than 50 hosted MCP servers |
| Deployment options | Single server with Docker Compose, distributed Docker Swarm, hybrid with a local Orborus, and Kubernetes with Helm charts | Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes via Helm, and air-gapped Kubernetes |
| Single sign-on | SAML and OpenID Connect, on-premises and in cloud, with per-tenant enforcement; SAML is being deprecated on Shuffle Cloud | Authentication and single sign-on are documented as enterprise features |
| Git version control and multi-tenant workspaces | Confirm with Shuffle which tenant and version control features sit in each license tier | Git version control integration and multi-tenant workspace management are listed as Enterprise features |
How Shuffle's OpenAPI app creator compares with Tracecat's custom actions and AI agents
Shuffle extends through apps, and the App Creator builds them from OpenAPI specifications. Each app runs as a versioned Docker container, and the Shuffle app SDK in Python covers integrations that a specification cannot describe well. This model matters most when your integration backlog is mostly REST-based tools that already publish OpenAPI documents. Your team can generate an app from a specification, add authentication and actions, and version it like any other container image. Check how your specifications handle pagination, webhooks and non-standard authentication, because those details decide how much hand-written Python you will maintain.
Tracecat extends through custom actions synced from Git, webhook triggers, structured tables and custom AI agents with tools and MCP servers. Action code lives in a repository, which suits teams that already review, branch and approve changes through Git. Its AI agents can call tools and MCP servers, so an AI-assisted triage roadmap fits this model more directly than an OpenAPI-first one. Confirm which Git version control features your edition includes, because the Tracecat repository names Git version control integration as an Enterprise feature. Tracecat's workflow engine runs on Temporal, and Shuffle's runtime relies on Orborus workers, so the two models also differ in how they scale and fail.
Choose by testing your three hardest integrations on both platforms before deciding. Pick one that has a clean OpenAPI document, one with poor documentation or custom authentication, and one that needs a decision or agent step. Build each in a non-production instance of Shuffle and Tracecat, then record the hours, the code you write, the number of files you maintain and how an update to the upstream API would reach your workflows. An OpenAPI-first backlog points toward Shuffle, while a Git-managed action library or an AI triage plan points toward Tracecat. Ask both vendors to confirm in writing which of these features your target license includes.
What each platform puts behind a paid license
Shuffle's code is licensed under AGPL-3.0, while workflows and modular app content are MIT, according to the LICENSE file and README in the Shuffle GitHub repository. Shuffle states that all features are available in the open-source edition. Its paid Business and Enterprise tiers do not unlock different features. They differ in feature limits, scaling and support. Since v2.1.1, those limits are actively enforced, so a deployment that exceeds them is constrained by the software rather than by a license audit.
- Code and content licenses: The platform code is AGPL-3.0, and workflows and modular app content are MIT. Review both when you plan to modify the code or share workflows with other organizations.
- Enforced limits since v2.1.1: The open-source and enterprise editions differ in limits that are enforced in software. Check which limits apply to your planned run volume, tenants and locations.
- The app runs metric: Licensing counts app runs, meaning actions that actually execute in a workflow. Triggers and skipped actions are not counted. Users, apps and workflows are unlimited, so the metric scales with automation activity, not headcount.
- Scaling and high availability: Scaling features, such as running more than one Orborus node for continuity, are a common reason teams compare tiers. Confirm in writing which of these features sit in each tier.
- Support and onboarding: Paid tiers add vendor support. Ask what response commitments and onboarding are included.
Before committing, ask Shuffle for a quote that maps your expected monthly app runs, tenant count and HA design to a specific tier, and confirm the metric definition in writing.
Tracecat is licensed under AGPL-3.0, according to the TracecatHQ/tracecat repository. Code in packages/tracecat-ee and the enterprise feature gates is under a separate paid Enterprise Edition license. The core automation engine, webhook triggers, case management, structured tables and AI agents are described in the Tracecat documentation without an enterprise label. The paid boundary is therefore drawn at specific named features and at the enterprise code path, not at the whole product.
- Enterprise code path: Files in
packages/tracecat-eeand the enterprise feature gates fall under the Enterprise Edition license. Confirm with the vendor which functions your deployment would call. - Multi-tenant workspace management: The repository names multi-tenant workspace management as an Enterprise feature. This matters if you plan to separate teams, customers or business units inside one installation.
- Git version control integration: Git version control integration is also named as an Enterprise feature. Teams that want workflow changes reviewed through their own repositories should confirm this in the paid tier.
- Authentication and single sign-on: The Tracecat documentation describes authentication and single sign-on as enterprise features. Identity integration is often required in regulated environments, so verify whether your identity provider needs a paid tier.
- Connector and MCP scope: The repository lists more than 100 prebuilt connectors and more than 50 hosted MCP servers. Confirm which of these are open-source and which depend on the enterprise terms for your use.
Before procurement, request the current Enterprise Edition license text and a written list of gated features from Tracecat, and confirm that your planned SSO and tenancy model is covered.
How SSO and identity integration differ, and what sits behind enterprise
Both platforms are AGPL-3.0 and both put identity features in different places, so the SSO question is partly a licensing question. The cards below separate what Shuffle ships in its open-source edition from what Tracecat lists as enterprise, and they flag the items you must confirm with each vendor before you commit.
Shuffle SAML and OpenID Connect
Shuffle added SAML single sign-on in version 0.9.16 and OpenID Connect in 1.0.0, and both are available on-premises and in the cloud. This matters most for a team that already runs an OpenID Connect identity provider and wants analysts to sign in without local Shuffle accounts. Check which identity provider settings your environment needs and test login with a non-admin account before rollout, since the docs describe SSO as configured per deployment.
SAML deprecation on Shuffle Cloud
The Shuffle docs state that SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect. If you plan to use the hybrid model, where a cloud control plane pairs with a local Orborus, confirm which SSO method your tenant will use and whether an existing SAML integration needs migration. A self-hosted deployment is not affected by this cloud change, but its SAML configuration should still be reviewed against your identity provider's own deprecation timeline.
Tracecat SSO and auth listed as enterprise
The Tracecat documentation describes authentication and single sign-on as enterprise features, so a self-hosted Community deployment should be assumed to lack them until your vendor confirms otherwise. If your security team requires centralized sign-in from day one, price the Enterprise Edition into the comparison. Ask which protocols the enterprise edition supports and whether it covers SAML, OpenID Connect or both before you assume parity with Shuffle.
Multi-tenant workspaces for MSSPs
Tracecat names multi-tenant workspace management as an Enterprise feature. For an MSSP or a group that keeps separate client environments, this is the item that decides whether one deployment can serve several clients with per-tenant SSO. Shuffle's per-tenant SSO enforcement is a separate capability, so test how tenant boundaries, role assignment and audit trails behave in each product, using an illustrative two-client pilot before you rely on either model.
Confirm identity items with each vendor
The supplied facts do not establish supported identity providers, group-to-role mapping, or SCIM provisioning for either platform. Ask both vendors which identity providers they certify, how IdP groups map to workflow and admin roles, whether SCIM deprecation or user lifecycle sync is supported, and how deprovisioned users lose access to saved app credentials. Get the answers in writing before you size the license.
What running and implementing each platform costs in people and infrastructure
The largest recurring cost is the set of components each platform keeps running. Shuffle's server side is a frontend, a Go backend API and an OpenSearch document database, and its runtime side is one or more Orborus nodes that start a worker for each execution, which in turn starts app containers. The configuration docs recommend an OpenSearch cluster, more than one Orborus node and, when several backends run, NFS for shared files and optional Memcached. Tracecat needs PostgreSQL, Temporal for durable workflow execution, an S3-compatible object store and nsjail for sandboxing, on top of its FastAPI backend and Next.js frontend. Each of these is a separate system to size, back up, monitor and patch inside your own accounts or data center. Ask the vendor or DeployOpen to show the sizing for the OpenSearch cluster on one side and the Temporal and PostgreSQL deployment on the other.
Staff skills and the one-time versus recurring split decide who carries the work. Shuffle's documented deployments are Docker Compose, Docker Swarm, Shuffle Cloud with a local Orborus, and Kubernetes with Helm, so an operator needs container orchestration skills that match the chosen target. Tracecat documents Docker Compose, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart and an air-gapped Kubernetes option, and its operators also need Temporal and PostgreSQL knowledge. One-time costs include the initial build, workflow and integration design, SSO setup and migration of existing playbooks. Recurring costs include upgrades, backups, capacity changes and any license fees. Upgrade effort follows release cadence: Shuffle 2.3.0 was published on September 28, 2026, and Tracecat 1.2.0 on October 16, 2026, so confirm how often each team expects to take a release and who tests it. The Shuffle pricing article explains the app run metric that drives Shuffle license scope.
Cost drivers differ by platform, and the quote should reflect them. Under Shuffle's pricing model, the metric is app runs, meaning actions that execute in a workflow, so higher automation volume raises the license scope even though users, apps and workflows are unlimited. Under Tracecat, multi-tenant workspace management and Git version control integration sit in the Enterprise Edition, so the number of tenants and the need for those features set the license tier. Ask for the scope of apps and connectors to build or customize, the number of workflows to migrate, the HA design (OpenSearch cluster and Orborus count for Shuffle, Temporal and PostgreSQL redundancy for Tracecat), the license tier for each platform and whether ongoing upgrades and testing are covered by a retainer. DeployOpen works from a fixed written scope, so every line of the quote should map to one of those items.
Moving from Shuffle to Tracecat, or back: what transfers and what is rebuilt
This sequence moves security automation between the two platforms while keeping a documented record of what each workflow does. It ends with rebuilt apps and cases, parallel test runs and a trigger cutover that can be rolled back. The reverse direction follows the same steps, with Tracecat AI agents and Temporal-based workflows rebuilt as Shuffle workflows.
Inventory workflows, apps, credentials and triggers
The migration owner lists every active workflow in Shuffle, including the apps each one calls, the credentials it uses and every trigger that starts it, such as webhooks, schedules and alerts from upstream tools. Record the business owner, run frequency and downstream systems for each item, then mark it keep, rebuild or retire. Confirm which inventory or export options your Shuffle version offers, and fill any gaps from the workflow editor. Done when every active workflow has a row in the inventory and a named owner has approved the list.
Secure the SHUFFLE_ENCRYPTION_MODIFIER secret
Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret. The Shuffle configuration docs warn that losing or changing this value breaks all saved app authentications. Keep the value in your secrets store, record where it lives, and do not rotate it until the cutover is complete. Confirm in the docs and in your Shuffle version whether any export carries encrypted credentials or only references to them. Plan to re-enter credentials in Tracecat unless that check shows otherwise. Done when the secret has a tested backup and a named owner, and the credential plan is written down.
Rebuild OpenAPI-based apps as custom actions
Shuffle apps are built from OpenAPI specifications in the App Creator or written with the Shuffle app SDK, and each runs as a versioned Docker container. A developer takes each app's specification and version, then recreates it as a Tracecat custom action or connector. Store the source in Git and sync it through Tracecat's custom action support. Confirm whether your Tracecat version can import an OpenAPI file directly, because that determines how much work each app takes. Done when every app used by a kept workflow has a passing test call in a non-production workspace and its source is under version control.
Map OpenSearch data to PostgreSQL
Shuffle keeps its documents in OpenSearch, while Tracecat stores its data in PostgreSQL. An engineer maps each Shuffle object type that matters, such as workflow definitions, execution history and case records, to a Tracecat table or object, and notes every field with no equivalent. Historical execution data is often better kept as a read-only archive than moved row by row, so decide retention early. Confirm with each vendor which export formats exist before writing the mapping. Done when the mapping is signed off, the archive location and retention rules are documented, and a sample record can be read back from the archive.
Redesign cases and tables in Tracecat
Tracecat provides case management and structured tables, so the cases your team tracks in Shuffle need an explicit design before any data moves. The case owner lists statuses, required fields, assignment rules and links to ticketing or chat tools, then builds the matching case structure and tables in a test workspace. Records that depend on the data mapped in the previous step should be checked against that mapping. Done when a sample of recent cases can be reproduced in Tracecat with the same fields, statuses and owners, and the analysts who work them confirm the layout is usable.
Run both platforms in parallel
Pick low-risk playbooks, such as enrichment, notification and ticket creation, and run them on both platforms against the same test alerts. Shuffle's Orborus workers and Tracecat's Temporal-based workflows process events on their own schedules, so compare outputs, timing and error handling in addition to success. Log each difference, then adjust the Tracecat version until it matches or the difference is accepted with a recorded decision. Done when an agreed set of test alerts produces matching outputs on both platforms and every remaining difference has a documented decision.
Cut over triggers one at a time
Update each upstream source, such as a SIEM alert forwarder, a ticketing webhook or a scheduled job, to point at its Tracecat webhook, one source at a time. Keep the matching Shuffle trigger enabled until its replacement has run successfully in production, and let in-flight Shuffle executions finish before disabling runners. Confirm how your Shuffle deployment, whether single server, Docker Swarm or Kubernetes, handles draining. Done when every trigger points to Tracecat, Shuffle has no active schedules or triggers left, and the rollback path to the original trigger has been tested.
Questions buyers ask before choosing Shuffle or Tracecat
How much effort does it take to run Shuffle or Tracecat with a small team?
Both are self-hosted platforms with several moving parts, so a small team should plan for ongoing operating work, not just an initial install. Shuffle's server side is a frontend, a Go backend and OpenSearch, and its runtime side adds Orborus workers that start app containers for each execution. Tracecat is built on FastAPI, Next.js, Temporal, PostgreSQL, an S3-compatible object store and nsjail for sandboxing. Both need upgrades, backups and monitoring of their data stores. Whether a small team can self-manage depends on whether it already runs container platforms and on how many workflows and executions it expects. Ask each vendor for its current component list and upgrade guidance for your target deployment, then test the operating routine in a non-production environment.
Do we need Kubernetes or Docker skills to run Shuffle or Tracecat?
Docker skills cover the simplest path for both, and Kubernetes skills become necessary for the larger deployments. Shuffle documents a single server with Docker Compose, distributed Docker Swarm, a hybrid model with a local Orborus, and Kubernetes with Helm charts. Tracecat documents Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment. The skill set you need depends on the deployment you pick and on your network constraints, such as whether runners need inbound firewall ports. Confirm the exact requirements for your chosen deployment in each project's current documentation before you commit to a platform.
How long does a migration to Shuffle or Tracecat usually take?
No fixed duration can be stated from the researched facts, so treat any timeline as something to be scoped, not assumed. The main drivers are the number of playbooks and apps to rebuild, the volume of executions, the identity setup, and the number of integrations that need credentials moved and tested. Shuffle apps are built from OpenAPI specifications or written in Python, which affects how much custom integration work you have. Tracecat workflows, case management and custom actions synced from Git add their own mapping effort. For an illustrative example, a team with a few integrations and one identity provider will scope very differently from a team with dozens of custom connectors. Ask the implementation partner for a written scope that lists each workflow, integration and identity step with its own deliverable.
Do AGPL obligations change between Shuffle and Tracecat for internal use?
Both platforms are licensed under AGPL-3.0, so the core license terms are the same, but the paid layers differ. Shuffle states that its code is AGPL-3.0 and that workflows and modular app content are MIT, while Tracecat's code in its enterprise packages and feature gates sits under a separate paid Enterprise Edition license. Whether AGPL obligations trigger for internal use depends on how you modify and make the software available, including over a network, so this is a question for your legal counsel. Read the LICENSE file in each repository, confirm how your own modifications will be shared, and record that decision before deployment.
Which enterprise features do we need for SSO and multi-tenant use?
For Shuffle, SAML single sign-on was added in version 0.9.16 and OpenID Connect in 1.0.0, and per-tenant SSO enforcement is available on-premises and in the cloud. Shuffle also states that limits between its open-source and enterprise editions are actively enforced since v2.1.1, so confirm which tenant and location limits apply to your license. For Tracecat, the documentation describes authentication and single sign-on as enterprise features, and multi-tenant workspace management and Git version control integration are named as Enterprise features. Ask each vendor in writing which license tier includes the SSO protocol, tenant model and limits you need, and whether those features apply to self-hosted installs.
Is a fixed-scope implementation partner worth engaging for this comparison?
A fixed-scope partner is worth considering when your team lacks spare capacity for the platform build, the integrations and the hardening work. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen also offers ongoing support and upgrades as retainers. It does not publish a price list and does not act as an official partner or reseller of Shuffle or Tracecat. Ask for references and a clear split of responsibilities before you engage any partner.
What should we ask for in a written quote for either platform?
A useful quote lists the deployment target, the number of workflows and apps in scope, the identity integrations, the data stores to be run and the acceptance criteria for each deliverable. Ask for the license tier and any enterprise features the design depends on, since those are separate costs from the implementation. Ask which items are one-time, such as the initial build and migration, and which recur, such as retainers for upgrades and support. Also ask how the quote changes if volume, app count or identity scope grows, and what the partner will hand over at the end, including documentation and runbooks. DeployOpen does not publish prices, so a quote follows from the written scope.
How DeployOpen helps you choose, implement or migrate between them
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Shuffle vs Tracecat, we start by working out which platform fits your automation scope, then build and document the chosen one in your environment.
How we scope
- Written scope lists the playbooks, integrations and identity settings to be built for Shuffle or Tracecat.
- We confirm which license edition your required features need before any deployment work begins.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Deployment follows the topology you choose, such as Docker Compose, Swarm, Kubernetes or a hybrid runner.
- We build integrations and workflows, and test them against your own tools and sandbox data.
- Secrets, encryption keys and identity connections are configured and checked as part of the build.
How we hand over
- Handover documentation covers architecture, workflow inventory, key management and backup procedures.
- Your team receives runbooks for adding apps, rotating credentials and recovering workers.
- If you later move between Shuffle and Tracecat, we document the workflow and data mapping needed.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned against the release notes and tested in a staging copy before production.
- Security testing of your automations can be scoped separately, with findings delivered in writing.
