Run it inside your own boundary

Deploy it

One compose file, one host, eight services. The application runs read-only and brings its own persistence, so the only decisions you make are where it runs and what it can read.

# everything the stack needs is in the repository
git clone https://github.com/hanu-security/hanu
cd hanu
cp .env.selfhost.example .env.selfhost     # datastore credentials, ports, KMS
docker compose -f docker-compose.selfhost.yml up -d

# then attach read-only cloud roles
aws iam create-role --role-name hanu-readonly \
  --assume-role-policy-document file://trust.json

The application container needs no external service. An air-gapped install mirrors the images and any content bundle into the environment and runs the same compose file; nothing in the running stack reaches out, which is a property you can watch with your own network tooling before you tell an assessor about it.

What it can read, and what it never needs

Cloud access is a read-only IAM role with an external ID, scoped to the accounts you list. The platform enumerates configuration and reads the audit trail; it does not modify resources, and it does not need a role that could.

Where your data lives

Every datastore in the list above runs inside your namespace, VPC or cluster. Findings stay in your Postgres, the graph stays in your Neo4j, artefacts stay in your MinIO, and source credentials are sealed with a KMS key you own.

There is no relay, no telemetry endpoint and no licence-check callout in the image. That is a stronger statement than "we do not sell your data" and a weaker statement than "we cannot see it" — the correct claim is that the software has nowhere to send it, and that you can verify this by watching egress rather than by reading a policy.

Operating it

Licensing, stated precisely

The core is under the Elastic License 2.0. It is source-available rather than OSI-approved open source, and the difference is worth describing rather than glossing.

• Permitted: use the software internally for any purpose, copy it, modify it, distribute it, and make it available within your organisation.
• Not permitted: providing the software to third parties as a hosted or managed service, circumventing licence-key functionality, or removing licensing and copyright notices.
• No time conversion. This is not a licence that becomes something else after three years, and it does not revert to a permissive licence on a schedule.
• No metering. Nothing counts seats, events per second, gigabytes ingested or hosts. Community costs $0 in production regardless of the size of the estate you point it at.

What self-hosting does not get you

A page that only lists advantages is an advertisement rather than a decision aid. The honest trade is this: you own the boundary and you own the operations.

• You run the datastores. Postgres, Neo4j, Redis and MinIO are yours to back up, upgrade, monitor and size. That is real work, and it is the price of the boundary.
• Community detection content arrives at release cadence. The continuously-updated feed between releases is a Growth capability. If new detection content within days of a campaign is a requirement, that is an edition decision and not a configuration one.
• No SOC 2 report for the self-hosted product. The managed edition has one. Self-hosted customers satisfy their own controls — the platform supplies the evidence engines and the audit trail that support doing so.
• No support SLA on Community. There is no contractual response time, no named engineer and no escalation path. Enterprise adds those.
• No SCIM, no Wiz, Jamf, Rapid7, Sumo Logic or Intune integration, and no Oracle Cloud support. These are absent in every edition, not gated by one.
• Hardening is yours. The image runs read-only and needs nothing outbound, but network policy, secret management and host hardening in your environment are your controls, not ours.

Questions