Encryption at rest
BDS does not encrypt its own data. Enable full-disk / volume encryption on the drive that holds the corpus data (e.g. BitLocker). This covers the source documents, the OCR'd text, the vector index, and the entity database.
Deployment & Security · Hardening Guide
Hardening & secure deployment guide.
For the IT / security staff deploying BDS. It defines what "a secured environment" means for BDS, so the items in the security attestation are concrete and verifiable. BDS is on-premise software; securing the environment it runs in is the operating organization's responsibility (see the shared-responsibility split). This guide tells you how.
01 · Default Posture
What you get out of the box.
A single-box install that changes nothing is already closed to the network.
Ports BDS uses (all loopback by default)
| Port | Service |
|---|---|
47080 | BDS REST API (the interface the client talks to) |
47101 | Local text model (llama.cpp) |
47100 | Local vision / OCR model (llama.cpp) |
47000 | Embedding server |
BDS deliberately uses the 47000 range to stay clear of the common 8080 / 8000 ports other local services often occupy — one less conflict at install. Keep all four bound to 127.0.0.1. Only the REST API (47080) is ever a candidate for controlled exposure; 47000 / 47100 / 47101 should never leave loopback.
02 · Network Hardening
Prefer single-box; gate anything beyond it.
Prefer single-box. If the BDS client and server run on the same machine, leave everything on localhost and add no firewall rules. This is the most secure configuration and the default.
If you must expose port 47080 (e.g. a separate client machine):
- Set
BDS_HOST=0.0.0.0deliberately — this is the only reason to change it. - Add a host firewall rule that allows inbound 47080 only from named client IPs — default-deny everything else:
New-NetFirewallRule -DisplayName "BDS API (named clients)" -Direction Inbound `
-Protocol TCP -LocalPort 47080 -RemoteAddress 10.0.0.11,10.0.0.12 -Action Allow03 · Host & Operating System
Patch, least-privilege, control access.
- Patch the host OS to a currently-supported level and keep it patched.
- Run the BDS services under a least-privilege account — not a domain admin.
- Limit interactive / administrator login on the host to named individuals; control physical access.
- Apply the endpoint-protection exclusion we provide at installScoped to the BDS engine directory only — do not disable endpoint protection. We supply the exact path and re-check guidance during onboarding.
04 · Data Protection
Encrypt at rest, back up, cover derived data.
Backups
Back up the corpus data directory on your normal schedule; verify recovery.
Vault export
If you publish entity cards to an Obsidian vault, that vault directory holds derived content too — include it in the same encryption + backup scope.
05 · OSINT Enrichment (Optional)
If you enable the one outbound module.
06 · Encryption in Transit & Authentication
Loopback needs nothing; an exposed port needs a proxy.
07 · Verification Checklist
Maps to the security attestation.
- Server confirmed bound to
127.0.0.1(or0.0.0.0with a scoped firewall rule). - Ports
47000/47100/47101are loopback-only. - Host OS patched; BDS runs under a least-privilege account.
- The endpoint-protection exclusion we provide is in place, scoped to the engine directory.
- Full-disk / volume encryption enabled on the corpus data drive.
- Backup + recovery verified for the corpus data directory.
- OSINT module: disabled, or routed through a controlled egress path.
- If 47080 is exposed: TLS + authentication in front of it; firewall default-deny.
- A named person owns host security; an incident process exists.
Pairs with the Deployment & Security overview and the security attestation. Questions on hardening or a security review — admin@veniceinference.com.