FortiSOAR alternative: when Tracecat fits and when FortiSOAR stays
Tracecat suits a SOC that wants one self-hosted tool for cases, workflows and AI agents, and its core is licensed under AGPL-3.0. FortiSOAR suits teams that depend on Fortinet's vendor ecosystem, its support terms and integrations across the rest of their Fortinet estate. The decision turns on three questions. The first is whether you need features in Tracecat's Enterprise Edition. Single sign-on and authentication, multi-tenant workspace management and Git version control are all listed as enterprise features, and code in packages/tracecat-ee plus the enterprise feature gates sits under a separate paid license. If every analyst must sign in through your identity provider, or an MSSP needs separate client workspaces, price the Enterprise Edition before you commit. If you can live with the core authentication options, confirm exactly what those are in the current documentation.
The second question is how much operational complexity your team will accept. Tracecat uses Temporal for durable workflow execution, with PostgreSQL for data, an S3-compatible object store and nsjail for sandboxing, so a production install is a multi-service system rather than a single application. Deployment options range from Docker Compose on a single host to Kubernetes through a Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access. A team that already operates Temporal, PostgreSQL and Kubernetes can absorb this load. A smaller SOC without platform engineers should ask who will handle upgrades, backups and Temporal monitoring, and whether the vendor or your implementation partner covers those tasks in writing. The Tracecat documentation lists the supported component versions, so check them before sizing hardware.
The third question is how much playbook logic must move. A long-running FortiSOAR estate holds playbooks, connector configuration and case history that must be rewritten as Tracecat workflows, actions and tables, not copied across unchanged. Custom actions can be synced from Git, which suits teams that want versioned automation, but Git version control is itself an Enterprise feature, so plan for that cost. Keep FortiSOAR where Fortinet-specific integrations, vendor support terms or FortiGuard-linked licensing are central to daily operations and no migration effort is funded. Choose Tracecat when most of your automation is custom, when case handling is the main daily tool, and when you can run a pilot in a non-production cluster. A useful test is to run one high-volume playbook through both tools side by side and compare outcomes, run time and the effort needed to maintain it.
Which SOC scenarios favor each platform
This table matches common SOC situations to the platform that fits them better, along with the condition that makes each advantage matter. Read each row against your own environment and requirements. Where a row points to Tracecat, confirm whether the Enterprise Edition license covers the feature you need, since multi-tenant workspaces, SSO and Git version control integration sit in the paid tier.
| Scenario | Better fit and why | When Enterprise Edition matters |
|---|---|---|
| One SOC wants cases and automation in one tool | Tracecat, when one team needs case management, structured tables and workflows on one self-hosted platform. Condition: a single analyst team with no separate MSSP or tenancy needs. | Case management and workflows are listed as core features. Confirm the license scope with Tracecat before deployment. |
| Strict data residency on your own Kubernetes cluster | Tracecat, which documents a Kubernetes Helm chart and stores data in PostgreSQL and an S3-compatible store you operate. Condition: case data must stay inside your cluster. | Confirm with Tracecat whether any Helm chart or cluster feature requires a license. Check FortiSOAR's own on-premises cluster support with Fortinet. |
| Fully air-gapped network | Tracecat, which documents an air-gapped Kubernetes deployment with no runtime internet access. Condition: you must mirror images and plan offline updates. | Confirm whether air-gapped installs and offline updates need the Enterprise Edition license. |
| MSSP running many isolated customer workspaces | FortiSOAR, if its multi-tenant model matches your isolation and billing needs. Condition: separate customer environments are a core service requirement. Confirm details with Fortinet. | Multi-tenant workspace management is an Enterprise feature in Tracecat, so it is required for this scenario. |
| Team depends on FortiSOAR connectors and vendor support | FortiSOAR, for existing connector coverage and vendor-backed support. Condition: your playbooks rely on Fortinet modules that are hard to rebuild quickly. | Tracecat lists more than 100 prebuilt connectors. Check each Fortinet module you use against them. |
| Team wants custom actions managed in Git | Tracecat, which documents custom actions synced from Git. Condition: your analysts or engineers want code reviewed and versioned like other software. | Git version control integration is listed as an Enterprise feature. Confirm which Git sync option your plan includes. |
| Central single sign-on for all analysts | FortiSOAR, if its built-in authentication meets your identity provider requirements. Confirm the supported protocols with Fortinet. | Authentication and single sign-on are described as Enterprise features in Tracecat. |
| Analysts building AI agents with tools and MCP servers | Tracecat, which documents custom AI agents with tools and MCP servers and lists more than 50 hosted MCP servers. Condition: agent-driven triage is part of the workflow. | Confirm with Tracecat which agent features and MCP integrations require the Enterprise license. |
Which Tracecat capabilities sit behind the Enterprise license
The first decision for any SOC considering Tracecat is that its core is licensed under AGPL-3.0, while code in the enterprise package and the enterprise feature gates falls under a separate paid Enterprise Edition license. The repository lists multi-tenant workspace management and Git version control integration as Enterprise features, and the Tracecat documentation describes authentication and single sign-on as enterprise capabilities. Those three areas decide whether a self-hosted deployment can serve several customers from one installation, whether changes are reviewed through Git, and whether staff sign in through a corporate identity provider.
The boundary around Git needs the closest check. The repository also presents custom actions synced from Git as a core feature, so the Git story is split: some Git capability appears free and some appears paid. Before you design your change-management process around Git-synced actions, ask Tracecat to state in writing which Git behavior is in the community edition and which requires the Enterprise license, including whether version control integration covers only sync or also workspace-level review. Confirm this against a test instance running the version you plan to deploy, because feature gates can change between releases.
The impact differs by buyer. An MSSP that needs separate client workspaces should treat multi-tenant workspace management as a go or no-go item and price it before selecting Tracecat. A regulated enterprise with a SAML identity provider should verify that SSO is included in the license it will actually buy, since access control and audit of administrator logins usually depend on it. A single-team SOC with one tenant and local accounts may never hit these gates, but should still confirm that its planned Git workflow is free. In every case, request the current edition matrix in writing, naming each feature in this section, and attach it to the scope so the deployment design matches the license you hold.
How Tracecat compares as a FortiSOAR alternative on features
This table compares FortiSOAR and Tracecat across the capabilities a SOC usually weighs when choosing a SOAR platform. Tracecat cells come from its repository and documentation, while FortiSOAR cells describe general capability, so confirm edition-specific details with Fortinet. The main takeaway is that Tracecat's SSO and multi-tenant workspaces sit in its paid Enterprise Edition, which should be priced into any comparison.
| Capability | FortiSOAR (commercial) | Tracecat (open source) |
|---|---|---|
| Workflow building and webhook triggers | Visual playbook designer for automated response steps. Confirm trigger types with Fortinet for your version. | Workflow automation with webhook triggers and custom actions synced from Git. |
| Connector coverage | Connector catalog delivered through modules and packs. Confirm the current list and update process with Fortinet. | More than 100 prebuilt connectors, according to the Tracecat repository. Check each one against your tools. |
| Case management | Incident and case records with playbook-driven handling. Confirm record types and customization limits with Fortinet. | Case management included in the platform. Confirm how it maps to your incident process. |
| Structured data tables | Records and modules hold structured incident data. Confirm table-style features with Fortinet. | Structured tables available for storing workflow and case data alongside automation. |
| AI agents, tools and MCP servers | AI-assisted features depend on the edition and version. Confirm agent and tool support with Fortinet. | Custom AI agents with tools and MCP servers, plus more than 50 hosted MCP servers, according to the repository. |
| Deployment options | Commercial deployment options depend on licensing. Confirm supported on-premises and air-gapped models with Fortinet. | Docker Compose on a single host, AWS ECS Fargate via Terraform, Kubernetes via Helm, and air-gapped Kubernetes. |
| Sandboxed execution | Execution isolation is handled by the vendor product. Confirm the sandboxing model with Fortinet. | Code runs in nsjail sandboxes, and workflows run on Temporal for durable execution. |
| SSO and multi-tenancy | Available in commercial editions, depending on your license. Confirm SSO and tenant options with Fortinet. | Authentication and SSO and multi-tenant workspaces are Enterprise Edition features under a paid license. |
| Vendor support | Support is covered by your Fortinet subscription. Confirm the service levels in your contract. | AGPL-3.0 core with a separate paid Enterprise Edition. Confirm support terms with Tracecat. |
What runs under Tracecat and what that means for operations
Tracecat is not a single binary. Its case management, workflows and AI agents depend on several cooperating components, and each one adds something an operator must patch, back up and understand. Before you compare Tracecat with FortiSOAR on features, map these components to your own support model.
FastAPI backend
The FastAPI backend is the Python service that exposes Tracecat's API and drives its cases, tables and workflow requests. For a SOC, it is the layer analysts and integrations reach first, so its availability and authentication settings affect every alert path. It adds one application service to patch and monitor, along with its Python dependencies. Your team needs Python packaging, API troubleshooting and familiarity with reading service logs. Confirm the supported Python and dependency update path in the Tracecat documentation before you commit to a patch cadence.
Next.js frontend
The Next.js frontend is the web interface where analysts build workflows, work cases and manage agents. Because it is a separate application from the API, it needs its own build, versioning and upgrade testing, and a browser-facing deployment behind your ingress or reverse proxy. Teams moving from FortiSOAR's single web console should plan for this split, since a frontend and backend can drift if they are not upgraded together. Skills needed include Node.js build tooling, container image handling and TLS and reverse proxy configuration.
Temporal for durable execution
Temporal runs workflow executions durably, so a playbook step that is interrupted can resume rather than being lost during a restart. This matters for enrichment and containment steps that call external systems and may run for a long time. Temporal is also a stateful service with its own database and history retention, which means extra storage, backup and version compatibility work. Your operations team needs to understand Temporal's worker model and how to diagnose stuck or retried workflows. Ask Tracecat how Temporal is deployed in each supported topology.
PostgreSQL for case data
PostgreSQL holds the relational data behind Tracecat, including the records that matter most in an investigation: cases, tables and workflow metadata. Backup and restore for this database is the recovery point for your incident record, so it belongs in your existing database standards with tested restores. If you already run managed or hardened PostgreSQL, you may reuse that practice. Confirm with Tracecat which PostgreSQL versions it supports and how schema migrations are applied during upgrades, since a failed migration can block the whole platform.
S3-compatible object store
The S3-compatible object store keeps larger artifacts that should not sit in the database, such as files attached to cases and stored payloads. It adds a storage service with its own credentials, lifecycle rules and capacity planning, separate from the database backup. Evidence handling needs particular care: confirm where attachments land, how they are encrypted at rest, and whether deletions in the case tool propagate to the bucket. Operations staff need object storage administration skills and an understanding of bucket policies. Choose a store your organization already backs up and monitors.
nsjail for sandboxing
nsjail isolates the code that runs inside Tracecat's actions, so custom Python steps do not have free access to the host. For a SOC that runs custom enrichment or lets teams sync actions from Git, this is a security boundary you must understand and test. It is a component you must keep current and verify on your host kernel and container runtime, since sandbox behavior depends on the environment. Operators need Linux namespace concepts and the ability to review sandbox configuration. Ask Tracecat for its documented threat model for custom actions before you allow untrusted code.
Where Tracecat can run and what each hosting model means for data control
Docker Compose on a single host is the simplest deployment model in the Tracecat documentation. The API, frontend, workflow engine, PostgreSQL, object storage and sandboxing components all run on one machine that your team controls. Cases, tables, workflow history and stored credentials sit on that host and its attached volumes, which makes the data location easy to describe to an assessor. The cost of this simplicity is that your team owns availability, backups and every upgrade.
- Data location: all records, attachments and workflow state sit on the disks and volumes you choose, so encryption at rest and backup targets are your decisions.
- Patching: your team patches the host operating system, the container runtime and each image version the stack pulls.
- Updates and images: you pull new image versions from a registry you approve, then restart the stack with Compose.
- Evidence you produce: host hardening baselines, access logs for the host and the Tracecat login, and recorded restore tests from your backups.
Confirm whether one host meets your availability expectations, because a single host failure stops all case handling until it is restored.
The AWS ECS Fargate option deploys Tracecat through Terraform into an AWS account you own. Your team decides the account, region, network layout and encryption keys in the Terraform configuration, so data residency is set by your infrastructure code rather than by a vendor-hosted tenant. AWS operates the underlying compute for Fargate, but the container images, module versions and AWS configuration remain your responsibility. Review the Terraform module before the first apply to confirm which data stores it provisions and where they sit.
- Data location: the region, VPC and data stores are defined by your Terraform variables, so residency follows your account settings.
- Patching: AWS manages the Fargate host layer, while your team patches container images and updates the Terraform module versions.
- Updates and images: you copy image versions into a registry in your account, update the module inputs, then run Terraform plan and apply.
- Evidence you produce: IAM role definitions, key management configuration, CloudTrail and VPC flow log retention, and the Terraform state history.
Check how Terraform state is stored and who can read it, since state files can contain sensitive configuration values.
The Helm chart deploys Tracecat into a Kubernetes cluster that your platform team operates. Data stays in the cluster's storage classes and the databases and object stores you connect to it, so residency depends on where the cluster runs, whether that is a cloud provider, a data center or a private cloud. Platform engineering owns the control plane, nodes, ingress and network policy, while the security team usually owns the secrets and access model. Tracecat's sandboxed execution uses nsjail, so confirm with the chart documentation which privileges the workers need before you set your pod security standard.
- Data location: persistent volumes, object storage buckets and database instances live in the locations your storage classes and connection settings point to.
- Patching: your team patches nodes, the Kubernetes version and the chart version, and it must schedule rolling upgrades.
- Updates and images: you upgrade the Helm release to a chosen chart version and override image tags from a registry you control.
- Evidence you produce: RBAC bindings, network policies, pod security configuration, secret management records and cluster audit logs.
Confirm which namespaces hold secrets and who can read them, because the chart's default configuration may not match your access model.
The air-gapped Kubernetes deployment runs on a cluster with no runtime internet access. Case data, workflow history and credentials stay inside your closed network because the platform never needs to call an outside service during operation. Your team must bring every image, chart and dependency across the boundary through an approved transfer process, then host them in an internal registry. Connectors that call external SaaS APIs will only work if your network allows those connections, so confirm each integration's egress path before go-live. DeployOpen can plan, install, document and prepare the systems and evidence for an assessment, but independent auditors and certification bodies issue any audit report or certification.
- Data location: case records, attachments and logs remain on internal storage, and no runtime telemetry leaves the network.
- Patching: your team mirrors each security fix into the internal registry and rebuilds the approved bundle for every release.
- Updates and images: each update passes a scan and a signed checksum check on the import side before it reaches the cluster.
- Evidence you produce: transfer logs, artifact checksums, change approvals for each import and records of the restore tests.
For a closed network, ask Fortinet to confirm FortiSOAR's on-premises entitlement and licensing requirements, and compare those obligations with the offline update and licensing steps your team would own under Tracecat.
What drives the cost of FortiSOAR and self-hosted Tracecat
FortiSOAR and self-hosted Tracecat shift cost in different places. One is a vendor subscription sized by users and nodes, the other is open-source software where the expense moves to infrastructure, staff and content upkeep. Ask for each component to be priced separately so the comparison is like for like.
Software license or subscription
FortiSOAR is licensed and recurring, so its cost depends on the edition, user or node basis and whether high availability or scale-out nodes are included. Tracecat's core is licensed under AGPL-3.0, so the self-hosted core carries no license fee, but any paid Enterprise Edition features are a separate agreement. Ask the vendor for edition, user or node basis, support terms and renewal uplift in writing.
Tracecat Enterprise Edition features
If you need single sign-on or multi-tenant workspace management, those are enterprise features under a separate paid license, so this is a recurring cost that the open-source core does not cover. Confirm which authentication methods, workspace counts and Git version control features are in scope before you commit. Ask whether the license covers upgrades and support, and what happens to those features if the license lapses.
Infrastructure for hosts and storage
Self-hosted Tracecat runs on Docker Compose, Kubernetes, AWS ECS Fargate or an air-gapped Kubernetes cluster, and it depends on PostgreSQL, an S3-compatible object store and Temporal. These are recurring compute, storage and backup costs that grow with alert volume, retention and high availability requirements. Ask your team to size each component for your environment, because the FortiSOAR sizing guidance does not transfer to Tracecat.
Staff time to operate Temporal and PostgreSQL
Operating Temporal for durable workflow execution and PostgreSQL for data is an ongoing internal task covering upgrades, backups, failover testing and capacity planning. This labor recurs every month, and it is the largest cost that differs from a managed FortiSOAR deployment. Estimate it in hours per month against the SOC engineers who will own it, and confirm whether your platform team already runs these services.
Migration and rebuild effort
Moving FortiSOAR playbooks, connector settings and case records into Tracecat workflows, cases and tables is largely one-time work. The effort depends on how many playbooks use FortiSOAR modules, how many Jinja expressions must be rewritten and how much historical case data you keep. Request a written scope that lists playbooks, record types and alert sources, and agree the cutover and parallel run period.
Ongoing content maintenance
Connectors and custom actions in Tracecat must be maintained as APIs change, and custom actions synced from Git need review and versioning. This is a recurring cost that falls to your engineers or a retained support partner, and it grows with the number of integrations in use. Ask who owns each action, how changes are tested before release and whether the scope includes ongoing support.
What a move from FortiSOAR to Tracecat involves
The sequence moves FortiSOAR playbooks, connectors and case data into Tracecat in a controlled order, so each step ends with a tested, working piece on the new platform before the old one is switched off.
Export and inventory the FortiSOAR configuration
Your team exports the FortiSOAR configuration with the Configuration Export wizard and builds a written inventory of every playbook, module, connector and scheduled job. Record which playbooks run in production, how often each one fires, and which alert sources trigger it. The step is done when the inventory has an owner for each item and the team agrees which playbooks are in scope for the move. Confirm with your FortiSOAR administrator which export options capture your custom content, since the exact contents depend on your version and setup.
Map modules and record types to Tracecat
Map each FortiSOAR module and record type to a Tracecat case, a structured table or a workflow input. Decide which fields must exist on the new side for analysts to work a case, and which historical fields only need to be searchable. Your SOC leads and the people who own each playbook should sign off the mapping. The step is complete when every record type in scope has a documented target and a named owner for any field that does not map cleanly.
Stand up Tracecat in the chosen deployment model
Deploy Tracecat in your environment using the model your security and infrastructure teams selected, such as Docker Compose on a single host, Kubernetes with the Helm chart, or the air-gapped Kubernetes deployment if the network has no runtime internet access. Configure the backing services that Tracecat depends on, including PostgreSQL and the S3-compatible object store, and set up backup for them. Confirm which authentication and single sign-on features your chosen edition includes before you rely on them. The step is done when the platform runs, backups restore in a test, and access control matches your policy.
Rebuild playbooks and port expression logic
Rebuild each in-scope FortiSOAR playbook as a Tracecat workflow, using Tracecat actions for the steps that call external tools. Rewrite the Jinja-style expressions and conditional logic in the form Tracecat expects, and move any custom action code into a Git repository that Tracecat syncs from, where your edition supports it. Start with the playbooks that handle the most alerts, because they show the most value and expose the most gaps. The step is done when each rebuilt workflow produces the same outcome as its FortiSOAR original on a set of recorded sample alerts, and the team has reviewed the differences.
Test in a non-production workspace
Run the rebuilt workflows in a non-production Tracecat workspace with copies of sample alerts, synthetic incidents and test credentials for each connected tool. Check that case creation, enrichment, approval steps and notifications behave as the analysts expect, and record every failure and its fix. Use a separate workspace so that test activity does not mix with production cases. The step is complete when the analysts who run the playbooks sign off on the results and the open defects have an agreed disposition.
Connect alert sources through webhooks
Point each alert source at a Tracecat webhook trigger, one source at a time, starting with a low-volume source. Confirm the payload format each source sends, adjust the workflow inputs where needed, and verify that cases are created with the expected fields. Keep the FortiSOAR ingestion path available so that you can revert a source quickly. The step is done when each source has delivered live alerts to Tracecat for a monitored period and the SOC has confirmed the cases look correct.
Run both platforms in parallel
Run FortiSOAR and Tracecat side by side, with each alert source sending to one platform as its primary and the other receiving copies or running in read-only mode for comparison. Compare case outcomes, error rates and analyst time on the same alerts. Decide in advance what evidence the team needs to switch each source, and record the decision. The step is done when every in-scope source has been switched and the comparison data supports the decision.
Archive FortiSOAR data and retire the platform
Decide which FortiSOAR records must move into Tracecat for active work and which should be exported to read-only archives under your retention policy. Keep the final configuration export and the archived records in a location your compliance team approves. Once cutover is complete and the agreed observation period has passed, disable FortiSOAR connectors, revoke its service accounts and decommission the platform, and keep the license obligations under review with your procurement team. The step is done when no alert source sends to FortiSOAR, the archives have been verified, and the decommission is documented.
How much work does a FortiSOAR to Tracecat switch take?
How long does a FortiSOAR to Tracecat switch take?
The duration depends on the scope, and a timeline follows from a written scope agreed before work starts. The main drivers are the number of playbooks and connectors in use, how many custom modules and record types need mapping to Tracecat cases and tables, how many alert sources must be switched over, and whether both platforms run side by side during cutover. A small playbook set with few integrations is a very different job from a large estate with custom content and multiple tenants. Ask for the timeline to be tied to a clear inventory from your current FortiSOAR configuration.
Can our team migrate from FortiSOAR to Tracecat without a partner?
Yes, a team with engineering capacity can do the work in-house, since Tracecat is open source and its documentation covers Docker Compose, Kubernetes and air-gapped deployment. The harder parts are usually inventorying FortiSOAR playbooks and connector settings, rewriting Jinja expressions and playbook logic as Tracecat workflows and actions, and validating outputs against live alerts. Many teams bring in outside help for the inventory and the cutover plan, then keep the rebuild in-house. Whichever route you take, agree the boundaries of responsibility before starting.
What does the migration require from our security and platform staff?
Expect to need people who know your current FortiSOAR playbooks, the SOC analysts who rely on them, and the platform engineers who will run Tracecat. Analysts should validate that rebuilt workflows produce the same case outcomes. Platform staff need to size and operate the stack, including PostgreSQL, Temporal, the object store and the sandbox components, and manage upgrades. Plan for review time from both groups, because automation that looks correct in a test often needs adjustment on real alert volume.
Do Tracecat's SSO and multi-tenant workspaces require the Enterprise Edition?
Based on the Tracecat documentation and repository, authentication and single sign-on are described as enterprise features, and multi-tenant workspace management is named as an Enterprise feature. Code in the enterprise package and feature gates falls under a separate paid license, while the core is AGPL-3.0. Confirm the exact feature split against the current documentation and your Tracecat contract before you design identity and tenancy, because it determines whether you need a paid license at all.
Does Tracecat work in an air-gapped network?
Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access, so it can be run in a closed network. Confirm which container images, Helm chart artifacts and any connector or MCP server dependencies must be mirrored in advance, and how updates will be brought in. Your FortiSOAR licensing relies on FortiGuard entitlements, so compare that dependency with what Tracecat needs in your environment. Ask your implementation scope to cover image mirroring, update procedures and the behavior when vendor contact is lost.
How should we compare total cost of ownership for each option?
Compare costs by component rather than by a single headline figure. For FortiSOAR, include subscriptions or licenses, the servers needed for high availability and scale-out, and the staff who maintain it. For Tracecat, include the infrastructure to host it, any Enterprise Edition license if you need SSO or multi-tenancy, the one-time migration work, and the ongoing staff time for upgrades and workflow maintenance. Ask every vendor and partner for a written quote that separates one-time from recurring costs and states what drives each line up or down.
What does DeployOpen do during the switch, and what do we keep?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure, under a fixed scope agreed in writing before work starts. In a Tracecat switch, that can cover the inventory, deployment in your cloud account, data center or air-gapped network, workflow rebuilding, integration and documentation. You keep ownership of the infrastructure, the data, the playbook decisions and the SOC processes. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For FortiSOAR vs Tracecat, we start with your SOC requirements and deployment constraints, then build and document a Tracecat environment you can operate after handover.
How we scope
- We inventory your FortiSOAR playbooks, connectors, modules and case types before recommending a Tracecat design.
- We confirm which Tracecat capabilities you need, including SSO and multi-tenant workspaces, and whether they fall in the Enterprise Edition.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Tracecat on Docker Compose, Kubernetes with the Helm chart, or an air-gapped Kubernetes cluster, matching your environment.
- We rebuild priority playbooks as Tracecat workflows with webhook triggers, case management and structured tables.
- We test workflows against sample alerts and document results, including where an AI agent step needs human approval.
How we hand over
- We deliver runbooks covering deployment, workflow ownership, custom action sync from Git and access configuration.
- We document backup and restore steps for the PostgreSQL database, Temporal state and object store your deployment uses.
- We walk your SOC and platform team through operation so they can maintain workflows without vendor involvement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We plan upgrades to new Tracecat releases, testing workflows and connectors in staging before production changes.
- We can prepare systems, controls and evidence for your compliance assessment, while independent auditors issue any reports.
