Deployment

hlid is one binary with one config file. Every deployment shape is a variation on "put those two things somewhere and open port 8080."

Docker

docker run -p 8080:8080 \
  -v ./hlid.toml:/app/hlid.toml \
  ghcr.io/skaft-software/hlid:latest

Pass backend credentials as environment variables:

docker run -p 8080:8080 \
  -v ./hlid.toml:/app/hlid.toml \
  -e ANTHROPIC_API_KEY \
  -e OPENAI_API_KEY \
  ghcr.io/skaft-software/hlid:latest

docker compose

The repo's docker-compose.yml runs hlid and a llama.cpp server side by side:

# 1. Uncomment the llama-server section in docker-compose.yml
# 2. Place your .gguf model file in ./models/
# 3. Start both
docker compose up

hlid comes up on :8080, llama.cpp on :8081, and the default config already points one at the other.

From source

git clone [email protected]:skaft-software/hlid.git
cd hlid
cargo build --release          # needs Rust 1.85+ (edition 2024)
./target/release/hlid          # reads hlid.toml from the current directory

Hardening

hlid is designed for localhost or a private network. If it listens anywhere your agents aren't:

1. Set auth_key. The localhost auth bypass only applies to loopback binds with no key configured. Anything else should require a key.
2. Terminate TLS in front. hlid speaks plain HTTP; put Caddy, nginx, or your ingress in front for HTTPS.
3. Keep credentials in the environment. credential_ref names env vars, so keys stay out of config files and out of version control.
4. Watch the observability endpoints. /hlid/requests shows request metadata (never backend keys). It sits behind the same auth as everything else.

See SECURITY.md for the vulnerability reporting policy.