CortexDB

The long-term memory platform for AI systems.

CortexDB helps teams give AI agents and applications durable memory, richer context, and production-ready integrations without forcing every workflow into prompts alone.

What is CortexDB?

CortexDB is a memory layer for AI products, agents, copilots, and internal knowledge systems. It helps applications:

• store important interactions and events
• retrieve relevant context when it matters
• connect information across tools and workflows
• organize memory by tenant, workspace, or application
• expose memory through SDKs, APIs, and MCP-compatible tools

Rather than acting like a generic database, CortexDB is designed around AI memory use cases such as retrieval, memory operations, connected context, and organizational knowledge capture.

What teams use it for

Teams use CortexDB to power experiences like:

• engineering copilots with operational memory
• support assistants with customer history and product context
• AI companions with persistent cross-session memory
• enterprise agents that need governed, tenant-aware memory
• workflow agents that combine Slack, GitHub, Jira, and incident data

Quick start

Get CortexDB running locally in a few minutes.

Docker

docker run -p 3141:3141 cortexdb/cortexdb

From source

git clone https://github.com/cortexdb/cortexdb.git
cd cortexdb
cargo build --release -p cortexdb
./target/release/cortexdb

By default, CortexDB will be available at http://localhost:3141.

First example

pip install cortexdbai

from cortexdb import Cortex

# Defaults to http://localhost:3141 — point at any cortexdb instance.
with Cortex() as c:
    c.experience("ws:demo", text="Alice deployed payments-service v3.1 to production")
    pack = c.recall("ws:demo", query="What should I know about payments-service?")
    print(pack)

Core workflows

CortexDB is built around a few simple memory operations:

• remember — add new memory
• recall — retrieve useful context
• search — explore memory by query or filter
• forget — remove or suppress memory where policy requires it

These workflows can be used directly through SDKs and APIs or embedded into agent frameworks and MCP tools.

Framework integrations

CortexDB is designed to work with the tools teams already use to build AI systems, including integrations for frameworks such as:

• LangChain
• LangGraph
• LlamaIndex
• CrewAI
• AutoGen
• OpenAI Agents
• PydanticAI
• Vercel AI SDK
• Flowise
• Dify
• Google ADK
• Eliza

See the docs site for integration-specific setup and examples.

Connectors

CortexDB can be used alongside common organizational systems so agents have access to operational and business context.

Current connector coverage includes:

• Slack
• GitHub
• Jira
• PagerDuty
• Confluence

MCP server

CortexDB can also be exposed through an MCP server so MCP-compatible agents and tools can use memory operations as native capabilities.

Typical MCP-enabled workflows include:

• adding memory during agent execution
• retrieving context before a task
• searching prior decisions and interactions
• connecting memory into tool-calling environments

Deployment options

CortexDB supports multiple ways of getting started and operating in production:

• local developer setup
• self-hosted deployment
• clustered deployment for larger workloads
• MCP and web-based companion services in the broader project ecosystem

For deployment guidance, see the docs site and Docker examples in this repository.

Local Docker deployment + live validation

The repository includes a no-mocks Docker validation matrix that builds the local image, starts real single-node containers for core, startup, growth, enterprise, and custom, and runs live tests against them.

Run it from the repository root with:

python tests/live/run_docker_live_suite.py

Use --skip-build to reuse an existing local image.

Runtime single source of truth

Use the repository root .env as the canonical runtime env for:

• production/server startup
• docker-compose.single.yml and docker-compose.yml
• tests/live/run_docker_live_suite.py
• benchmarks/locomo/run_locomo.py
• benchmarks/locomo/llm_judge_memori.py

The benchmark and live-test runners now default to .env and support an override via CORTEX_RUNTIME_ENV_FILE or their --env-file flag.

Backups and disaster recovery

CortexDB now supports an operator-oriented backup and recovery path with:

• RocksDB checkpoint-based backups
• object-store uploads to s3, gcs, or azure
• WAL archival for point-in-time recovery (PITR)
• restore-time rebuilding of vector, graph, fulltext, content, and memory-state projections

Operational backup settings live under [security.backup] in server config. Cloud providers can use either explicit backup config fields or the standard provider environment variables already recognized by the object-store layer (AWS_*, GOOGLE_*, AZURE_*).

For the current operator runbook, see docs/enterprise_runbooks.md. For deployment profile behavior and the local live validation matrix, see docs/deployment_profiles.md.

Learn more

• Documentation: docs-site/
• Public docs: https://docs.cortexdb.io
• Integrations: integrations/
• SDKs: sdks/
• MCP server: mcp-server/

Contributing

We welcome contributions. If you want to help, the most useful areas include:

• integrations
• connectors
• SDK improvements
• documentation and cookbooks
• deployment and operator workflows

See CONTRIBUTING.md if available in your workflow, or open a discussion with ideas for new integrations and plugins.

License

Apache 2.0 — see LICENSE.

Documentation | Discord | Twitter