Argus: an agentic SOC platform built as Django apps plus a Next.js console
An open source AI-native agentic SOC platform
At a glance
- What is it?
- Argus packages alert ingestion, ticketing, CMDB, correlation, workflow orchestration and an MCP-style AI assistant into one Apache-2.0 repository. The design is API-first and loosely coupled, but the README also leaves several operational questions open.
- Who is it for?
- Argus is worth a pilot if you want a single self-hosted console for alerts, tickets, CMDB and Sigma-based correlation, and if you have someone who can read Django settings and the k8s manifests rather than only clicking through the UI. Skip it if you need a drop-in managed detection service or if your analysts cannot be given MCP tool access under least privilege.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- 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
What Argus is trying to replace, and for whom
Most small security teams run a detection stack that is really three or four separate products: something that ingests and stores alerts, a ticketing system, a spreadsheet or CMDB for asset context, and a workflow tool bolted on to move data between them. Argus takes the position that these are one product. The README lists the consolidated objects as Alerts, Tickets, CMDB, Dashboards, Correlation, Workflows/Orchestrator and an AI Assistant, and the repository layout mirrors that list with one Django app per domain under backend/.
The intended user is not a large enterprise with an existing SIEM contract. It is a team that wants to self-host, wants the source, and is willing to run PostgreSQL plus a Django service plus a Next.js frontend. The README explicitly offers two modes: deploy it as a complete SOC platform, or integrate it into an existing security ecosystem through the API. That second mode is the more realistic one for most readers, because the API prefix /api/v1/ is documented and the frontend already proxies through it.
The architecture: Django apps behind a Next.js proxy
The architecture notes break the system into six layers. The frontend is Next.js App Router and handles pages, UI composition and API proxying. The API layer is Django with Django REST Framework, providing auth, alerts, tickets, CMDB, workflows and AI endpoints. Domain features are separated into Django apps so they can evolve independently with RBAC. PostgreSQL is the primary datastore and Elasticsearch is described as an optional alert source, not a required component. The AI Assistant sits in an intelligence layer that exposes MCP-style interfaces, and the orchestrator and workflows layer handles scheduled execution and audit trails.
The data flow for a browser request is stated plainly: the frontend proxies /api/v1/* requests through a Next.js route handler to the backend, centralizing browser-side API access. That is a deliberate choice. It means the browser never talks to Django directly, which simplifies CORS and lets the Next.js layer act as the single entry point. It also means the Next.js service is on the critical path for every API call, so its availability matters as much as the backend's.
Authentication is DRF Token Authentication, and the auth endpoints cover login, logout, register and OTP. Token auth is simple to operate but it is not the same as short-lived session tokens; anyone holding a token holds the account until it is rotated. The README does not describe token expiry or rotation policy, and that gap is worth noting before you put this in front of analysts.
Detection as code, and where Sigma fits
Under Detection, the README claims out-of-box use case detection and correlation rules, detection-as-code with rule versioning, and write-once, run-anywhere detection with Sigma rules. The correlation app in the repository layout is where the rules live. The value of the Sigma claim is portability: a rule written in Sigma is not tied to Argus, so if you later move to another engine you keep the detection content. The cost is that Sigma covers a defined set of log source categories, and anything outside those categories has to be expressed in whatever native format Argus uses. The README does not document that native format, so treat the Sigma path as the supported one until you read docs/architecture.md.
Rule versioning is listed but not specified. There is no described mechanism for promoting a rule from staging to production, no described rollback, and no described test harness. If your team already treats detections as code with CI, you will be building that pipeline yourself around the correlation app.
The AI assistant is an MCP tool registry, not a chatbot wrapper
The AI section is the part that distinguishes this project from a conventional open source SIEM. The README describes a built-in conversational interface plus an MCP-style tool registry and JSON-RPC connector, exposed at /api/v1/mcp/. The listed capabilities are ticket-context queries, similar-case retrieval, CMDB queries and observable extraction.
That list matters more than the chat window. Each of those is a tool the assistant can call, which means each is a permission boundary. The security section of the README says to configure access boundaries, auditing and least-privilege for AI and MCP features. That is the correct advice, and it is also an admission that the default posture is not automatically least-privilege. If you deploy Argus and leave the MCP endpoints reachable with a broadly scoped token, you have given a language model read access to your ticket history and asset inventory. The README does not document per-tool authorization, so plan to enforce it at the gateway or in the Django permissions layer.
The observable extraction tool is the one to scrutinize first. Extraction turns free text into structured indicators, and the output is only as good as the model behind it. Nothing in the supplied material names the model provider, whether local or remote inference is used, or what happens to ticket content that is sent for analysis. That is a data residency question you have to answer yourself before pointing this at production tickets.
Getting it running: compose files, env template and make targets
The repository ships docker-compose.dev.yml for local development and docker-compose.prod.yml for a production container setup. An env.example file serves as the environment template, and there is a makefile with helper targets. Kubernetes manifests live in k8s/ and the README names three of them: k8s/backend-deploy.yaml, k8s/frontend-deploy.yaml and k8s/postgres-deploy.yaml.
The security section gives the concrete settings to change in production: a secure random SECRET_KEY, precisely set ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS, backups and monitoring for the database, object storage and logs. Those are Django settings, so they belong in the environment file that env.example models. The README does not print the exact variable names beyond those three, and it does not show a full compose invocation, so the honest starting point is to copy env.example, fill in the values, and read the compose file before running it.
Two deployment details are worth flagging. First, the k8s directory is described as containing basic deployment manifests; there is no mention of a StatefulSet for PostgreSQL, so the postgres-deploy.yaml is likely a plain Deployment and you should check how storage is handled before trusting it with ticket data. Second, PostgreSQL is marked optional in the tech stack, which is confusing given the architecture notes call it the primary datastore. Verify which components actually run without it.
Version cadence and what v0.72 implies
The releases listed are v0.7 on 2026-07-02, v0.71 on 2026-07-05 and v0.72 on 2026-07-08. Three releases in six days, all in the 0.7x range. That cadence suggests active iteration on a pre-1.0 codebase rather than a stabilized product. The last push to the default branch is 2026-09-10, so the project is not archived and work continued after the release window.
For an operator, the practical consequence is upgrade churn. A pre-1.0 project that ships patch releases days apart will occasionally change API shapes or migration files. The README does not describe a database migration policy, a deprecation window, or an upgrade procedure beyond the compose and k8s files. If you deploy Argus, pin the image tag rather than tracking main, and read the diff between releases before applying them. The Apache-2.0 license means you can fork and hold a version if upstream moves faster than your change control allows.
Where Argus is the wrong tool
The clearest limitation is scope of ingestion. Elasticsearch is described as an optional alert source, and the README does not list the log sources, parsers or connectors that ship out of the box. Alert ingestion is listed as a capability, not as a catalog. If your environment generates most of its signal in a format Argus does not parse, you are writing the integration yourself through /api/v1/integrations/, which the README describes only as integration config and tests.
The second limitation is operational surface. A production deployment here means PostgreSQL, a Django service, a Next.js service, and optionally Elasticsearch, plus whatever the AI assistant calls out to. That is four or more moving parts for a team that may be one or two people. A hosted platform with a per-seat price is a legitimate alternative when your constraint is headcount rather than data control.
The third is the AI dependency. If you cannot send ticket content to an external model, or cannot run a local one, the assistant features are not usable and you are left with a conventional open source ticketing and correlation tool. That is still useful, but it is a different value proposition than the one the project name implies.
Alternatives and the actual difference in approach
The closest open source comparison is Wazuh, which pairs a host-based agent with a manager and indexer and ships its own rule language and decoders. The difference is where the logic runs. Wazuh expects an agent on the endpoint and centralizes detection in the manager; Argus has no described agent and instead treats alerts as ingested objects, with Sigma as the portable rule format and Elasticsearch as an optional source. If you already have endpoint telemetry flowing somewhere, Argus fits as the layer above it. If you need host-level file integrity monitoring and rootcheck, Wazuh is the one that ships that.
A second comparison is TheHive with Cortex, which covers case management and observable enrichment. The overlap is ticketing and enrichment; the difference is that TheHive is not a detection engine and does not ship correlation rules, while Argus bundles correlation and an orchestrator in the same Django project. Choosing between them is mostly a question of whether you want one application with an internal AI assistant or a set of composable services you wire together.
Neither comparison is settled by the README, which does not benchmark against either project or describe migration paths.
Editorial conclusion
Argus is worth a pilot if you want a single self-hosted console for alerts, tickets, CMDB and Sigma-based correlation, and if you have someone who can read Django settings and the k8s manifests rather than only clicking through the UI. Skip it if you need a drop-in managed detection service or if your analysts cannot be given MCP tool access under least privilege. Before adopting, verify three things in your own environment: that the docker-compose.prod.yml services match the data stores you intend to run, that SECRET_KEY, ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS are set from env.example rather than left at defaults, and that the /api/v1/mcp/ tool registry exposes only the tools you are willing to let the assistant call.
Community notes