UTMStack correlates log data before ingestion, and v10 has a sunset date

Correlation happens before the data is stored

UTMStack is described as a unified threat management platform that merges SIEM and XDR technologies, and the approach it claims as its own is real-time correlation of log data, threat intelligence and malware activity patterns from multiple sources, which the README says enables the identification and halting of complex threats that use stealthy techniques. The architectural claim that matters is in the Why section, and it is a single sentence. Correlation happens before data ingestion, reducing workload and improving response times. That is a different pipeline shape from the usual collect, store, then query. If the correlation runs on the ingest path, the work is done once per event rather than once per query, and the storage layer below it is holding data that has already been judged. The feature list follows the same shape, with log management and correlation, threat detection and response, threat intelligence, alert investigation, file classification, SOC AI-Powered Analysis and security compliance as the seven pillars.

The first thing the README tells you is that v10 is going away

The repository opens with an upgrade notification rather than a pitch, and that is a reasonable choice for a platform with a versioned architecture. UTMStack v10 will be sunset on December 5, 2026. As of today, v10 is no longer receiving any new features and will only receive critical fixes until the sunset date, and after December 5, 2026, v10 will no longer be supported. All users must upgrade to v11 as soon as possible using the upgrade package, with the full guide at docs.utmstack.com/upgrade. The release list makes the churn visible. There is a v11.3.0 marked as a pre-release from 2026-10-19, a v11.2.16 from 2026-10-01, and a v12.0.0 from 2026-09-29, and the default branch of the repository is v11. So there is a v12 in the wild while the default branch and the upgrade path point at v11, and anyone deploying needs to decide which line they are on before they touch the installer.

Storage sizing is a first class part of the installation

The installation guide provides instructions for Ubuntu 22.04 LTS, and the sizing section before it is the part that tells you whether this fits your estate. The assumptions are stated up front, that 60 data sources generate approximately 100 GB of monthly data. Two storage definitions follow, hot log storage for data that is not archived and can be accessed for analysis at any time, and cold log storage for archived data that should be restored before it is accessed. The required resources for one month of hot storage are then tabulated, and the tiers are linear in data sources: 50 data sources at 120 GB needs 4 cores, 16 GB RAM and 150 GB of disk; 120 sources at 250 GB needs 8 cores, 16 GB and 250 GB; 240 at 500 GB needs 16 cores, 32 GB and 500 GB; 500 at 1000 GB needs 32 cores, 64 GB and 1000 GB. The tiers may be combined to allocate resources based on the number of devices and the retention you want, and one limit is called out in capitals, since going above 500 data sources or devices requires adding secondary nodes for horizontal scaling.

Installing means downloading and running an installer script

The installation can be performed using an installer file or an ISO image, and the instructions given are for the installer file option. The preparation steps are short, and they are the first commands a new operator runs:

- Update packages list: `sudo apt update`
- Install WGET: `sudo apt install wget`
- Download the latest version of the installer by typing `wget http://github.com/utmstack/UTMStack/releases/latest/download/installer`

Then the operator changes to the root user, makes the file executable with chmod +x installer, and runs the installer without parameters. The default Ubuntu Server credentials are given as user utmstack with password utmstack, and the README notes that once UTMStack is installed you use admin as the user with the password generated during the installation for the default account. The distinction matters because the printed credentials are the underlying system account while the web login uses a generated secret, and anyone deploying this should change both before the platform faces real data.

The default Ubuntu Server credentials are given as user utmstack with password utmstack, and the README notes that once UTMStack is installed you use admin as the user with the password generated during the installation for the default account. The distinction matters because the printed credentials are the underlying system account while the web login uses a generated secret, and anyone deploying this should change both before the platform faces real data.

The repository is a set of services rather than one application

The top level of the repository describes how the platform is assembled, and it is a list of services rather than a single codebase. There is an agent/ directory and an agent-manager/ for the collectors that talk to the systems being monitored, a backend/, a frontend/, shared/ and etc/ for common code, filters/ and rules/ for the detection and processing logic, plugins/, and the pieces that reach outside the stack, an as400/ directory for that platform, a user-auditor/, a utmstack-collector/ and a web-pdf/. There is an event_processor.Dockerfile at the root, which is a good clue about the deployment shape, and the README states that UTMStack services are isolated by containers and microservices with strong authentication. The docs/ directory and an AGENTS.md sit alongside the usual files such as SECURITY.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md. If you are evaluating this as a platform, the directory list is the fastest way to understand that you are adopting a distributed system with its own operational surface, not a program you install and configure.

The security section makes specific, checkable claims

The Security section of the README is short and concrete, which is unusual for a project of this size. The code is reviewed daily for vulnerable dependencies, and penetration testing is performed on the system yearly and after every major release. All data in transit between agents and the UTMStack servers is encrypted using TLS. The services are isolated by containers and microservices with strong authentication, and connections to the server are authenticated with a plus 24 characters unique key, which is a mouthful but a concrete scheme. User credentials are encrypted in the database and protected by fail2ban mechanisms and 2FA. The daily dependency review and the yearly penetration test are the two claims worth following up on, because they are the ones that determine whether the platform is safe to point at a production network.

Where the platform is the wrong tool

Three cases stand out. The first is a small environment with a handful of servers, because the sizing model starts at 50 data sources of hot storage and 4 cores, and a single log host does not need a correlation engine that runs before ingestion. The second is a team that wants managed detection, since UTMStack is software you run and the README's own pages, the demo, the videos and the documentation site, exist to support the operator rather than the analyst. The third is a team unwilling to own an AGPL-3.0 codebase, since the licence means modifications you host or distribute have to be offered back under the same terms, and that is a conversation with a legal team rather than a technical one. Against a commercial SIEM, the difference in approach is that you own the data, the correlation and the upgrades, and in exchange you own the sizing, the patching and the v10 migration.

Editorial conclusion

Adopt UTMStack if you want to run your own SIEM and XDR platform, correlate log data before it lands in storage, and keep the data inside your own environment under an AGPL licence rather than sending it to a vendor. Do not adopt it if you need something that runs without hardware planning, because the installation guide assumes a sized cluster and a hot and cold storage model, and do not stay on v10, which stops receiving features now and stops being supported on December 5, 2026. Before you deploy, size the storage tiers for your data source count, read the upgrade guide at docs.utmstack.com/upgrade, and check which release you are pinning, since v11.3.0 is marked as a pre-release while v12.0.0 already exists.

Frequently asked questions

Official sources

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