Self-hosting

GraphRAG runs entirely on your infrastructure — no data leaves your network at answer time, and there is no managed dependency to lock into.

The stack

Docker Compose brings up five services:

Service	Role
`api`	the HTTP API (FastAPI)
`worker`	asynchronous ingestion
`postgres`	control plane — projects, keys, jobs, document registry
`arcadedb`	knowledge plane — one graph database per tenant
`caddy`	TLS termination / reverse proxy

Language-model calls (embeddings, extraction, answering, re-ranking) go to a single OpenAI-compatible endpoint that you configure — so you choose the provider and keep one key.

Configure & run

cp .env.example .env
# set: ADMIN_API_KEY, OPENAI_API_KEY, OPENAI_BASE_URL, ARCADEDB_ROOT_PASSWORD, POSTGRES_PASSWORD

docker compose up -d --build

Apply the database schema (control plane migrations):

docker compose run --rm api alembic upgrade head

Confirm it’s healthy:

curl https://your-host/health

Key environment variables

Variable	Purpose
`ADMIN_API_KEY`	admin credential for provisioning; empty ⇒ provisioning is closed
`OPENAI_API_KEY` / `OPENAI_BASE_URL`	the model endpoint (any OpenAI-compatible provider)
`ARCADEDB_ROOT_PASSWORD`	knowledge-store root credential
`POSTGRES_PASSWORD`	control-plane credential

Operations

Backups — a scripted, scheduled backup of every tenant’s knowledge base, with a restore drill that actually restores a backup and verifies it. A backup you have never restored is not a backup.
Isolation — each tenant can be given its own database user so isolation holds at the storage layer, not just in application code.
Upgrades — the knowledge store is pinned by image digest and gated behind a capability probe, so a storage-engine change can’t silently break behaviour.

These operational pieces ship with the project. Single-node deployments are fine to start; add replication before you depend on it for production traffic.

← PreviousSearch & Answer Next →Limitations