Tracecat: an AGPL-3.0 security automation platform you self-host with Docker

What Tracecat automates, and for whom

Tracecat targets security operations work that currently lives in a mix of cron jobs, ticket queues and hand-written scripts. The README describes it as an open source security automation platform for teams and AI agents, and lists four things it keeps in one place: agents, workflows, lookup tables and case management. A detection fires, a case is opened, a workflow runs, an agent writes notes back to the case, and a table holds the enrichment data the next run will need. The repository topics confirm the audience: incident-response, case-management, orchestration, security.

The people who get value from it are the ones who already write Python for security tasks and want those scripts to run durably, with a UI on top. Tracecat is not aimed at analysts who want a purely click-driven playbook editor, and it is not a detection engine. It assumes you bring the alerts. The README positions it against the usual SOAR category, and the related searches show people comparing it to other open source SOAR platforms.

Temporal for durability, nsjail for the untrusted parts

The architecture is split into a Python backend (FastAPI, SQLAlchemy, Pydantic, managed with uv), a Next.js frontend, PostgreSQL for state, an S3-compatible object store, Temporal for durable workflow execution, and nsjail for sandboxing. The pyproject.toml dependencies back this up: fastapi, sqlalchemy via alembic migrations, aioboto3 and minio for object storage, temporalio, and fastmcp for the MCP layer.

Two design decisions matter more than the rest. First, workflows run on Temporal, so a step that waits on a human approval or a slow API call is a durable execution rather than a process you keep alive. Second, untrusted code runs inside nsjail sandboxes or pid runtimes. The Dockerfile builds nsjail from a pinned commit (NSJAIL_COMMIT=388b9655a696e88df3185d09e36c0378a8532904) and applies a patch named nstun-bounded-memory.patch, then builds a minimal sandbox rootfs from python:3.12-slim-bookworm. That is a heavier build than most self-hosted tools, and it is the price of running third-party scripts in the same deployment as your case data.

The MCP layer cuts both ways. Tracecat can act as an MCP server so an external agent harness turns prompts into automations, and it can act as an MCP client to reach remote HTTP or OAuth servers or local servers via npx or uvx commands. The README notes that pre-built hosted MCP servers are an Enterprise Edition feature, so the open source path expects you to supply your own.

Installing Tracecat with Docker and running a first workflow

The README gives four deployment options: Tracecat Cloud, Docker, AWS Fargate, or Kubernetes Helm. Self-hosting starts from the Docker Compose files and the environment template. Copy .env.example to .env, then generate the three secrets the file names, because the compose file will not start without them.

git clone https://github.com/TracecatHQ/tracecat.git
cd tracecat
cp .env.example .env
python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
openssl rand -hex 32
openssl rand -hex 32

The Fernet output goes into TRACECAT__DB_ENCRYPTION_KEY, and the two hex strings fill TRACECAT__SERVICE_KEY and TRACECAT__SIGNING_SECRET. The template also sets PUBLIC_APP_PORT=80, PUBLIC_APP_URL=http://localhost:${PUBLIC_APP_PORT} and TRACECAT__APP_ENV=development. Set TRACECAT__APP_ENV to production for anything reachable from outside your machine.

docker compose up -d
docker compose ps

The compose file starts caddy on ${PUBLIC_APP_PORT}, the api service from ghcr.io/tracecathq/tracecat, and the supporting services. Note the image tag default: TRACECAT__IMAGE_TAG:-1.0.0-beta.50. If you want a different build, set that variable rather than editing the compose file. Once the stack is up, the app is at the URL in PUBLIC_APP_URL.

From there the workflow is: create a workflow in the low-code builder, add steps, and attach a Python script from your Git repository as a custom registry action so it can be used as a workflow step or an agent tool. The README does not walk through the script sync step, so check the docs directory in the repository before assuming a specific sync command exists.

Beta software, and a licence boundary inside the repository

The repository is not archived and the last push was on 2026-09-10, so the codebase moves. But the release line is explicit: the newest tags are 1.0.0-beta.52-rc.24, 1.0.0-beta.52-rc.23 and 1.0.0-beta.52-rc.22, all release candidates. The README carries an important note that Tracecat is in active development and tells you to review the changelog before updating. The pyproject.toml classifier says Development Status :: 4 - Beta. Treat upgrades as a real operational task, not a background pull.

The harder constraint is licensing. The repository is AGPL-3.0 with stated exceptions: the packages/tracecat-ee directory and the code that gates ee features across the repo fall under Tracecat's paid Enterprise Edition licence, and the README says production use requires a valid Tracecat Enterprise License. That means the open source build and the enterprise build are not the same product. Features the README lists under Enterprise Edition include fine-grained access control (RBAC, ABAC, OAuth2.0 scopes), human-in-the-loop approval of sensitive tool calls, workspace version control to GitHub, GitLab or Bitbucket, and metrics and monitoring for workflows, agents and cases. If any of those are on your requirements list, you are evaluating a commercial product, not an AGPL one. This is a description of the licence terms as stated, not legal advice; read the LICENSE file and the EE directory before you deploy.

The other limitation is operational weight. A self-hosted Tracecat is PostgreSQL plus Temporal plus an S3-compatible store plus a Caddy proxy plus the nsjail sandbox stack. Teams without someone who can run that will find managed Cloud cheaper than the time they spend on it. The README does not document rollback or downgrade procedures, which matters when the only tags are release candidates.

How Tracecat differs from a pure playbook runner

The obvious comparison is a workflow-only automation tool such as n8n or a classic SOAR playbook engine. The difference is not the node editor, which all of them have. It is that Tracecat treats Python scripts as first-class registry actions and runs them in nsjail sandboxes, and it runs the whole graph on Temporal so long waits and retries survive a restart. A generic automation tool will call an HTTP endpoint; Tracecat will run your code under a sandbox policy and expose the same code as an agent tool.

The second difference is the agent layer. Tracecat bundles an MCP server and an MCP client, so an external coding agent can build automations, and internal agents can reach external MCP servers. Tools that bolt an LLM onto a playbook editor are doing something adjacent but not the same. If your need is a cron-driven script runner with a nice UI, Tracecat is more infrastructure than you need. If your need is durable, sandboxed security automation with case state attached, the combination is harder to assemble yourself.

Who should deploy Tracecat, and what to check first

Tracecat fits security engineering teams that write Python, already run containers, and want automation, case tracking and agent tooling in one self-hosted system rather than three. It fits teams that need data to stay inside their own network and are willing to run Temporal and PostgreSQL to get that.

It does not fit teams that need a supported stable release today, because the current line is 1.0.0-beta.52 release candidates. It does not fit teams whose requirements are mostly RBAC, approval workflows, workspace version control or workflow metrics, since those are listed as Enterprise Edition. And it does not fit a one-person security team with no container experience, because the sandbox build and the four backing services are not something you set and forget.

Before deploying, verify three things in the repository: which files sit under packages/tracecat-ee, what the release changelog says about the version you plan to pin, and whether the docs cover the script sync path from your Git repository. The compose default tag is 1.0.0-beta.50, which is older than the newest release candidates, so decide deliberately whether to pin it or override TRACECAT__IMAGE_TAG.

Editorial conclusion

Adopt Tracecat if you want a self-hosted, code-native automation layer where Python scripts become workflow steps and agent tools, and you are comfortable running PostgreSQL, Temporal, an S3-compatible store and nsjail from docker-compose.yml. Do not adopt it if you need a stable release line, because the newest tags are 1.0.0-beta.52 release candidates, or if your roadmap depends on RBAC, human-in-the-loop approvals or hosted MCP servers, which the README places in the Enterprise Edition under a paid licence. Before committing, read the packages/tracecat-ee boundary in the repository and confirm which of the features you need sit on the AGPL-3.0 side.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. TracecatHQ/tracecat on GitHub