Taranis AI: an OSINT pipeline that turns news feeds into analyst-reviewed reports

The problem Taranis AI addresses, and who it is actually for

Most OSINT tooling stops at collection. You get a feed reader, a scraper, or an alerting bot, and the analyst still does the reading, the deduplication and the write-up by hand. Taranis AI targets that middle layer. The README describes it as collecting unstructured news articles from sources such as websites, running Natural Language Processing over them to improve content quality, and letting analysts refine the result into structured report items that become deliverables such as PDF files. The unit of work is not the article, it is the report.

That framing tells you who the project is for. It assumes a division of labour: collectors and bots do the ingestion and enrichment, a human does the judgement. Teams with no analyst in the loop get a queue nobody drains. The topics list (cybersecurity, secops, osint, nlp) and the feature set point at CERT-style or threat-intelligence desks rather than at a journalist tracking a single beat. The hardware guidance reinforces this: 16 GB RAM, 4 CPU cores and 50 GB of disk to use all NLP features, against 2 GB, 2 cores and 20 GB without them. That is a server, not a laptop side project.

How the pieces fit: core, worker, frontend and the message broker

The architecture is a set of cooperating services rather than a monolith. An ingress container runs Nginx as a reverse proxy and is the entrypoint. The core service talks to the database and exposes REST endpoints to both the frontend and the workers. The frontend is Flask with HTMX and tailwindcss. The worker service runs RQ workers that provide collectors, bots, presenters and publisher features. Redis acts as message broker and job queue, PostgreSQL is the primary supported database with SQLite also supported, and Centrifugo handles realtime.

The data flow follows from that split. A collector in a worker pulls from a source such as a website, RSS or Atom feed, Mastodon, MISP or Request Tracker, and creates a news item. Bots and presenters transform and enrich it. The item lands in the core database, where analysts see it through the frontend and promote it into a structured report. Because the queue is Redis and the workers are RQ, the pipeline is asynchronous: a slow collector does not block the API, but it also means a stalled worker looks like silence rather than an error. The repository directory layout matches the service table, with src/core, src/ingress, src/frontend, src/models and src/worker, plus a docker directory holding an example docker-compose file. Pydantic models in src/models validate inputs and outputs, which is the main contract between services.

One detail worth noting for operators: the README distinguishes two health endpoints. /api/isalive is a lightweight liveness probe that only confirms that the core API process is responding. /api/health is the operational one, reporting each dependency as up, down or n/a, returning 503 if any dependency is down and 200 otherwise. Wiring a load balancer to /api/isalive alone will keep a broken deployment in rotation.

Installing Taranis AI with Docker and making a first collection

The README does not give inline install commands. It points production deployments at the deployment guide using docker compose on taranis.ai, and the repository ships an example docker-compose file under docker/. That is the supported path; there is no documented pip install of the whole platform. The README also notes that deployments still on Celery and RabbitMQ should read the RQ migration guide in dev/rq_migration_guide.md, which is a signal that older installations are expected to move onto the Redis-backed RQ workers described in the service table.

The REST API is specified by an OpenAPI 3.1 document at src/core/core/static/openapi3_1.yaml, and the README states it can be accessed in a running installation under config/openapi. Use that path to confirm the API surface your version actually exposes before scripting against it. Core exposes two unauthenticated health endpoints: /api/isalive confirms only that the core API process is responding, while /api/health reports the status of core dependencies as up, down or n/a and returns 503 if any dependency is down and 200 otherwise. Point your checks at the second one, not the first.

For collection, the README documents dedicated setup notes for two sources: docs/intelowl.md for IntelOwl enrichment and docs/mastodon.md for Mastodon collection, including access-token HTTPS requirements and the choice between complete and latest cursor modes. Those two documents are where to look first, because source configuration is the part most likely to differ from a generic compose tutorial, and the README does not document a single generic collector configuration that covers every source.

Where Taranis AI gets in your way

The resource floor is the first obstacle. Without NLP the project asks for 2 GB of RAM, 2 CPU cores and 20 GB of disk; with all NLP features the README states at least 16 GB, 4 CPU cores and 50 GB. That is a meaningful jump, and it is not a soft recommendation you can ignore by disabling a flag at runtime. If your host is a small VPS, you are choosing between the stripped-down configuration and a different tool.

The second issue is that the project is a platform, not an application. Four services in the main table plus database, broker and realtime component have to be running before the first article appears. Every one of them is a failure point, and the README documents health reporting for core dependencies but does not document rollback, backup or restore procedures. If you need to know how to recover a corrupted report store, the README is silent and you will be reading the deployment guide instead.

The third is the queue. Because collection runs through RQ workers on Redis, a collector that fails repeatedly does not necessarily surface as a user-visible error. You need to watch worker state, not just the API. Teams without anyone who owns that monitoring will find articles quietly missing and blame the source.

Finally, the collaborative sharing feature is explicitly labelled experimental in the README. Story-level sharing between Taranis AI instances via MISP, or directly between Taranis AI and MISP, is not something to build a cross-organisation process on without testing it yourself.

Taranis AI compared with a plain feed reader plus a script

The realistic alternative for many teams is not another OSINT platform. It is an RSS reader, a scheduled Python script that writes to a database, and a shared document for write-ups. That stack is trivial to run and has no hardware floor worth mentioning.

The difference is where the work happens. In the script approach, enrichment is whatever you wrote, the analyst's notes live outside the tool, and the report is assembled by hand in a word processor. Taranis AI moves all three into one system: NLP enrichment runs in the worker, the analyst refines items inside the frontend, and the deliverable is generated as a structured report or PDF by a presenter or publisher. The cost of that integration is the operational surface described above.

A second alternative is to use Taranis AI purely as a collector and ignore the analyst workflow, pushing news items into an existing system through the REST API. The OpenAPI spec makes that possible, but you would be running the full stack, including the database and broker, to use a fraction of it. If collection is all you want, a smaller scraper is the better fit; Taranis AI earns its complexity only when the report stage is also inside the tool.

Maintenance, releases and the EUPL-1.2 licence

The last push to the default branch was on 2026-09-15, and the most recent releases are 1.4.4 on 2026-08-24, 1.4.3 on 2026-08-13 and 1.4.2 on 2026-07-20. That is a steady cadence of patch releases over roughly two months, which matters for upgrade planning: you should expect to move between minor versions more than once a quarter, and each move means rebuilding containers from the compose file rather than patching files in place.

The upgrade cost is tied to the service split. A version bump touches core, worker, frontend and ingress images together, and the database schema is owned by core. The README does not document a migration procedure or a rollback path, so the practical safeguard is a database backup taken before you pull new images. Budget for that step in your release process; it is not optional when the project does not document the reverse operation. The repository also carries maintainer release steps in docs/releasing.md and container and Python dependency SBOM scope and attestations in docs/sbom.md, which are the two files to read if your organisation needs provenance records for the images it runs.

On licensing: the project is released under the European Union Public Licence, EUPL-1.2, and the README states this explicitly. EUPL is a copyleft licence, and it is notable that it is a European licence drafted with compatibility in mind, which is why the repository also carries an EU funding acknowledgement through the Connecting Europe Facility. If you plan to redistribute modified versions, or to embed Taranis AI in a product you ship, read the licence text at the link the README gives and get your own legal review. Nothing here is legal advice, and the practical questions (what counts as a derivative work, what you must publish) are exactly the ones a lawyer should answer.

Editorial conclusion

Adopt Taranis AI if you already run a security or intelligence desk with analysts who will work a review queue, and you can give the NLP stack 16 GB of RAM, 4 CPU cores and 50 GB of disk. Do not adopt it if you want a single-binary news reader, if you have no PostgreSQL or Redis operational experience, or if you expect the collectors to run without tuning. Before committing, verify three things: that the docker compose deployment in the deployment guide covers the sources you need (websites, RSS/Atom, Mastodon, MISP, Request Tracker), that the /api/health endpoint returns 200 with all dependencies up in your environment, and that the EUPL-1.2 copyleft terms are acceptable to whoever owns your distribution plans.

Frequently asked questions

Official sources

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