DFIR-IRIS
Live demo
v3.0.0-beta.1 · in final testing

Same mission. 
New airframe. 

Everything you know is still in there. Almost everything underneath it has been rebuilt — and there is a new room for the days it all goes wrong. Six stops from v2.4.29 to v3.

The swap

What comes off, 
what goes on. 

Six things you are running today, and what replaces them.

  • v2.4.29
    Interface
    Jinja pages and a jQuery bundle, served by the Flask app
    v3.0.0-beta.1
    A SvelteKit application running as its own service
  • v2.4.29
    Coordination
    Comments on a case, and a chat window beside it
    v3.0.0-beta.1
    War rooms — live chat, teams, tasks, timelines and sitreps
  • v2.4.29
    Alerts
    A queue you filter, and merges you make by hand
    v3.0.0-beta.1
    Clusters, condition rules and investigation flows
  • v2.4.29
    API
    A REST surface documented by hand, page by page
    v3.0.0-beta.1
    ~211 new v2 endpoints and an OpenAPI 3.1 spec built from the code
  • v2.4.29
    Machines
    Nothing an assistant could safely talk to
    v3.0.0-beta.1
    A built-in MCP server, off until an admin turns it on
  • v2.4.29
    Database
    PostgreSQL 12, md5 authentication
    v3.0.0-beta.1
    PostgreSQL 18 and scram-sha-256, with a scripted migration
Six stops

What actually 
changed. 

  1. 01 ·The cockpit

    The whole interface, 
    rebuilt. 

    The UI the Flask app used to render is gone. In its place is a SvelteKit application that ships as its own container and talks to the backend the same way your scripts do — over the API.

    • SvelteKit, server-rendered
    • its own container
    • 460 Svelte components
    • 29 end-to-end suites
    107
    templates retired
  2. 02 ·War roomsnew

    A room for 
    the bad days. 

    A case is where an investigation lives. A war room is where a crisis gets run — one live space with the people, the decisions and the clock all in it, and everything said there landing in the record.

    • threads, polls, reactions
    • lead · responder · observer
    • versioned sitreps
    • room tasks, timelines and notes
    • open → active → standby → closed
    14
    slash commands
  3. 03 ·Alertsnew

    Alerts arrive 
    with a plan. 

    Clusters gather the noise into one story. Rules decide what happens to it. And investigation flows attach the playbook before an analyst has even opened the thing.

    • alert clusters
    • condition-based rules, scoped and prioritised
    • ordered flow steps
    • required steps
    • progress tracked per analyst
  4. 04 ·The API

    A bigger API — 
    and a real spec. 

    v3 adds around 211 endpoints under /api/v2 and generates its OpenAPI document straight from the code, so the docs cannot drift from the routes. Four legacy paths retired; the rest still answer.

    • OpenAPI 3.1
    • 368 documented paths
    • browsable inside IRIS
    • your v1 integrations keep working
    +211
    v2 endpoints
  5. 05 ·MCPnew

    IRIS talks to 
    machines. 

    A Model Context Protocol server is built in, so an assistant can work a case through exactly the permissions its analyst has — and nothing beyond them. It stays dark until an admin says otherwise.

    • off by default
    • every call checked against the ACL
    • admin tool allowlist
    • per-user opt-out
    50
    MCP tools
  6. 06 ·Foundations

    Rebuilt where 
    you can't see it. 

    A layered backend with the boundaries enforced in CI, a modern database under it, and — if you want them — errors you can actually chase, on a server you own.

    • PostgreSQL 12 → 18
    • one IRIS_VERSION pins the whole stack
    • rollback-safe migration script
    • opt-in, self-hosted error reporting
Unchanged

The parts you rely on, 
left alone. 

A rebuild is only worth it if the day job survives it. Your data comes across, your integrations keep answering, and IRIS still runs on your own metal under the same licence.

  • Cases
  • Alerts
  • IOCs
  • Assets
  • Evidence
  • Timelines
  • Tasks
  • Notes
  • The graph
  • Dashboards
  • Reports
  • Modules and hooks
  • RBAC
  • OIDC
  • Self-hosted
  • LGPLv3
Before you go

One hop from v2.4.29. 

  1. Step 1
    Take both backups

    A cold volume tarball and a pg_dumpall. The engine jump is not reversible in place.

  2. Step 2
    Run the script

    upgrade-db-pg12-to-pg18.sh is idempotent — stop it and start it again safely.

  3. Step 3
    Bring the stack up

    docker compose up -d. Alembic migrates the schema on the first boot.

Read the migration guideOperator runbook

v3 is on final approach. 
Fly it before it lands. 

The beta is live and the migration path is written. Try it on a copy of your data, tell us what breaks, and it gets fixed before release.

Read the docsContribute on GitHubTalk to us