Self-Hosting

Running CortexDB yourself is the recommended path — the same server the cloud runs, on your own infrastructure. Start here.

Self-hosted CortexDB is for customers

Self-hosted releases from 0.9.0 on, including the one these docs describe, are available to customers through the customer portal, with a company license; talk to us to become one. The last public release, 0.8.21, is on cortexdb.ai/download. To use this release today without running a server, start on CortexDB Cloud.

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 at localhost:3141, first write + recall.
Defaults & prerequisites — what runs out of the box (content-only: capture, BM25 + vector recall) vs what's opt-in (blob extraction, 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 ~100 CORTEX_* 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 on CortexDB Cloud — free to start, nothing to run — and move to your own server later as a customer; only the base URL changes.

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.