Faraday: a multiuser vulnerability console for scanner output

The problem Faraday solves: scanner output that never reaches a shared record

A penetration test or a continuous scan produces files. Burp writes XML, Nessus writes its own export, nmap writes text. Each file is readable on its own and useless next to the others. The README frames this as two separate jobs: designing ways to get new information, and keeping track of findings so remediation actually moves. Faraday takes the second job. It aggregates and normalizes what you load, then presents it through visualizations the README says are useful to managers and analysts alike. The audience is therefore a team, not a solo operator. The README states the project was made to let you take advantage of community tools in a truly multiuser way. If two testers work the same target on the same day, their findings land in the same workspace instead of two laptops.

How the pieces fit: server, workers, Postgres, Redis and the plugin layer

The repository layout shows a Flask application with Celery workers, and docker-compose.yaml wires the parts explicitly. The db service is postgres:12.7-alpine, the redis service is redis:8.4-alpine, and a faraday-default-worker container runs the command faraday-worker with PGSQL_HOST, PGSQL_PASSWD, PGSQL_DBNAME and REDIS_SERVER passed as environment variables. PostgreSQL holds the normalized findings; Redis backs the queue; the worker consumes jobs. The plugin layer is a separate package, faraday-plugins, pinned in requirements.txt as faraday-plugins>=1.27.0,<2.0.0 and in pyproject.toml as faraday-plugins>=1.30.0,<2.0.0. The README splits plugins into two kinds: console plugins that interpret the output of a tool you execute, and report plugins that import artifacts such as XML or JSON. That split explains the two entry points a user sees, running a tool through faraday-cli or uploading a file that already exists. Faraday Agents Dispatcher is a separate repository that lets the platform drive scanners on remote machines and pull the results back.

Installing Faraday with docker-compose and running your first console scan

The README calls docker-compose the easiest way to get running. It fetches the compose file from the master branch and starts the stack:

wget https://raw.githubusercontent.com/infobyte/faraday/master/docker-compose.yaml
docker-compose up

The compose file pulls index.docker.io/faradaysec/faraday:latest and mounts a Docker volume at /home/faraday/.faraday, so data survives container restarts. The server listens on port 5985. The README says that in your browser you can go to http://localhost:5985 and log in with faraday as the username and the password printed by the installation process.

If you prefer a plain container, the README requires a Postgres instance first and shows the environment variables to point at it:

docker run \
  -v $HOME/.faraday:/home/faraday/.faraday \
  -p 5985:5985 \
  -e PGSQL_USER='postgres_user' \
  -e PGSQL_HOST='postgres_ip' \
  -e PGSQL_PASSWD='postgres_password' \
  -e PGSQL_DBNAME='postgres_db_name' \
  faradaysec/faraday:latest

The PyPI path is three commands, with initdb creating the schema before the server starts:

pip3 install faradaysec
faraday-manage initdb
faraday-server

For the first real use, install the CLI and push a scan into a named workspace. The README gives this example, which runs nmap and sends the parsed result to the workspace test:

pip3 install faraday-cli
faraday-cli tool run "nmap www.exampledomain.com"

The CLI prints the nmap output as it runs, then reports the workspace it sent data to and a completion line. Existing artifacts go in through the report path instead, for example faraday-cli tool report burp.xml. Both paths end in the same normalized store, which is the point of the design.

Where Faraday stops helping: state, dependencies and the wrong-sized team

Faraday is a service, not a command. It needs PostgreSQL and Redis, and the compose stack adds a worker container on top of the server. On a laptop that is three processes before you have scanned anything, which is a poor trade if you are triaging a single nmap run. The installation options also diverge in what they leave you responsible for. The plain docker run path expects an existing database and the right PGSQL_ variables; the Debian and RPM packages expect you to add your user to the faraday group and start faraday-server through systemd. The README does not document a rollback or downgrade procedure for the database schema, and alembic migrations are in the dependency list, so schema changes are part of the upgrade path. Treat the database as something to back up before a version jump rather than something you can reverse casually. Finally, the value of the platform is proportional to the number of tools feeding it. With one scanner and one analyst, the normalization layer has nothing to reconcile.

Faraday compared with running the scanners and reading their reports directly

The obvious alternative is to run nmap, Burp or Nessus yourself and read each report as it comes. That approach has no server, no database and no migration risk, and for a single engagement it is faster. The difference is what happens on the second run. Direct scanner use produces a new file each time, and comparing the two is manual work. Faraday normalizes both into the same schema, which is what makes the visualizations in the README possible and what makes the multiuser claim meaningful. The trade is that you accept a Python 3.11 application, a PostgreSQL dependency and a plugin package that must recognize your tool's output format. If your scanner is not in the plugin list, the direct route still works and Faraday adds nothing. The README points anyone missing a plugin at the faraday_plugins repository for a pull request.

Licence and the cost of keeping Faraday current

Faraday is GPL-3.0-only, stated in pyproject.toml and shipped as LICENSE in the repository root. That matters if you plan to modify the server and distribute it, because the GPL carries obligations that a permissive licence does not. Running it internally to manage your own findings is a different situation from redistributing a modified build, and the licence text, not this article, is what governs. On maintenance, the last push was on 2026-09-17, and the most recent release is v5.24.2 from the same day, following v5.24.0 on 2026-09-03 and v5.23.2 on 2026-08-20. Releases arrive on a roughly two-week cadence in that window. The upgrade cost sits in two places: the Python dependency pins, which are tight (celery==5.4.0, werkzeug==2.3.8, elasticsearch>=7.16.3,<8), and the database migrations. The tight pins are a stability choice and also mean that a transitive dependency conflict is resolved by the project, not by you.

Editorial conclusion

Adopt Faraday if several people already run scanners and the results live in scattered XML and JSON files that nobody reconciles. Skip it if you only need to read one nmap run once, or if you cannot run PostgreSQL and Redis alongside the server. Before committing, verify that your scanner's output format appears in the plugin list, and check that the host serving port 5985 is reachable only by the people who should see the findings.

Frequently asked questions

Official sources

1. infobyte/faraday on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases