Summary
Three gaps in the Qdrant vector DB service configuration:
Issue 1 — No authentication (#17)
Qdrant exposes its HTTP API (port 6333) and gRPC API (port 6334) with no authentication. Any local process can read, write, or delete all user vector embeddings without credentials. Ports are bound to 127.0.0.1, limiting exposure to localhost, but auth should still be present for defence-in-depth.
Qdrant v1.x supports API key authentication via the QDRANT__SERVICE__API_KEY env var.
Issue 2 — No resource limits (#11)
The Qdrant container has no deploy.resources.limits. During RAG indexing, Qdrant can consume unbounded system RAM, potentially OOM-killing the Docker VM and corrupting vector data. Every other resource-intensive service in the stack has memory limits.
Issue 3 — TCP healthcheck instead of HTTP (#19)
The current healthcheck:
test: ["CMD-SHELL", "bash -c 'echo > /dev/tcp/localhost/6333'"]
This is a raw TCP port probe — it only confirms the port is open, not that Qdrant is healthy and serving. Qdrant provides GET /healthz which returns HTTP 200 only when ready.
Fix
Five files:
extensions/services/qdrant/compose.yaml — add env var, limits, fix healthcheck.env.example — document QDRANT_API_KEY in Optional Security section.env.schema.json — register QDRANT_API_KEY (secret: true) for Linux validate-env.shinstallers/phases/06-directories.sh — auto-generate key on Linux installinstallers/macos/lib/env-generator.sh — auto-generate key on macOS install
Note: No other service in the stack currently connects to Qdrant's HTTP API programmatically, so adding the API key requires no client-side changes. Open WebUI and n8n have optional user-configured Qdrant integrations — those are out of scope for the installer.
Note: Windows installer is not updated in this PR — Windows Qdrant auth is a follow-up.
Summary
Three gaps in the Qdrant vector DB service configuration:
Issue 1 — No authentication (#17)
Qdrant exposes its HTTP API (port 6333) and gRPC API (port 6334) with no authentication. Any local process can read, write, or delete all user vector embeddings without credentials. Ports are bound to
127.0.0.1, limiting exposure to localhost, but auth should still be present for defence-in-depth.Qdrant v1.x supports API key authentication via the
QDRANT__SERVICE__API_KEYenv var.Issue 2 — No resource limits (#11)
The Qdrant container has no
deploy.resources.limits. During RAG indexing, Qdrant can consume unbounded system RAM, potentially OOM-killing the Docker VM and corrupting vector data. Every other resource-intensive service in the stack has memory limits.Issue 3 — TCP healthcheck instead of HTTP (#19)
The current healthcheck:
This is a raw TCP port probe — it only confirms the port is open, not that Qdrant is healthy and serving. Qdrant provides
GET /healthzwhich returns HTTP 200 only when ready.Fix
Five files:
extensions/services/qdrant/compose.yaml— add env var, limits, fix healthcheck.env.example— document QDRANT_API_KEY in Optional Security section.env.schema.json— register QDRANT_API_KEY (secret: true) for Linux validate-env.shinstallers/phases/06-directories.sh— auto-generate key on Linux installinstallers/macos/lib/env-generator.sh— auto-generate key on macOS installNote: No other service in the stack currently connects to Qdrant's HTTP API programmatically, so adding the API key requires no client-side changes. Open WebUI and n8n have optional user-configured Qdrant integrations — those are out of scope for the installer.
Note: Windows installer is not updated in this PR — Windows Qdrant auth is a follow-up.