Which fits your team: Google SecOps SOAR or Tracecat for your own infrastructure
A security team facing a renewal, a data residency rule or a growing concern about lock-in should settle one question first: who will run the automation platform, and where must it run? Google SecOps SOAR fits when the team wants a managed cloud service, when SOAR is bundled with the SIEM in one ingestion-based package, and when the organization already relies heavily on Google's cloud. Tracecat fits when playbooks, cases and AI agents must run on Docker, Kubernetes or an air-gapped cluster inside the organization's boundary, and when the team is ready to operate that stack. Its core is licensed under AGPL-3.0, so the self-hosted code can be inspected and modified under that license.
Tracecat's documented self-hosted options include Docker Compose on a single host, AWS ECS Fargate through Terraform, a Kubernetes Helm chart, and an air-gapped Kubernetes deployment with no runtime internet access. That last option matters when a residency rule forbids outbound connections from the automation layer. Custom AI agents can call tools and MCP servers that you configure, so the team decides which systems an agent can reach. Google SecOps reaches internal systems through its own remote agent model, so confirm with Google which data location and deployment options your contract covers before you compare them with an on-premises design. Read the Tracecat documentation for the current deployment guides.
The decision usually turns on three questions. First, do you need SAML or single sign-on? Tracecat's documentation lists authentication and SSO as enterprise features, so check whether your identity model depends on them. Second, do you need multi-tenant workspace management or Git version control integration? The repository also names both as Enterprise features under a separate license. Ask Tracecat in writing which edition includes each capability you require. Third, who will operate the platform? Plan for the PostgreSQL database, the S3-compatible object store, the Temporal workflow engine and upgrades, and name the team that owns them before you commit to self-hosting.
Which option fits which scenario
This table matches common operating conditions to the better fit between Google SecOps SOAR and self-hosted Tracecat, with Shuffle where it changes the answer. Read each row against your own constraints, and check the condition named in the right-hand column before deciding. Teams with residency, air-gap or Python requirements will usually find Tracecat the closer match, but licensing and SIEM dependencies often decide the final path.
| Scenario | Better fit | Why, and what to check |
|---|---|---|
| Cloud-first SOC already on Google SecOps SIEM | Stay on Google SecOps SOAR, or pilot Tracecat alongside it | Alert ingestion and bundled cases keep working. Moving SOAR alone means repointing alert sources and confirming what the SIEM still costs. |
| Regulated team that must keep alert data inside its boundary | Tracecat, self-hosted | Docker Compose, Helm or AWS ECS Fargate keep workflows and cases in your environment. Confirm where logs, PostgreSQL and the object store reside. |
| Air-gapped network | Tracecat on air-gapped Kubernetes | A documented deployment runs with no runtime internet access. Confirm how images, connector updates and AI model access reach the cluster. |
| Team with Python integrations | Tracecat | Custom actions synced from Git let existing Python integrations be version controlled. Confirm whether your Git workflow needs the Enterprise feature. |
| Team that needs SSO or multi-tenancy | Tracecat Enterprise Edition | Authentication, SSO and multi-tenant workspaces are listed as enterprise features. Confirm the license scope before the design is fixed. |
| Team that needs a large premade app catalog now | Shuffle, or Tracecat after a connector check | Shuffle ships premade apps and an OpenAPI app creator. Tracecat lists more than 100 prebuilt connectors, so compare coverage for your specific tools. |
| Small team that wants a managed service | Ask for a hosted or managed quote before choosing | Tracecat is documented as self-hosted. Ask the vendor whether a hosted option exists, and ask DeployOpen for a retainer scope to run it. |
How Tracecat deploys: single host, Kubernetes, AWS ECS or air-gapped
Docker Compose on one host is the simplest way to evaluate Tracecat or run a small team's automation on infrastructure you control. The Compose stack brings the application services together, but each dependency still needs an operator decision. A single host also concentrates risk, because one machine holds the database, object store, workflow engine and sandboxing, so backup and restore planning matter from the first day. The Tracecat documentation describes this model in detail.
- Components to run: PostgreSQL for application data, an S3-compatible object store for artifacts, Temporal for durable workflow execution, and the Tracecat services themselves.
- Sandboxing: Custom actions run in nsjail, so confirm that the host kernel and container settings allow it before you test custom code.
- Scaling limit: One host means one failure domain and no horizontal scaling of workers, so treat this model as a pilot or a small production footprint.
- Persistence: Back up PostgreSQL and the object store together, and test restores on a second host before you rely on them.
Confirm which Compose file matches your Tracecat release and whether the object store and Temporal ship inside the stack or must be supplied as external endpoints.
The Helm chart suits teams that already operate clusters and want standard tooling for upgrades, secrets and network policy. Tracecat's services, Temporal and the data stores fall under your cluster governance, so the platform team owns capacity, ingress and recovery. Most of the design work lies in deciding where the stateful components live and who runs them.
- Stateful dependencies: Decide whether PostgreSQL, the S3-compatible store and Temporal run inside the cluster under your operators or as managed services reached over the network.
- Helm values: Keep chart values and secrets in version control under review, and pin the chart version you tested.
- Sandbox policy: nsjail needs specific process isolation features, so check the pod security settings and any admission policies your cluster enforces.
- Ingress and identity: Place the web interface behind your reverse proxy and single sign-on. The Tracecat documentation describes authentication and single sign-on as enterprise features, so confirm what your edition includes.
- Upgrades: Plan each Helm upgrade with database migrations and Temporal version compatibility in the same change window.
Ask Tracecat which chart version matches your Kubernetes version and whether Temporal is bundled with the chart or expected as an external dependency.
Tracecat documents an AWS ECS Fargate deployment provisioned through Terraform. This model suits teams that want a managed container runtime inside their own AWS account without managing nodes. The Terraform code defines the infrastructure, so it can be reviewed, versioned and rebuilt, but your team still owns the AWS accounts, identity and access policies, and the bill.
- Terraform state: Store state in a locked, encrypted backend inside your account, and restrict who can apply changes.
- Data services: Confirm which PostgreSQL and object storage resources the module creates and which you must supply, along with how each is encrypted.
- Networking: Decide between private subnets with controlled egress and public endpoints. Workers that call third-party APIs need outbound paths either way.
- Sandboxing on Fargate: Verify that nsjail-based action execution works under the Fargate runtime restrictions before you depend on custom actions.
- Recurring costs: Task sizing, the database instance class, storage volume and data transfer are the main ongoing AWS charges. Ask for the module's full list of created resources in writing.
Review the Terraform module version against your target AWS region and account guardrails, and confirm in the Tracecat documentation which parts of the module are supported.
Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. Container images, charts and any other dependencies must cross the boundary through a controlled transfer process before installation. The Google side works differently. Google Security Operations is a cloud service, and it reaches systems inside your network through remote agents that pull tasks, so a network that cannot accept that model needs the automation engine inside its own boundary.
- Artifact transfer: Mirror container images and Helm charts into an internal registry, and record checksums so each import can be verified.
- Runtime dependencies: Confirm that PostgreSQL, the object store, Temporal and nsjail need no external downloads at runtime, and that any AI agent model endpoints are internal or disabled.
- Connectors and MCP servers: Many connectors call external services. List the ones your environment can reach and plan internal endpoints for the rest.
- Release updates: Define how security fixes cross the boundary, including the review step for each release.
- Loss of cloud-hosted SOAR: Once the network is closed, the cloud-hosted SOAR and its bundled SIEM stop being reachable, so decide which log sources and alert feeds stay internal.
Ask Tracecat for its current air-gapped installation guide and check every image and dependency against your transfer process before you schedule a build.
Where your alert and case data lives under each option
Google SecOps SOAR runs as a Google-hosted service, so alert and case records sit in Google's cloud under Google's controls. Tracecat puts the same records in a stack you operate, which moves residency, licensing and evidence decisions onto your team and your contracts.
Data location and residency
With Google SecOps, alerts, cases and playbook run history are stored in Google Cloud under the service terms you accept. With Tracecat, case data lives in the PostgreSQL database and S3-compatible object store you deploy, whether that is a single Docker Compose host, an AWS ECS Fargate stack, a Kubernetes cluster or an air-gapped cluster. Confirm which region and host hold each store before you sign off on residency.
Core license versus enterprise code
Tracecat's core is licensed under AGPL-3.0, which governs how you may run and modify the code. Files under packages/tracecat-ee and enterprise feature gates fall under a separate paid Enterprise Edition license. Have legal map every feature you plan to use against those two licenses, because the AGPL obligations and the Enterprise terms are different contracts.
Identity and SSO as an enterprise feature
Authentication and single sign-on are described in Tracecat's documentation as enterprise features, so the free core may not give you your existing SSO path. Google SecOps authenticates through your Google identity setup. Before choosing Tracecat, confirm whether SSO, role mapping and multi-tenant workspace controls are included in the edition you will license, and plan how local accounts will be governed if they are not.
Audit trails and evidence ownership
Under Google SecOps, the vendor operates the platform and you request logs and reports within its offering. Under Tracecat, your team owns the audit logs, database backups, access records and change history of the deployment. Decide who exports these records, where they are retained and how long, and which ones are needed for each control you must evidence.
Who prepares controls and evidence
DeployOpen can plan the hosting, access, backup and logging controls for a self-hosted Tracecat deployment and prepare the evidence that shows they operate. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so ask your auditor which evidence formats they accept before scoping the work.
Which Tracecat features need the paid Enterprise Edition
Tracecat is licensed under AGPL-3.0, but the repository separates its code into two licenses. Code in packages/tracecat-ee and the enterprise feature gates sits under a separate paid Enterprise Edition license. The Tracecat repository names multi-tenant workspace management and Git version control integration as Enterprise features, and the Tracecat documentation describes authentication and single sign-on as enterprise features as well. For a single team running Google SecOps SOAR replacement work on its own infrastructure, the core AGPL edition covers the workflow automation, webhook triggers, case management, structured tables, custom AI agents with tools and MCP servers, and custom actions that the team defines itself. The core edition also covers the self-hosted deployment paths documented by Tracecat, including Docker Compose, Helm on Kubernetes and the air-gapped Kubernetes option.
The practical consequence affects the migration plan. If your Google SecOps SOAR playbooks are being translated into Tracecat custom actions synced from Git, the Git sync feature is one of the enterprise items, so confirm with Tracecat whether your intended sync pattern is available on the edition you plan to run. Single sign-on is the other common gap: if your security analysts must sign in through your corporate identity provider, check whether that requirement depends on the Enterprise Edition before you size the project. Ask Tracecat for a written list of the features in each edition, the license terms that apply to the version you will deploy, and whether a commercial license changes your obligations under AGPL-3.0 if you modify the code.
Edition boundaries can change between releases, so treat any feature list in this page as a starting point and confirm the current one before committing. Tracecat 1.2.0 was released on October 16, 2026, according to its GitHub releases page, so check that release's notes against your requirements. Build a short checklist: which of your analysts need individual sign-on, whether you have more than one team or tenant that must stay separated, and whether your playbook source control must live in Git. Those three answers decide whether the core edition is enough or whether the enterprise license belongs in the cost model from the start.
Cost of ownership: licenses, infrastructure, people and migration work
Comparing Google SecOps SOAR with Tracecat is mostly a comparison of who you pay and for what. The subscription side is set by Google's contract, while the Tracecat side is open-source software plus the infrastructure, operations and engineering time you carry yourself.
Google SecOps subscription
Google Security Operations is sold as a cloud service in ingestion-based packages, with SOAR bundled into the SIEM subscription. The recurring cost is set by your ingestion volume and package terms, not by the SOAR features you use. Ask Google to price SOAR as a separate line if you plan to keep the SIEM and move only automation, because the bundle makes that split hard to see on a standard renewal.
Tracecat core licensing
The core platform is licensed under AGPL-3.0, so there is no per-seat or per-connector license fee for the open-source features. Your recurring costs are infrastructure and people. Confirm with your legal team how AGPL obligations apply if you modify Tracecat and offer it to users outside your organization.
Enterprise Edition licensing
Multi-tenant workspace management, Git version control integration and authentication with single sign-on are described as Enterprise features under a separate paid license. If your identity provider requires SSO or you need separate tenants for business units, budget for this as a recurring line item and request a written quote covering term, support and what the license includes.
Servers, PostgreSQL, Temporal and storage
Self-hosting means running the Python and Next.js services, PostgreSQL, Temporal for durable workflow execution and an S3-compatible object store. These are recurring compute, storage, backup and patching costs in your cloud account or data center. Cost rises with case volume, workflow run frequency and retention, and the choice between single-host Docker Compose, AWS ECS Fargate, Kubernetes or an air-gapped cluster changes the operations load.
Staff who build and maintain playbooks
Most of the recurring cost is people: engineers or analysts who build workflows, write custom actions, tune agents, review changes and handle upgrades. Google SecOps playbooks are built in its visual tooling, so Tracecat requires skills in its workflow model and Python custom actions. Estimate this by counting active playbooks and integrations, then ask your staffing or retainer provider for a written scope that names who maintains them after go-live.
One-time migration and cutover work
Migration is the main one-time cost: inventorying playbooks, blocks and connectors, translating Python integrations into Tracecat custom actions synced from Git, mapping cases, testing and repointing alert sources. Google's export tools do not carry case history, so plan separately for archiving closed cases. Ask for a fixed-scope written proposal that lists playbooks in scope, cutover approach, parallel-run period and acceptance criteria.
What moving playbooks and cases to Tracecat involves
The sequence turns Google SecOps SOAR playbooks, integrations and case workflows into Tracecat workflows, custom actions and tables that run in your own infrastructure, with alert sources cut over only after parallel checks pass. Each step closes with a named output so the team knows when to move on.
Inventory playbooks, blocks and connectors
Security engineering and the SOAR owner list every active playbook, the blocks each one calls, and the connectors and remote agents those blocks depend on. Mark which playbooks trigger from the SIEM, which are run by analysts and which are scheduled or rarely used. Record the alert types and case fields each playbook reads and writes. This step is done when the team has one inventory that maps every production playbook to its triggers, integrations and owners, and the owners have confirmed the list is complete.
Export playbook definitions from Google SecOps
An administrator exports playbook definitions and related content from Google SecOps SOAR, using the ZIP export or GitSync, and stores the archives in version control outside the SOAR tenant. Confirm with Google what the export covers, since exports may not include case history, analyst notes or attachments. Ask the same question about integration configuration and secrets. This step is done when every inventoried playbook has a stored definition and the gaps in the export are written down.
Translate Python integrations into Tracecat custom actions
Developers rewrite each custom Python integration as a Tracecat custom action, then store the action code in a Git repository that Tracecat syncs from. Blocks that only call a documented API can often be rebuilt as Tracecat actions or built-in connectors, while integrations with local logic need a closer review. Credentials move into Tracecat's secrets handling, not the code. This step is done when each action passes a test run against a non-production system and the owner signs off on its inputs and outputs.
Map cases and structured data to Tracecat
The case owner maps each Google SecOps case field, status, severity and playbook output to a Tracecat case field or structured table, and defines which values the workflows must set. Decide which historical cases are kept as a read-only archive in the existing system and which are not migrated. This step is done when a written field map exists for every case type in scope and a sample case created in Tracecat carries the same data the analyst needs.
Stand up the chosen Tracecat deployment
The platform team installs Tracecat in the chosen environment: Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through the Helm chart, or the air-gapped Kubernetes deployment if there is no runtime internet access. Tracecat relies on PostgreSQL, an S3-compatible object store and Temporal, so confirm each dependency is hosted, backed up and monitored. Ask Tracecat's documentation which features are enterprise-only, such as single sign-on and multi-tenant workspaces, before you design access. This step is done when workflows run end to end on a test webhook and the backups restore successfully.
Rebuild workflows and run them in parallel
Engineers rebuild each playbook as a Tracecat workflow using webhook triggers, the translated actions and the mapped case fields, then route a copy of live alerts to Tracecat while Google SecOps keeps handling them. Compare the actions each system takes, the case outcomes and the timing for a set period agreed with the SOC lead. Investigate every mismatch and record whether it is a logic error, a missing integration or an accepted difference. This step is done when the SOC lead signs off on the comparison and the open differences are resolved or accepted in writing.
Cut over alert sources and retire remote agents
Once parallel results are accepted, the SIEM and detection sources are repointed to Tracecat's webhook endpoints one source at a time, with a documented rollback for each. Remote agents and Publisher configurations that fed Google SecOps are disabled after their last task is handled, and their credentials are revoked. Confirm that no detection still routes to the old SOAR before the tenant is set to read-only. This step is done when every alert source reaches Tracecat, the agents are removed, and the cutover record is filed with the security team.
Questions buyers ask before choosing Tracecat over Google SecOps SOAR
What does switching from Google SecOps SOAR to Tracecat actually cost?
The cost has four parts: the Tracecat software itself, the infrastructure to run it, the migration work, and the staff time to maintain playbooks afterward. Tracecat's core is licensed under AGPL-3.0, so the open-source edition carries no license fee, but features in the separate Enterprise Edition require a paid license. Infrastructure depends on the deployment model you choose: Docker Compose on a single host, AWS ECS Fargate through Terraform, Kubernetes through a Helm chart, or an air-gapped Kubernetes cluster. Your Google Security Operations contract is a separate cost. If you only move SOAR, you still pay for the SIEM unless you replace it too. Ask Google for the terms of your package and ask Tracecat for current Enterprise Edition pricing, since no figure is supplied here.
How long does a migration to Tracecat take?
The timeline depends mainly on how many playbooks, blocks and connectors you run today, and how many of them use custom Python integrations that must be rewritten. Simple playbooks built from prebuilt connectors move faster than bespoke logic that touches many internal systems. Tracecat provides more than 100 prebuilt connectors, so check how many of your integrations already have a match before estimating. Work also depends on how many alert sources you need to repoint and how much case history you must keep. No duration is supplied for this migration, so request a timeline from a written scope that lists each playbook and integration rather than relying on a general estimate.
Can our own team migrate to Tracecat without outside help?
A team with automation engineers and familiarity with Docker or Kubernetes can handle a small set of playbooks in-house. The harder parts are inventorying existing playbooks and connectors, translating custom Python logic into Tracecat custom actions synced from Git, mapping cases, and cutting over alert sources without losing detections. Tracecat's own documentation covers the self-hosted deployment options, so start with a proof of concept on one playbook before committing. If the inventory is large or the team lacks time, a fixed-scope engagement with DeployOpen can plan, implement and document the work, with scope, deliverables and timelines agreed in writing first.
Which Tracecat features require the Enterprise Edition?
The Tracecat repository names two features as Enterprise capabilities: multi-tenant workspace management and Git version control integration. The Tracecat documentation also describes authentication and single sign-on as enterprise features. Code under the enterprise package path and enterprise feature gates falls under a separate paid license, while the core is AGPL-3.0. Confirm the current list with Tracecat before you design around it, because gated features can change between releases. If your plan depends on Git-synced custom actions, which is central to translating Python integrations, check whether that workflow is free in your deployment model.
Does Tracecat support air-gapped deployment?
Yes, Tracecat documents an air-gapped Kubernetes deployment with no runtime internet access. This matters for networks that cannot accept Google SecOps' cloud model and its remote agents that pull tasks over the Publisher proxy. Before you commit, confirm how updates, container images and prebuilt connector content reach the isolated cluster, since those artifacts must be mirrored into your boundary. Also confirm which features in your plan need outbound access, such as third-party APIs your playbooks call. The Tracecat documentation should be the first place to check these details.
What do Tracecat's underlying components mean for daily operations?
Tracecat runs a Python FastAPI backend, a Next.js frontend, Temporal for durable workflow execution, PostgreSQL for data, an S3-compatible object store and nsjail for sandboxing. Each component needs backups, monitoring, upgrades and access control, so your operations team takes on more than a SaaS subscription removes. Temporal and PostgreSQL in particular need capacity planning and recovery procedures that match your incident response targets. Tracecat 1.2.0 was released on October 16, 2026, so plan a regular upgrade cycle and test each release in a non-production workspace first.
What skills and staff time does running Tracecat require?
Plan for people who can operate containers, manage a database and object store, handle secrets and SSO configuration, and write or review automation code. Playbook authors need to understand your case lifecycle and the tools in your SOC. Expect ongoing effort for connector maintenance, custom actions and AI agent tooling, which Tracecat supports through custom agents with tools and MCP servers. Ask your staff to name an owner for the platform, for playbook changes and for security patches. Those responsibilities recur after go-live and are often the largest long-term cost.
How DeployOpen scopes a Tracecat evaluation or migration
DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For a Tracecat engagement, that work usually starts with a fixed scope agreed in writing before any work begins. The scope names the deployment target (Docker Compose on a single host, Kubernetes through the Helm chart, or the air-gapped Kubernetes option), the playbooks and cases to be rebuilt, the alert sources to connect, the identity integration, and the deliverables and timeline the two parties accept. Ongoing support, upgrades and continuous testing are handled separately as a retainer, so the reader should decide early whether the first phase ends at cutover or continues into operation.
DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful preparation is an inventory: how many playbooks and cases your team handles, which connectors and custom integrations you depend on, which Tracecat features you need (several sit in the Enterprise Edition, such as single sign-on and multi-tenant workspace management, so confirm these against the Tracecat documentation before scoping), and where the database, object store and workflow engine will run. Ask for the quote to list each component separately: discovery and evaluation, environment build, playbook translation, integration work, hardening, backup and recovery setup, documentation, and any retainer. Ask which items are one-time and which recur.
DeployOpen does not hold any partnership, reseller or certified provider status with Tracecat, and an engagement does not imply one. Scope discussions should therefore confirm licensing directly with the vendor: which edition your team needs for each feature, who signs that agreement, and whether any Enterprise Edition license changes the deployment work. Before signing a scope, ask DeployOpen to state which decisions it will make with you, which it will leave to your security and compliance owners, and which evidence it will hand over. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Google SecOps SOAR versus Tracecat, we start from your playbooks, cases and alert sources, then scope a deployment that fits your environment.
How we scope
- Inventory of existing Google SecOps SOAR playbooks, blocks, connectors and case workflows before any design work starts.
- Written scope covering deployment target, Tracecat edition requirements, integrations and the cases to be migrated.
- Fixed-scope engagements with deliverables and timelines agreed in writing before work begins, and a quote that follows from that scope.
How we build
- Deployment on Docker Compose, Kubernetes via Helm, or an air-gapped Kubernetes cluster, matched to your network boundary.
- Rebuilding priority playbooks as Tracecat workflows with webhook triggers, and translating Python integrations into custom actions synced from Git.
- Testing of workflows, case handling and AI agent tool access against your own sample alerts before any live alert source is connected.
How we hand over
- Documentation of the architecture, configuration, workflow inventory and the list of features that depend on the Enterprise Edition.
- Runbooks for operating the Temporal, PostgreSQL and object store components, including backup and restore steps.
- Knowledge transfer to your platform and security engineers, with a written record of cutover steps and rollback options.
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover.
- Upgrade planning for each Tracecat release, with testing of existing workflows before a new version reaches production.
- Preparation of configuration and evidence for compliance assessments, with independent auditors providing any formal audit or certification.
