Two unauthenticated health endpoints, one of which reports the dependency topology

Both health endpoints are unauthenticated, and one returns the dependency state

The README names two health-related endpoints and is explicit that neither requires authentication. `/api/isalive` is described as a lightweight liveness probe that only confirms the core API process is responding, which is the conventional split. `/api/health` is the one to think about: it is the operational endpoint, it reports the status of core dependencies as `up`, `down` or `n/a`, and it returns 503 if any dependency is down and 200 otherwise. On an ordinary service that is an inconvenience. On a system that scrapes, enriches and stores investigative material it is a map, because an unauthenticated caller learns which of the database, the queue and the worker tier are failing at the moment of asking, and a `n/a` entry names a dependency that exists but is not being probed. Two details widen that surface. The OpenAPI 3.1 description is committed at `src/core/core/static/openapi3_1.yaml` and is served from inside a running installation under `config/openapi`, so every route is documented for whoever can reach the proxy.

The queue moved from Celery to RQ, and both stacks appear in the same file

The Getting Started section points production deployments at a docker compose guide, then adds a second path for a specific case: existing Celery and RabbitMQ deployments are sent to an RQ Migration Guide kept in the repository at `dev/rq_migration_guide.md`. So the project has already changed its broker, and the README still addresses installations running the old one. The support services table shows where it landed, listing Redis as both the message broker and the job queue for RQ workers. RabbitMQ appears nowhere in that table, which tells you the migration is not optional for anyone starting fresh; the guide exists so a running installation is not abandoned. RQ itself appears in two other places: the worker service is described as RQ workers offering collectors, bots, presenters and publisher features, and the presenter role is what turns a draft into the PDF output the workflow ends with.

NLP is the difference between 16 GB of RAM and 2 GB

The hardware section gives two profiles and the gap is not marginal. To use all NLP features the stated minimum is 16 GB of RAM, 4 CPU cores and 50 GB of disk. Without NLP it is 2 GB of RAM, 2 CPU cores and 20 GB of disk. So the enrichment step described as AI-enhanced analysis, which is the part of the pipeline that automatically enhances and enriches collected articles, is an eightfold jump in memory and two and a half times the storage. The lower profile is still a working product rather than a demo: collection, the analyst workflow that converts unstructured news into structured report items, and multi-format output into structured reports and PDF files all live outside the NLP stage. The practical reading is that the platform can start small and be upgraded into AI processing later, which is unusual for a product named after the AI.

The analyst chat is per-user, persistent, and scoped to authorised stories

One feature in the list stands apart from the rest, because it is the only one described as needing an external model, and it is marked optional. The optional analyst chat provides persistent, per-user conversations that can answer general questions or search the stories the analyst is authorised to see, through a separately configured OpenAI-compatible Responses API. Three separate design choices are packed into that sentence. Persistence means conversation state outlives a session and belongs to a user rather than a request. The separately configured API means the model endpoint is not implied by the platform and has to be pointed at something, which is also how you keep inference inside your own boundary. And the authorisation scope on search is the part that matters, because a chat interface over collected intelligence is exactly where an over-broad filter would leak, and the stated behaviour is that the search is bounded by what that analyst may see.

Six collectors, one of which is a ticketing system

The worker is the component that touches the outside world, and its sources are enumerated in the directory listing: websites, RSS and Atom feeds, Mastodon, MISP, and Request Tracker, with the output being news items. Request Tracker is the notable one, since it is a ticketing system rather than a news source, and its presence says the collectors are aimed at wherever an organisation's reports actually arrive rather than only at published articles. Three integrations have their own documentation files rather than a section in the README: IntelOwl enrichment is set up through `docs/intelowl.md`, Mastodon collection through `docs/mastodon.md`, and that Mastodon document covers access-token HTTPS requirements plus the difference between a complete cursor mode and a latest cursor mode. That distinction is the one to read before deploying, because it decides whether a collection run backfills history or only takes what is new.

MISP sharing is the one feature carrying an experimental label

Most of the feature list is written in the present tense, but the collaborative threat intelligence entry is marked experimental. It supports Story-level sharing, and it does so in two shapes: between two Taranis AI instances through MISP, or directly between Taranis AI and a MISP instance. Story-level rather than report-level or item-level is the granularity choice, and it is the same unit the collectors produce as news items, so sharing tracks the analyst's working objects. Two operational files sit alongside it that are easy to miss in a README this short: `docs/releasing.md` for maintainer release steps, and `docs/sbom.md` for the scope of the software bill of materials covering container and Python dependencies, together with attestations. A provenance document scoped to both the image and the Python dependency set is the right shape for something meant to be deployed by other agencies.

EUPL copyleft, a Flask and HTMX frontend, and a heading with nothing under it

The licence is the European Union Public Licence 1.2, and `LICENSE.md` sits at the root. EUPL is copyleft, so an organisation that modifies the platform for its own use has a question to answer about distribution that a permissive licence would not raise, and for a national CERT tool that is often the whole point of forking. The service layout is Nginx as an ingress reverse proxy, a Flask frontend using HTMX and tailwindcss rather than a single-page application, a core service holding the REST endpoints for both the frontend and the workers, and the worker service itself, with Postgres as the primary citizen database and SQLite also supported. Development and packaging are Nix based, with `flake.nix`, `flake.lock` and a `taranis.nix`, alongside `tox.ini` and a pre-commit configuration. The lineage is stated plainly, from Taranis3 and Taranis-NG, both of which come from European CERT organisations. The README's final heading is EU Funding, and nothing follows it.

Editorial conclusion

It fits a CERT, an analyst team or a newsroom that already has a Postgres and Redis estate and wants a platform where a human still turns collected articles into a report rather than publishing a model's summary. It does not fit a small team wanting a single-container install, since the architecture is four services behind a reverse proxy with its own realtime server, and it does not fit anyone planning to modify it internally without publishing, because EUPL-1.2 is a copyleft licence. Before exposing an instance, decide whether the unauthenticated dependency status endpoint is acceptable on your network, because on a system ingesting sensitive material it names which components are down, and confirm the Mastodon cursor mode matches the completeness you need.

Frequently asked questions

Official sources

1. License: EUPL-1.2
2. Project website
3. README
4. Releases
5. taranis-ai/taranis-ai on GitHub