Platform Chain of Custody Validation Deployment Company Contact Request a Demo
Home/Deployment

Your hardware. Your network. Nowhere else.

Bloodhound is self-hosted and offline by default. Case data stays on infrastructure you control, in a deployment model that fits the restrictions your lab already operates under.

No cloud dependency Air-gap friendly No telemetry Offline licensing
Deployment models

Three ways labs run Bloodhound

MODEL 01

Standalone workstation

The full platform on a single examiner workstation. Suits solo practitioners, consultants and small units with case volumes that fit on one machine.

  • Single-host install, no external services
  • Local evidence storage or attached array
  • Ledger anchored to the local node key
MODEL 02

Lab server, multi-examiner

A central processing and storage node, with examiners working concurrently from their own seats. Parsing runs server-side and custody is unified across the team.

  • Shared case and evidence repository
  • Role-based access with per-case scoping
  • One ledger spanning every examiner’s actions
MODEL 03

Air-gapped enclave

Deployment inside a network with no outbound path at all. Installation, licensing, updates and validation datasets move by controlled offline media.

  • Offline install and licence activation
  • Signed update bundles, verified before apply
  • Zero outbound connections at any time

Security posture

Built for data that must not leave

Case material is among the most sensitive data any organisation holds: victims, suspects, warrant scope, unindicted third parties. We build on the assumption that none of it may ever transit a network you do not own.

  • No phone-home. No telemetry, no usage analytics, no crash reporting back to us. Nothing is transmitted from a Bloodhound install.
  • Encryption at rest. Evidence stores, working copies, indexes and the ledger are encrypted on disk, with keys held by the deployment.
  • Role-based access. Examiner, reviewer, supervisor and auditor roles, scoped per case, with every access attempt written to the ledger.
  • Write-blocked sources. Originals are opened read-only at the platform level, whatever hardware write-blockers you also use.
  • Signed artifacts. Builds, update bundles, validation reports and exported ledgers are signed and verifiable offline.
network posture — gk-node-01
$ bloodhound doctor --network outbound connections .......... 0 telemetry endpoints ........... none compiled in licence check ................. offline, local update channel ................ manual bundle evidence store encryption ..... AES-256-GCM ledger key .................... hardware-backed source mounts ................. READ-ONLY (6) rbac .......................... enforced ✓ host is air-gap compliant

Sizing

Indicative hardware

Parsing and indexing are CPU- and I/O-bound. Treat these as starting points; we will size against your real case volumes during evaluation.

ProfileCPUMemoryStorageTypical use
Workstation8 cores32 GB2 TB NVMeSolo examiner, one or two active cases
Lab node16–32 cores128 GB8 TB NVMe + arraySmall unit, several concurrent examiners
Processing tier64+ cores256 GB+NVMe tier + bulk arrayHigh-volume lab, sustained parallel parsing
Air-gapped enclaveMatched to tierMatched to tierLocal only, no network storageClassified or restricted environments

Platforms

Linux server and workstation distributions, with containerised and native install paths. No dependency on a particular hypervisor or cloud provider.

Storage

Local NVMe for working copies and indexes, bulk arrays or SAN for retention. Evidence stores are encrypted whatever the underlying medium.

Backup & retention

Evidence, ledger and case metadata back up as one verifiable set. A restored case re-verifies its chain and its evidence hashes before it will reopen.


Lifecycle

Installing and updating without a network

01

Offline install

A signed installation bundle on controlled media. Signature and hash are checked before anything is written.

02

Local licensing

Licences activate against the local node with no callback, no seat check and no expiry surprise in the middle of a case.

03

Baseline validation

Run the validation suite on your hardware to establish a documented baseline before first case use.

04

Controlled updates

Updates arrive as signed bundles you apply on your own schedule. Re-run the suite afterwards.

Version pinning for open cases

A case records the platform build that processed it. Labs can hold that build in place for the life of an open matter, so the version you testify about is still the version installed, and can still be re-validated on demand.

  • Build identifier recorded in the case and in the report
  • Side-by-side installs of pinned and current builds
  • Re-validation of any pinned build before testimony
  • Update history written to the custody ledger

Scoped to your environment

Tell us how your lab is configured and what it is allowed to connect to. We will size the deployment around that.