Tracecat: an AGPL security automation platform with an enterprise-licensed core
Open-source security automation platform for teams and AI agents
At a glance
- What is it?
- Tracecat combines agents, Temporal-backed workflows, lookup tables and case management in one Python and Next.js application, aimed at security teams that want to write automations rather than click through them. The main thing to understand before adopting it is that the repository ships under two licences, and the version string is still a beta release candidate.
- Who is it for?
- Adopt Tracecat if you have engineers who are comfortable running Temporal, PostgreSQL and an S3-compatible object store, and if your automation needs span workflows, agents and case tracking rather than one of those alone. Do not adopt it if your organisation cannot accept AGPL-3.0 terms, if you need the enterprise features and cannot buy a licence, or if you require a stable tagged release rather than a beta release candidate.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Tracecat is trying to close in security operations
Security teams accumulate automation in fragments. A SOAR playbook lives in one console, a Python enrichment script lives in a Git repository, the investigation notes live in a ticketing system, and the lookup data those scripts need lives in a spreadsheet or a static file. Tracecat's pitch is that all four belong in one application. The README describes it as "the open source security automation platform for teams and AI agents" and lists agents, workflows, lookup tables and case management as a single unit rather than four products.
The intended user is not a analyst clicking through a no-code builder. It is a security engineering function that already writes Python and wants the orchestration layer to stop being a separate system. The README frames the code-native angle directly: custom Python scripts are synced from your Git repository into Tracecat, and the custom registry turns those scripts into agent tools and workflow steps. That is a meaningfully different starting point from platforms where the extension mechanism is a vendor SDK wrapped in a proprietary runtime.
Agents, workflows, cases and tables as one data model
The architecture visible in the material is a Python backend built on FastAPI, SQLAlchemy and Pydantic, managed with uv, with a Next.js and TypeScript frontend using React Query and Shadcn UI. Persistence is PostgreSQL, and an S3-compatible object store handles binary data. Durable execution is delegated to Temporal, which is the part that matters most for anyone who has been burned by cron jobs that silently die halfway through an incident.
Temporal's role is to make workflow execution durable, so a long-running enrichment or containment sequence survives a process restart. On top of that, the workflow builder supports if-conditions and loops, which the README lists alongside durable execution as the core of the workflows feature. Agents are a separate construct with prompts, tools and chat. They connect outward through an MCP client that speaks to remote HTTP or OAuth servers, or to local servers launched with npx or uvx commands. Tracecat also exposes its own MCP interface, which the README says turns prompts into automations through Claude Code, Codex and Copilot.
The sandboxing layer is nsjail. The README states that untrusted code and agents run inside nsjail sandboxes or pid runtimes, and describes the platform as sandboxed-by-default. That default is the difference between an agent that can execute generated code and an agent that can execute generated code on your production host. Note what the material does not say: it gives no isolation guarantees beyond the nsjail and pid runtimes, no resource limits, and no escape analysis. Treat the sandbox as a boundary you still have to configure and test.
Running it: Docker, Fargate, Helm, and what the README does not give you
Deployment options named in the README are managed Cloud, self-hosted Docker, AWS Fargate, or Kubernetes Helm. Those are the only paths described. The README does not include a docker compose snippet, environment variable list, port map or Helm values example, so anyone self-hosting has to go to the repository or the documentation site to find the actual commands. That is a real gap in the top-level material, and it is worth knowing before you budget a day for evaluation.
What the README does commit to are the infrastructure dependencies you must supply yourself: Temporal for durable workflows and jobs, PostgreSQL for the database, and an S3-compatible object store. A self-hosted evaluation therefore involves standing up four systems, not one. Configuration keys, connection strings and secret names are not listed in the supplied material, so this article will not guess at them. The honest position is that the README tells you which components exist and which deployment targets are supported, and nothing about the specific values you pass to them.
The licence split is the first thing to check, not the last
Tracecat is AGPL-3.0 with carve-outs. The README states that the packages/tracecat-ee directory, and the code that gates enterprise features across the repository, fall under a paid Enterprise Edition licence, and that production use of those parts requires a valid Tracecat Enterprise Licence. It further states that code under those exceptions must not be redistributed, sold or otherwise commercialized without permission.
This is a hybrid model, and it has two practical consequences. First, if you fork the repository or offer a hosted service built on it, you need to understand which files you are touching. The boundary is described as extending beyond a single directory into feature-gating code spread across the repo, which makes the split harder to reason about than a clean directory-level separation. Second, the enterprise feature list is not decorative. Pre-built MCP servers, RBAC and ABAC with OAuth2.0 scopes, human-in-the-loop approval from an inbox, Slack or email, workspace version control syncing to GitHub, GitLab or Bitbucket, and workflow, agent and case metrics are all listed as Enterprise Edition. If your reason for choosing Tracecat includes fine-grained agent permissions or an approval queue, you are evaluating a commercial product with an open source core, not an open source product. Whether AGPL-3.0 obligations suit your distribution model is a question for your own counsel; nothing here is legal advice.
Beta release candidates and the upgrade cost they imply
The most recent releases listed are 1.0.0-beta.52-rc.24, 1.0.0-beta.52-rc.23 and 1.0.0-beta.52-rc.22, published within days of each other in September 2026. A patch number of 52 and a release-candidate suffix of 24 is a lot of iteration on a single beta line. The README reinforces this with an explicit warning: Tracecat is in active development, and readers should review the release changelog before updating.
For a self-hosted deployment this translates into an operational cost that is easy to underestimate. You are running PostgreSQL, Temporal, an object store and two application tiers, and the application tier is shipping release candidates on a fast cadence. Upgrades need a changelog review each time, and the README's own instruction to do so suggests breaking changes are expected rather than exceptional. If your team cannot absorb that cadence, pin a specific release candidate and treat upgrades as scheduled work with a rollback plan, rather than tracking main.
The counterweight is that the project is not archived and is actively pushed, so the churn is a sign of development rather than abandonment. Both things are true at once, and the decision is whether your team wants to be early on a beta or late on something quieter.
Where Tracecat is the wrong tool
Three cases stand out. The first is a team that wants a single-purpose enrichment script. Tracecat's value comes from the integration of workflows, agents, tables and cases; adopting Temporal, PostgreSQL and an object store to run one script is a poor trade against a scheduled function in whatever cloud you already use.
The second is an organisation that needs the enterprise features but cannot or will not buy the licence. Human-in-the-loop approval, RBAC and ABAC, workspace version control and metrics are all on the paid side. A team that adopts the AGPL core expecting to grow into those capabilities will hit a wall, and the README's own framing of the enterprise edition as a separate licensed product makes that wall explicit rather than accidental.
The third is a team without anyone who has operated Temporal. The README presents Temporal as the substrate for durable execution and jobs, which means debugging a stuck workflow is a Temporal problem as much as a Tracecat problem. The platform does not hide that dependency, and it should not be treated as invisible during evaluation.
On alternatives, the material supports one honest comparison. A general-purpose workflow orchestrator such as Temporal used directly, with your own Python activities and your own case tracking in a separate tool, gives you the same durable execution substrate without the security-specific data model. The difference in approach is that you assemble the pieces yourself and keep full control of the licence, but you also write and maintain the agent tooling, the lookup tables and the case layer that Tracecat ships as one application. Tracecat's bet is that the integration is worth more than the assembly cost. That bet is reasonable for a security engineering team and unreasonable for a platform team that already has an orchestrator.
Editorial conclusion
Adopt Tracecat if you have engineers who are comfortable running Temporal, PostgreSQL and an S3-compatible object store, and if your automation needs span workflows, agents and case tracking rather than one of those alone. Do not adopt it if your organisation cannot accept AGPL-3.0 terms, if you need the enterprise features and cannot buy a licence, or if you require a stable tagged release rather than a beta release candidate. Verify three things first: the contents of packages/tracecat-ee and which features it gates, the changelog entry for the specific 1.0.0-beta.52-rc build you intend to run, and whether the Docker, Fargate or Helm deployment path you choose gives you a working Temporal and PostgreSQL setup before you migrate any existing runbooks onto it.
Community notes