Self-Hosting
Running CortexDB yourself is the recommended path — the same server the cloud runs, on your own infrastructure. Start here.
Self-hosting is the recommended way to run CortexDB. The server you run yourself is the same one the
cloud runs — the identical cortexdb/cortexdb image, the identical v1 API. Hosting it yourself means:
- Your data stays in your infrastructure — memory, embeddings, and blobs never leave your network.
- No per-token or per-seat cost — you pay only for the compute you run and the model APIs you choose to wire in (or none, if you run models locally).
- Full control — pick your embedding and answer models, your storage backend, your auth and compliance posture.
- One binary — a single Rust process; single-node handles ~10M events on commodity hardware.
Start here
Five minutes to a running server
The Self-Hosting Quickstart takes you from nothing to a stored-and-
recalled memory with one docker run. It's the recommended starting point for everyone.
The self-hosting path
- Quickstart —
docker run, point atlocalhost:3141, first write + recall. - Defaults & prerequisites — what runs out of the box
(content-only: capture, BM25 + vector recall, blob extraction) vs what's opt-in (Facts/Beliefs/
Understanding, the knowledge graph, cross-encoder rerank, and
/v1/answer), and how to turn each on. - Configuration — how config resolves (defaults →
cortex.toml→ env → CLI), and the ~100CORTEX_*knobs. - Profiles & Presets — copy-paste configs for common shapes, including a full Enterprise profile.
Wire in the pieces you need
- Embeddings — required for vector recall; OpenAI, Cohere, or a fully local Ollama.
- LLM & Answer generation — the answer lane (
CORTEX_ANSWER_*) that powers/v1/answer, plus the extraction and enrichment lanes. - Storage & Cluster — WAL durability, HNSW shape, blob backends.
- Media ingestion · Code Intelligence Plane.
Operate it
- Security & Compliance — auth, TLS/mTLS, RBAC, audit, SIEM, GDPR erasure.
- Backups & Disaster Recovery — the verified cold-backup procedure.
- Deployment Presets —
dev_local/on_prem_enterprise/ cloud postures.
Self-hosted vs Cloud
Both run the same server and the same v1 API — you move between them by changing one base URL, so this is a deployment choice, not a product choice.
| Self-hosted (recommended) | Managed cloud | |
|---|---|---|
| Where data lives | Your infrastructure — memory, embeddings, blobs never leave your network | CortexDB's infrastructure |
| Model API keys | Yours; you choose the providers (or run models locally, no external calls) | Managed for you |
| Cost model | Your compute + whatever model APIs you wire in (or $0 with local models) | Tiered subscription |
| Who runs it | You (one Docker container; single-node handles ~10M events) | CortexDB |
| Upgrades / ops | You pull new images and run backups | Handled for you |
| Auth | You set CORTEX_API_KEY (or your OIDC/IdP) | Provisioned tokens |
| Best when | Data residency, cost control, air-gapped or regulated environments, full control | You'd rather not operate a server and want zero ops |
Not sure? Start self-hosted with the Quickstart — it's five minutes and nothing leaves your machine — and switch the base URL to the cloud later if operating the server isn't worth it for you.
Connectors, self-hosted
Every one of the 18 connectors runs against your own instance with the
cortexdb-sync CLI — no dashboard required. Point it at http://localhost:3141 and it ingests Slack,
GitHub, Jira, and the rest into your scopes.
Moving between self-hosted and cloud
The API, SDKs, and connectors are identical — point them at http://localhost:3141 (self-hosted) or
https://api-v1.cortexdb.ai (managed cloud) by changing one base URL.
What is CortexDB?
The long-term memory layer for AI agents — durable memory, connected context, and practical ways to integrate memory into real workflows.
Self-Hosting Quickstart
Run your own CortexDB server with one docker run, then store and recall your first memory against localhost — the recommended way to start.