Bring Your Own Infrastructure

Three independent BYO configs let you decide exactly where your data lives and which LLM sees it. Each follows the same contract: PUT validates with a live self-test before saving, credentials are Fernet-encrypted at rest and never returned or logged, DELETE reverts to the platform default.

BYO object storage#

PUT /v1/memory/storage/config
{"backend": "s3", "endpoint_url": "https://…", "bucket": "…",
 "region": "auto", "access_key": "…", "secret_key": "…"}

Self-test: write + read + delete a probe object. After this, your file bytes (drops, attachments) live in your bucket — AWS, Hetzner, MinIO, anything S3-compatible.

BYO database#

PUT /v1/memory/database/config        # your Postgres DSN

Your memories and embeddings live in your own Postgres (needs pgvector).

BYO extraction LLM#

PUT /v1/memory/extraction/config
{"provider": "custom", "base_url": "https://api.openai.com/v1",
 "model": "gpt-4o-mini", "api_key": "sk-…"}

Self-test: a 1-token completion. Any OpenAI-compatible endpoint works — your own OpenAI/Azure key (you pay your own usage), or a self-hosted Ollama/llama.cpp server (base_url: http://…:11434/v1), so conversation text never touches a third-party LLM. Graph extraction runs in the background worker, so a slower local model is fine.

Resolution order#

For extraction: tenant BYOK config → server-level env override → platform default. The same precedence idea applies to storage and database. You can mix freely — e.g. platform DB + your bucket + your LLM.

What goes where (summary)#

DataDefaultWith BYO
Embeddingscomputed on-box, stored in platform DByour DB
File bytesplatform bucketyour bucket
Extraction promptsplatform OpenAI keyyour key / your local model