Which open-source SOAR platform fits your team
If your security team must automate response on infrastructure it runs itself, the deciding factors are usually the license terms you can accept for internal use, how much of the platform your team will operate, and whether you need enterprise identity and access features on day one. Shuffle and Tracecat are both AGPL-3.0 security automation platforms with purpose-built SOAR scope, StackStorm is Apache-2.0 with a long record as an event-driven automation engine, and n8n is a general-purpose workflow tool that many teams also evaluate. Start by matching the license to how you will use and distribute the software, then match the operating model to the people you have.
Shuffle suits a SOC or CERT team that wants a SOAR-specific workflow editor, OpenAPI-based app creation and a deployment choice ranging from Docker Compose to Kubernetes. Its AGPL-3.0 code and MIT-licensed workflow and app content are a good fit when you can meet AGPL obligations, and its paid tiers mainly change feature limits, scaling and support, so confirm those limits against your expected action volume. Tracecat fits a team that wants case management, webhook-driven workflows and AI agent tooling in one AGPL-3.0 platform, with several self-hosted paths including air-gapped Kubernetes. Enterprise features such as multi-tenant workspaces, Git version control and single sign-on sit under a separate paid license, so check them before you commit. StackStorm fits engineering-led operations teams that already think in sensors, actions and rules, and want Apache-2.0 licensing with role-based access control in the open-source edition since version 3.4. Its operating burden is higher because it runs MongoDB and RabbitMQ.
n8n is included as a general-purpose option, and it is not OSI open source. Its Sustainable Use License permits use or modification only for internal business purposes or non-commercial or personal use, and features such as SAML and LDAP single sign-on need a paid Business or Enterprise license. If a service provider or product embedding is part of your plan, have counsel review that license before you choose n8n for security automation. Whichever platform you shortlist, confirm the license file and edition features for the exact version you will deploy, and ask your DeployOpen scope to name the identity, secrets and high availability requirements you must meet.
Which SOAR option suits which scenario
This table maps common team situations to the platform that fits best and the license or edition condition that could change the answer. Read each row as a starting point, then confirm the named condition against your own licensing and hosting requirements before shortlisting.
| Scenario | Best fit | Reason and condition |
|---|---|---|
| SOC running alert-driven playbooks | Shuffle | Workflow editor and app creator build integrations from OpenAPI specifications, and Orborus runs executions on hybrid on-premises workers. Confirm that the app run metric in its paid tiers fits your alert volume, since all features are in the open-source edition but limits are enforced. |
| CSIRT managing cases end to end | Tracecat | Case management, structured tables and webhook triggers are built in. Multi-tenant workspaces and Git version control are Enterprise features, and SSO is described as enterprise-only, so confirm those needs before choosing it. |
| Infrastructure or ops team automating remediation | StackStorm | Apache-2.0 licensed, with sensors and actions covering SSH, HTTP and Docker, and about 160 packs on the Exchange. RBAC with LDAP group mapping is in open source since 3.4. Confirm the packs you need, because StackStorm has no built-in case management. |
| Team needing AI agents with tools | Tracecat | Custom AI agents with tools and MCP servers are part of the platform, and the repository lists more than 50 hosted MCP servers. Confirm which agent features sit behind the Enterprise license in your version, and test agent actions in a non-production workspace first. |
| Team already running n8n for other workflows | n8n (general-purpose option) | Reuses existing skills and tooling for non-security work. The Sustainable Use License limits use to internal business or non-commercial purposes, and SAML and LDAP single sign-on need a paid Business or Enterprise license. Confirm the license terms with your legal team before using it for security response. |
| Team needing SSO and OpenID Connect from day one | Shuffle | OpenID Connect arrived in version 1.0.0 and SAML in 0.9.16, both available on-premises. SAML is being deprecated on Shuffle Cloud in favor of OpenID Connect, so self-hosted deployments should confirm their plan. |
| Organization requiring OSI-approved open-source licenses | StackStorm | Apache-2.0 licensing avoids the AGPL-3.0 and Sustainable Use License questions that apply to Shuffle, Tracecat and n8n. Confirm the license obligations of any packs you add from the Exchange. |
How Shuffle, Tracecat and StackStorm are built
Shuffle, Tracecat and StackStorm reach the same goal, running response actions automatically, through very different moving parts, and that difference is what your operations team will live with. Shuffle separates the server from the runtime. The server side is a frontend, a Go backend API on port 5001 and an OpenSearch document database. Orborus, the runtime component, polls the backend for jobs, starts a worker for each workflow execution, and that worker starts app containers. Shuffle documents four deployment patterns, including a hybrid model where a local Orborus needs no inbound firewall ports. For high availability, the configuration docs call for an OpenSearch cluster, shared files over NFS when several backends run, and more than one Orborus node. Confirm with the Shuffle documentation which of these you need for your load, and plan for the SHUFFLE_ENCRYPTION_MODIFIER secret, because losing or changing it breaks every saved app authentication.
Tracecat is a Python FastAPI backend with a Next.js frontend, and it runs workflows on Temporal for durable execution. Its data lives in PostgreSQL and its files in an S3-compatible object store, and it sandboxes actions with nsjail. The operating burden therefore sits in four stateful dependencies, Temporal, PostgreSQL, object storage and the sandbox runtime, each of which needs backup, upgrades and monitoring. Tracecat documents Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart and an air-gapped Kubernetes option, so the deployment choice largely decides how much platform work your team inherits. Ask the vendor how Temporal and nsjail are supported in your chosen topology before you commit.
StackStorm is a set of loosely coupled microservices that communicate over a message bus, with MongoDB for storage and RabbitMQ for messaging. Its model is event driven: sensors are Python plugins that watch external systems and fire triggers, actions perform outbound work, and rules connect triggers to actions or workflows. Content is organized into packs, which are stored as code, so changes can go through the same review path as the rest of your infrastructure. The services scale horizontally, and a Helm chart for an HA cluster on Kubernetes is available as a beta blueprint, which means you should validate it in a test environment before relying on it. Expect StackStorm to demand the most familiarity with message buses and Python-based pack development, and treat the operational skills in your team as a deciding factor.
Capability comparison across the open-source SOAR options
This table compares Shuffle, Tracecat and StackStorm on license, release, data store, deployment, SSO, case management, integrations, high availability and extensibility. Cells marked for vendor confirmation cover areas the published sources do not settle, so check them before shortlisting. n8n, the general-purpose option, is discussed separately on this page because its Sustainable Use License and paid edition gates differ from these three.
| Capability | Shuffle | Tracecat | StackStorm |
|---|---|---|---|
| License | AGPL-3.0 for code. Workflows and modular app content are MIT. | AGPL-3.0 for core. Code in packages/tracecat-ee and enterprise feature gates is under a separate paid Enterprise Edition license. | Apache-2.0 |
| Latest release and date | 2.3.0, published September 28, 2026 | 1.2.0, released October 16, 2026 | v3.9.0, published January 12, 2026. Confirm the current release with the vendor before planning. |
| Data store | OpenSearch for documents and data | PostgreSQL for data and an S3-compatible object store | MongoDB for storage and RabbitMQ for messaging |
| Deployment options | Single server with Docker Compose, distributed Docker Swarm, hybrid with Shuffle Cloud and local Orborus, and Kubernetes with Helm charts | Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, and air-gapped Kubernetes | Confirm supported deployment methods with the vendor. Published sources describe a Kubernetes HA blueprint in beta. |
| SSO support | SAML since 0.9.16 and OpenID Connect since 1.0.0, with per-tenant enforcement. SAML is being deprecated on Shuffle Cloud. | Authentication and single sign-on are enterprise features. Confirm which protocols the edition you need supports. | Confirm SSO protocols with the vendor. Role assignment from LDAP group membership is available in open source since version 3.4. |
| Case management | Confirm whether case handling is a built-in module or a workflow pattern with the vendor. | Case management is documented as a built-in feature alongside structured tables and webhook triggers. | Confirm with the vendor. Published sources describe event-driven actions and remediation, not a case model. |
| Prebuilt integrations | Apps built from OpenAPI specifications or the Python SDK. Confirm the size of the current app catalog. | More than 100 prebuilt connectors and more than 50 hosted MCP servers, per the repository | About 160 integration packs with more than 6,000 actions, per the repository description |
| Kubernetes or HA path | Helm charts on Kubernetes. HA guidance includes an OpenSearch cluster, Memcached, NFS for shared files and more than one Orborus node. | Helm chart on Kubernetes and an air-gapped Kubernetes option. Confirm the HA reference architecture with the vendor. | Microservices over a message bus that scale horizontally. The HA Helm chart is a beta blueprint. |
| Extensibility and audit trail | Apps run as versioned Docker containers. Confirm audit log scope with the vendor. | Custom actions synced from Git, custom AI agents with tools, and nsjail sandboxing. Confirm audit trail details with the vendor. | Packs stored as code. Audit trail of every action execution can ship to LogStash, Splunk, statsd or syslog. |
Each option in brief, with its license
Four platforms reach the shortlist for open-source SOAR, and their license terms differ more than their feature lists. Read each card for the license condition that decides whether a platform fits your organization, then check the license text against how you plan to run and modify it.
Shuffle under AGPL-3.0
Shuffle is a SOAR platform started in mid-2019 for the CERT and SIRT community. Its code is licensed under AGPL-3.0, while workflows and modular app content are MIT, so teams can separate what they share from their own automation content. The AGPL matters if you modify Shuffle and offer it to users over a network, because those changes carry source obligations. Confirm the app-run metering in the pricing article before you plan volumes, since it counts executed actions rather than triggers or skipped steps.
Tracecat with an enterprise carve-out
Tracecat is a security automation platform for teams and AI agents, licensed under AGPL-3.0. Code in packages/tracecat-ee and the enterprise feature gates falls under a separate paid Enterprise Edition license. Multi-tenant workspace management, Git version control integration and authentication features are listed as enterprise features, so check whether those capabilities are in your plan before you design around them. This split matters most for teams that need tenant separation or SSO from day one.
StackStorm under Apache-2.0
StackStorm is an integration and automation platform that acts on events through sensors, actions and rules. It is licensed under Apache-2.0, and role-based access control, once an enterprise feature, is available in the open-source release since version 3.4, including role assignment from LDAP group membership. The permissive license suits teams that want to embed or modify the code without copyleft obligations. Its content lives in packs stored as code, so plan for ongoing pack review and maintenance by your own engineers.
n8n under the Sustainable Use License
n8n is a general-purpose automation tool, distributed under the Sustainable Use License, which is not an OSI-approved license. It permits use or modification for internal business purposes or non-commercial use, and files marked .ee fall under the separate n8n Enterprise License. Its free Community edition lacks SAML and LDAP single sign-on, multi-main mode and log streaming, which need a paid Business or Enterprise license. Choose it for general automation with an internal-use scope, and have counsel review the terms if you plan to offer it to customers.
What licensing and paid editions change for your team
Shuffle states that all features are available in its 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 the boundary is set by those limits rather than by a separate feature list. Its licensing is priced on app runs, which counts actions that actually execute in a workflow. Triggers and skipped actions are not counted, and users, apps and workflows are described as unlimited.
- Feature parity claim: Shuffle describes all features as available in the open-source edition, so ask which limits apply to your planned volume.
- Limits and scaling: Paid tiers differ in feature limits, scaling and support, so confirm the exact numbers for your deployment.
- App-run metric: Only executed actions count, so estimate your run volume from real playbooks rather than from alert counts.
- Enforced limits: Because limits are enforced since 2.1.1, test your workflows against the open-source build before assuming they fit.
- Unlimited users and workflows: Confirm in writing that this applies to your tier.
Before committing, ask the vendor to confirm in writing which limits, support terms and run allowances apply to your environment.
Tracecat is licensed under AGPL-3.0, but code in its enterprise package and enterprise feature gates falls under a separate paid Enterprise Edition license. The repository and documentation name multi-tenant workspace management and Git version control integration as Enterprise features. The documentation also describes authentication and single sign-on as enterprise features. A team that needs central identity sign-on or separate workspaces for business units should treat these as paid requirements, not as open-source defaults.
- Single sign-on: Authentication and SSO are described as enterprise features, so plan identity integration around the paid license.
- Multi-tenant workspaces: Separate workspace management for multiple tenants is an Enterprise feature.
- Git version control: Git integration is named as Enterprise, though custom actions synced from Git are described in the core documentation.
- AGPL obligations: The open-source core is AGPL-3.0, so review what your modifications and hosting imply with counsel.
- Enterprise license terms: Confirm the scope, term and support of the Enterprise license with the vendor.
Before committing, ask the vendor which features in your design require the Enterprise license and get the commercial terms in writing.
n8n runs as the free Community edition without a license key. Its Sustainable Use License allows use or modification for internal business purposes or non-commercial use, and files marked .ee fall under a separate enterprise license. Several controls that security and platform teams often expect are paid features. According to the n8n documentation, SAML and LDAP single sign-on, multi-main mode, environments, external secrets, log streaming, Git version control and projects need a paid Business or Enterprise license.
- SAML and LDAP sign-on: Both need a Business or Enterprise license, so budget for identity integration as a paid item.
- Multi-main mode: High availability through multiple main instances requires a paid license.
- External secrets and log streaming: Secret stores and log forwarding are paid features, which affects how you meet audit requirements.
- Environments and projects: Separating development from production and grouping workflows need a paid license.
- License scope: The Sustainable Use License is not OSI-approved, so confirm your internal use case with counsel.
Before committing, check the current n8n edition comparison and confirm in writing which features your design depends on.
StackStorm is licensed under Apache-2.0. Role-based access control, which was once part of an enterprise edition, was donated to the Linux Foundation and is available in open source since version 3.4. Role assignment from LDAP group membership is included. This means access control is not a paid gate for StackStorm the way it is for some other platforms, but teams should still verify how RBAC fits their identity model and audit needs for their chosen version.
- Open-source RBAC: Role-based access control is available in open source since version 3.4.
- LDAP group roles: Roles can be assigned from LDAP group membership.
- Apache-2.0 license: The license is permissive, so commercial use does not depend on a paid tier for core features.
- Support is separate: Confirm whether vendor or commercial support is available and what it covers, since the license does not include it.
- Version pinning: Check the release you deploy, such as v3.9.0 published on January 12, 2026, against the RBAC documentation.
Before committing, confirm in writing which StackStorm version and support arrangement you will run and how RBAC maps to your audit requirements.
How to choose and pilot a SOAR platform
This sequence moves a team from a list of response goals to a tested pilot on one deployment target. Each step produces a written artifact that narrows Shuffle, Tracecat, StackStorm and n8n to the one that fits the team's systems, licensing needs and case handling.
Define the response use cases and systems
The SOC or detection engineering lead writes down the five to ten response actions the team needs most, such as enriching an alert, disabling a compromised account or blocking an indicator. For each action, list every system it touches, including the SIEM, identity provider, EDR, ticketing tool and cloud accounts, and note whether the action needs a human approval step. The output is a use case register that names the systems and the owner of each one.
Check license and edition fit
The security architect and procurement lead compare each required feature against the license and edition terms of each candidate. Shuffle is AGPL-3.0 with app run limits on its paid tiers, Tracecat keeps multi-tenant workspaces and Git version control in its Enterprise Edition, StackStorm is Apache-2.0 with RBAC in open source since version 3.4, and n8n is under the Sustainable Use License, with SAML and LDAP single sign-on and audit-related features needing a paid Business or Enterprise license. Confirm with each vendor which SSO protocols and audit log exports are included in the edition you plan to run. The output is a feature-by-edition table signed off by security and legal.
Decide case handling requirements
The incident response manager decides whether the platform must hold cases, tasks and evidence, or whether cases will stay in a separate system such as a dedicated case management tool. Tracecat documents case management and structured tables, while Shuffle and StackStorm are typically used to execute actions and hand results to an external case tool, so confirm each platform's native case features against the register from the first step. The output is a decision on where cases live and which platform writes to them.
Test integration coverage for top use cases
The automation engineer maps each top use case to an existing integration before any build work starts. Shuffle builds apps from OpenAPI specifications in its App Creator or from Python with its SDK, StackStorm uses sensors and actions grouped in packs from its Exchange, Tracecat lists more than 100 prebuilt connectors plus custom actions synced from Git, and n8n relies on its node library. Mark each system as covered, covered with custom work, or missing. The output is a coverage matrix that shows how much custom code each platform would need.
Confirm security and secrets handling
The platform owner reviews how each candidate stores credentials used by its integrations. Shuffle encrypts saved app credentials with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing that value breaks saved authentications, so the team must plan key custody and backup before go-live. Confirm equivalent controls for the other candidates with the vendor. The output is a documented secrets design that the security team accepts.
Select a deployment target and run the pilot
The platform engineering lead chooses one deployment target that matches the team's infrastructure, such as Docker Compose on a single host, Kubernetes with Helm, or a hybrid setup with a local worker. Shuffle documents a hybrid option where a local Orborus needs no inbound firewall ports, and Tracecat documents an air-gapped Kubernetes option. Build the top three use cases in a non-production environment with real-looking but non-sensitive test alerts, and record run results, failures and approval steps. The output is a pilot report with a go or no-go recommendation, the chosen platform and the open items that must close before production.
What running each platform takes from your team
Shuffle, Tracecat and StackStorm each put a different set of stateful services on your team's plate, so start by listing those stores and who backs them up. Shuffle's server side needs its Go backend, frontend and an OpenSearch document database. The Shuffle configuration docs recommend an OpenSearch cluster for high availability, optional Memcached for a shared cache, and NFS for shared files when several backends run, plus more than one Orborus node so workflows keep running if one fails. Tracecat runs on Temporal for durable workflow execution, PostgreSQL for data and an S3-compatible object store. StackStorm uses MongoDB for storage and RabbitMQ for messaging, and its Kubernetes HA chart is a beta blueprint, so confirm with the StackStorm project how far that chart is supported for production before you plan around it.
Secrets handling is where Shuffle needs the most care. Shuffle encrypts saved app credentials and API keys in OpenSearch with AES-256 using the SHUFFLE_ENCRYPTION_MODIFIER value. The Shuffle docs warn that losing or changing that secret breaks every saved app authentication, so store it in your secrets manager, include it in your backup runbook, and test a restore that includes it. Ask Shuffle how to rotate the modifier without re-entering every credential. Tracecat's sandboxing via nsjail and StackStorm's pack configuration each raise their own questions about where credentials sit, and those answers belong in the vendor conversation before go-live.
Upgrade cadence is the recurring cost that most teams underestimate. Shuffle 2.3.0 was published on September 28, 2026, Tracecat 1.2.0 on October 16, 2026, and StackStorm v3.9.0 on January 12, 2026, so the three projects are on very different release rhythms. Shuffle's docs suggest the latest Docker tag for stable use and the nightly tag only for experiments, which means you should pin versions in your own change process. Ask each vendor for its upgrade path, whether database migrations are reversible, its support window for older releases, and how custom apps, packs or actions survive a version change. Those answers, not the release dates alone, determine how much of your team's time each upgrade consumes.
Common questions about open-source SOAR cost and effort
What actually drives the cost of running Shuffle, Tracecat or StackStorm?
The software license is only one line item. For self-hosted SOAR, the cost is driven by the infrastructure you run, the people who build and maintain workflows and integrations, and any paid edition you need for SSO, multi-tenancy or support. Shuffle's paid tiers differ in feature limits, scaling and support, and its pricing article describes a single metric, app runs, meaning actions that actually execute in a workflow, while users, apps and workflows are unlimited. Tracecat's Enterprise features include multi-tenant workspace management and Git version control integration. StackStorm's open source edition includes RBAC since version 3.4. Ask each vendor for a written list of which features sit behind a paid tier, and ask how usage is metered before you model the run cost.
Can a small security team run a self-hosted SOAR platform on its own?
Yes, for a team with someone who can operate containers, a database and a message bus, and who is comfortable writing or reviewing automation code. Each platform has a different operating footprint. Shuffle's documented deployments range from a single server with Docker Compose to Kubernetes with Helm charts, and its high availability guidance calls for an OpenSearch cluster and more than one Orborus node. Tracecat documents Docker Compose on a single host and a Kubernetes Helm chart, and its stack includes Temporal, PostgreSQL and an S3-compatible store. StackStorm uses MongoDB and RabbitMQ, and its Kubernetes HA chart is a beta blueprint. A team without platform engineering capacity should either size that gap honestly or scope outside help for the first build.
How long does a SOAR pilot take, and what does it depend on?
No duration is supplied for these platforms, so treat any figure from a vendor or a consultant as a claim to test. A pilot's length depends on how many playbooks you want to prove, how many of your tools need new or customized integrations, whether identity and secrets are wired in, and whether you run it in a cloud account, a data center or an air-gapped network. Shuffle builds integrations from OpenAPI specifications in its App Creator, while StackStorm uses sensors and actions packaged as packs. Tracecat supports custom actions synced from Git. Ask any implementation partner for a written scope with named deliverables and milestones before work starts, and confirm which of your target integrations already exist as maintained apps or packs.
What skills does the work need from the team?
Plan for three skill sets: platform operations, integration engineering and playbook design. Platform operations covers containers, the backend database or document store, message brokers and backups. Integration engineering covers API authentication, rate limits and writing or adapting connectors. Playbook design covers the incident logic itself, including when automation may act without a human. Shuffle apps can be written in Python with the app SDK or generated from OpenAPI, and StackStorm packs are code stored in version control. Tracecat's custom AI agents and MCP tools add another area to review. Before hiring, map your existing staff against these three areas and decide where the gap will be filled.
Which license terms change the cost of using each platform?
License terms matter most when you plan to distribute, host for other organizations, or modify the code and keep it private. Shuffle's code is AGPL-3.0, while its workflows and modular app content are MIT. Tracecat's core is AGPL-3.0, but code in its enterprise packages and feature gates is under a separate paid license. StackStorm is Apache-2.0. n8n is not OSI open source: its Sustainable Use License limits use to internal business, non-commercial or personal purposes, and its .ee files fall under a separate enterprise license. Features such as SAML and LDAP single sign-on, multi-main mode and external secrets need a paid n8n Business or Enterprise license. Have counsel review the exact terms against how you intend to deploy and share the software.
Can playbooks move from one SOAR platform to another?
Usually not directly. Each platform stores workflows in its own format, and the logic, connectors and credentials do not transfer one to one. Shuffle workflows live in its OpenSearch backend, Tracecat workflows run on Temporal, and StackStorm content is stored as code in packs and rules. The portable parts are the decision logic, the list of steps, the API calls and the data mappings, which you can document in plain language before rebuilding. Keep credentials out of the migration path, because Shuffle encrypts saved app credentials with a secret that must be preserved, and each platform needs its own authentication setup. Export your playbooks to version-controlled documentation now, so that any later move starts from a clear specification.
What happens to cost and risk if the platform is hard to change later?
Switching cost grows with the number of playbooks, custom integrations and stored credentials. Each platform creates its own lock-in: Shuffle's saved app authentications depend on the SHUFFLE_ENCRYPTION_MODIFIER secret, and losing or changing it breaks them. Tracecat and StackStorm each tie automation to their own runtime and data stores. Reduce that risk by keeping integration code in your own repository, recording the secret and key management procedures, and writing a runbook for backup and restore. Ask any implementation partner to deliver the playbooks as documented code, along with the configuration needed to recreate the environment, so the cost of a later migration stays visible and bounded.
Does DeployOpen handle SOAR licensing or certification for us?
No. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not set your license position, and it does not issue audit reports, attestations or certifications. For license interpretation, ask your legal team or the vendor. For compliance evidence, ask your independent auditor or certification body. DeployOpen can prepare the systems, controls and evidence those assessments need, and it does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes SOAR selection and implementation
DeployOpen treats SOAR selection and implementation as fixed-scope work agreed in writing before any build starts. DeployOpen does not favor Shuffle, Tracecat, StackStorm or n8n, and it does not publish a price list, so a quote follows from the written scope rather than from a platform preference. The scope document should name the platform decision itself, the workflows to be automated, the case and alert sources, the target deployment (single host, Kubernetes, or an air-gapped network) and the identity model, because each of those changes the work.
Within that scope, the work usually covers platform planning, integration with the client's SIEM, ticketing and identity systems, hardening, backup and restore of the automation data stores, documentation of workflows and runbooks, and handover. Ask for each item as a separate deliverable with its own acceptance criteria. For backup, confirm which stores hold credentials and execution history for your chosen platform, and who holds the encryption secret, since losing a key can break every saved integration. Ongoing upgrades, monitoring and continuous testing are available as support retainers, which recur and are priced separately from the one-time build.
Ask for a quote that lists who does what, what is one-time and what recurs, and which assumptions would change the price, such as the number of integrations to build, the number of environments, or whether the platform's paid edition is required for single sign-on or audit features. Confirm licensing terms directly with each vendor, because DeployOpen does not set or resell them. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications, so ask the auditor which automation logs they will need before the scope is signed.
