BloodHound keeps two databases and one shared development password, and its homepage points at the paid product

One application, two databases, two collectors

The architecture is stated in one paragraph at the top of the README and it is unusually concrete. BloodHound is a monolithic web application: an embedded React frontend that draws the graph with Sigma.js, and a Go REST API backend behind it. It is deployed with a PostgreSQL application database and a Neo4j graph database. The data comes from outside the application, from the SharpHound and AzureHound collectors, which are separate projects in the same organisation. The claim made for the tool is that it uses graph theory to surface hidden and often unintended relationships across identity and access management systems, and that with the OpenGraph work it now reaches beyond Active Directory and Azure to other identity platforms. The README says plainly that both red and blue teams use it, attackers to find paths and defenders to find them first.

The graph database is a configuration choice

The README describes Neo4j as part of the deployment, but the development environment file says something more flexible. There is a setting for the graph driver, set to neo4j by default, with a comment naming the two accepted values as neo4j or pg. So the graph can live in Postgres instead, which changes what you have to operate: one database instead of two, and a different set of performance characteristics for the traversal queries the application exists to run. Everything else in that file is arranged around the assumption that both are present, with separate host names, ports, volumes and upgrade settings for the graph store, plus an administrative database front end on its own port. Reading the environment file rather than the README is the faster way to understand what a local run actually starts.

Every port binds to loopback and one password is reused

The shipped environment example is a good example of a development setup done carefully in one respect and sloppily in another. Carefully: every port is bound to the loopback address rather than to all interfaces, including the web port, the API port, the tool API port, the database ports, the graph database's bolt and web ports, and the identity provider's HTTP and HTTPS ports. A debug port is exposed as well, which is the profiling endpoint. Sloppily: the same example password string is reused for the administrative database front end, the graph database authentication, the application database user and the identity provider's database user and secret. That is fine for a local stack that nothing else can reach and unacceptable the moment a host name or a bind address changes.

The Go module is lowercase and depends on its own collector

The Go module file carries three details worth reading. The module path is all lowercase, github.com/specterops, while the repository itself is capitalised, so a self-import and a clone URL differ. The language directive names an exact patch release rather than a minimum. And there is a dependency replacement with a comment explaining it: the replacement is required for a migration tool whose driver is built against an extremely old build, which is the kind of note that tells you the constraint will outlive the tool. The requirement list includes the Azure collector itself as a library at a pinned version, so the collector ships inside the server module rather than being fetched at run time, alongside SAML and OpenID Connect libraries, an AWS SDK with IAM authentication and S3 support, a router, a semantic versioner and a template engine.

React types are pinned to 18.2 and one workspace skips the checks

The frontend manifest is named bloodhound-ce, marked private, and declares two workspace globs: the user interface directory and the JavaScript packages. Its scripts all delegate to the user interface workspace, and the cross-workspace ones use a foreach pattern rather than a per-package list. Three things stand out. An audit script runs with a severity floor and a production environment flag, so dependency checking is part of the normal workflow. An accessibility test and two reporting scripts exist, with the reports served and generated by Allure from a Playwright results directory. And a specific package, an eslint plugin for style props, is excluded by name from type checking, linting and formatting, which means that workspace is trusted rather than verified. The resolutions block pins several packages to exact versions.

Profiling, scanning and mock generation all have config files

The root of this repository is where the engineering practice shows. There is a continuous profiling configuration, a vulnerability scanner configuration, a mock generator configuration, a custom linter configuration, a file for the act tool that runs workflows locally, a Debian packaging directory, and a constraints file whose extension belongs to a dependency analysis tool. There are three compose files rather than one, split by purpose into development, testing and watch variants, with a directory of dockerfiles beside them and a directory of local harnesses. The build uses a justfile alongside a Go workspace template, which is a template rather than a committed workspace file, and the frontend uses a Yarn 4 workspace manifest with a matching Yarn configuration and release directory. Python appears only as a Black configuration with a line length of 120.

Two header templates and one exception clause

The licensing section is more nuanced than a single licence line. The README states that unless otherwise annotated by a lower-level licence file or licence header, all files in the repository are released under Apache 2.0, and reproduces the notice as a block of text rather than only linking it:

Copyright 2025 Specter Ops, Inc.

Licensed under the Apache License, Version 2.0
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

That exception clause has teeth here, because the root contains three licence-related files: the licence itself and two header templates, one for Go files and one general. The practical consequence for anyone reusing code is that the clause cuts both ways: the default is Apache 2.0, but a file carrying its own header may say otherwise, and the clause exists precisely because some files in a repository this size do.

The repository's homepage points at the enterprise product

Two small metadata facts tell you how this project is positioned. The homepage recorded for the repository is the enterprise product page on the vendor's site, not a community edition page and not the repository itself, which is what a commercially supported product with a free tier looks like from the outside. The release titles follow the same pattern: the newest patch is titled with the community edition name and the version, while the two release candidates that precede it carry only version numbers. The README itself has no installation commands at all. Running the software is delegated to a quickstart guide on the documentation site, with a Docker Compose example linked from the repository and a developer quick start in the wiki. The original tool is credited to three people by handle, and the community edition is attributed to the vendor team that also brought the enterprise product.

Editorial conclusion

BloodHound Community Edition is a defensible choice if your environment is Active Directory or Azure and you want to see privilege relationships as a graph rather than as a list of group memberships, and the collectors are what do the collection rather than anything you have to script. Three things to check before you deploy it. The graph database is not fixed: the development environment selects between Neo4j and Postgres, so decide which one you are committing to and size it accordingly. Every port in the shipped environment file binds to loopback, which means none of it is reachable until you change that deliberately. And the licences are layered, with a general Apache 2.0 statement plus two header templates and a lower-level exception clause, so check the directory you are copying code out of.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SpecterOps/BloodHound on GitHub