BloodHound CE: mapping identity attack paths with a Postgres and Neo4j backend

What BloodHound CE actually solves for identity teams

Manual review of group membership and delegated permissions does not scale past a few hundred principals. BloodHound's premise is that privilege relationships form a graph, and that the interesting findings are paths through that graph rather than individual misconfigurations. The README states that the project "leverages graph theory to reveal hidden and often unintended relationships across identity and access management systems." A single nested group membership is unremarkable; the chain from a low-privilege account to domain admin through three nested groups and a delegation setting is the thing an analyst cannot hold in their head.

The audience is split. Red teams use it to find routes to privileged access. Blue teams use the same graph to find and close those routes before someone else does. The README frames both sides explicitly. The project also extends past Active Directory and Azure through OpenGraph, which the README describes as supporting analysis across "diverse identity platforms" via a library of integrations. That extension is the part worth checking against your own environment, because the OpenGraph library is a separate documentation set from the core AD workflow.

The architecture: React, Go, Postgres and Neo4j

The README calls BloodHound "a monolithic web application composed of an embedded React frontend with Sigma.js and a Go based REST API backend." The frontend is embedded, so you are not deploying a separate static site and API tier. Sigma.js handles graph rendering in the browser, which matters because the visual output is the product, not a report.

Two databases sit underneath. Postgres is the application database, holding users, configuration and job state. Neo4j is the graph database that stores the nodes and edges the collectors produce. That split is the main operational cost of running BloodHound CE. The .env.example confirms it: BH_POSTGRES_USER, BH_POSTGRES_PASSWORD, BH_POSTGRES_DB, BH_NEO4J_AUTH and BH_NEO4J_ALLOW_UPGRADE are all separate settings, and GRAPH_DRIVER is documented with the comment "use neo4j or pg," meaning the graph backend is a selectable driver rather than a fixed dependency.

Data flows in from outside the repository. The README names SharpHound and AzureHound as the data collectors, and both live in their own SpecterOps repositories. BloodHound CE does not collect anything itself. If you cannot run a collector against the target environment, the application has nothing to display.

Installing BloodHound CE and loading a first dataset

The README does not contain install steps. It says: "Please refer to the Quickstart Guide for BloodHound Community Edition," linking to the BloodHound documentation site. The repository does ship an examples/docker-compose/ directory with its own README, which is the concrete starting point inside the repo.

The .env.example at the repository root shows the shape of a local configuration. These are the port and credential variables it defines:

WEB_PORT=127.0.0.1:80
BH_API_PORT=127.0.0.1:8080
GRAPH_DRIVER=neo4j
BH_NEO4J_AUTH=neo4j/bloodhoundcommunityedition
BH_NEO4J_PORT=127.0.0.1:7788
BH_POSTGRES_USER=bloodhound
BH_POSTGRES_PASSWORD=bloodhoundcommunityedition
BH_POSTGRES_DB=bloodhound
BH_POSTGRES_PORT=127.0.0.1:6543

Every value above binds to 127.0.0.1, and the credentials are the literal defaults from the example file. That is deliberate for a local harness and wrong for anything reachable from a network. The example also sets BH_NEO4J_ALLOW_UPGRADE=true, which lets the Neo4j container migrate its store on start.

Once the stack is up, the workflow is collection then ingest. Run SharpHound against an Active Directory environment or AzureHound against an Azure tenant, then upload the resulting data through the BloodHound CE interface. The documentation site, not the README, covers the upload and query steps.

Where BloodHound CE is the wrong tool

The dependency footprint is the first constraint. A Postgres instance and a Neo4j instance is a lot of moving parts for a question that a one-off LDAP query might answer. If your goal is to check whether a specific group has unexpected members, BloodHound is overkill and you will spend more time on the deployment than on the answer.

Second, the collectors are out of scope for this repository. SharpHound and AzureHound are separate projects, and the README treats them as inputs rather than components. A team that wants a single artifact to run, collect and report has to assemble that from at least three repositories.

Third, the README does not document rollback, backup, or upgrade procedures for the databases. BH_NEO4J_ALLOW_UPGRADE exists, but the README is silent on what happens to an existing graph when a new version starts against it. The release cadence is fast, with v9.8.0-rc1, v9.7.1 and v9.7.1-rc1 all published within the same week in September 2026. That pace makes a tested restore path a prerequisite rather than a nice-to-have, and the README does not supply one. Verify it against the documentation site before pointing BloodHound at a production directory.

BloodHound CE compared with a directory query tool

The obvious alternative for many teams is a scripting approach built on LDAP queries or a cloud identity API, run ad hoc or on a schedule. The difference is not effort, it is the model. A query returns a set of objects that match a filter. BloodHound builds a persistent graph and then answers path questions across it, which is why the graph database exists at all.

That distinction has a practical consequence. A query-based approach is stateless and cheap to rerun; you get today's answer and nothing accumulates. BloodHound CE accumulates. Each collection adds or updates nodes and edges, and the value of the tool grows with the completeness of the graph rather than with the cleverness of any single query. The cost is that you now own two databases, a data retention question, and an ingest pipeline.

A second alternative is the commercial BloodHound Enterprise product from the same vendor, which the README links from the homepage. The README describes BloodHound CE as "created and maintained by the SpecterOps team who also brought you BloodHound Enterprise." The README does not enumerate feature differences between the two, so any comparison beyond that shared authorship would be speculation.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. The release history shows release candidates and stable releases interleaved, with v9.8.0-rc1 published two days before that push. Anyone running BloodHound CE should expect to track releases rather than pin to a version for years.

Licensing is straightforward at the repository level. The README states that, unless a lower-level LICENSE file or license header says otherwise, "all files in this repository are released under the Apache-2.0 license." The go.mod and pyproject.toml files both carry Apache-2.0 SPDX headers, which is consistent with that statement. Apache-2.0 permits commercial and closed-source use and includes a patent grant. It does not cover the separate collector repositories, which have their own licence files. This is a description of what the repository states, not legal advice; check the LICENSE file and any per-directory headers yourself.

The upgrade cost is dominated by the databases. Neo4j store migrations, Postgres schema changes and the GRAPH_DRIVER setting all interact, and the README does not document the supported upgrade path between major versions. Budget for a staging environment that mirrors your graph size before you upgrade a production instance.

Editorial conclusion

Adopt BloodHound CE if you already have a directory or cloud identity estate to map and can run Postgres plus Neo4j alongside it. Do not adopt it as a lightweight single-host scanner, and do not expect the README to walk you through deployment: verify the Quickstart Guide, the examples/docker-compose/README.md, and the GRAPH_DRIVER setting before you commit to a graph backend. The collectors, SharpHound and AzureHound, are separate repositories, so confirm which one matches your environment first.

Frequently asked questions

Official sources

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