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 single-node deployment (the supported configuration)
• MCP and web-based companion services in the broader project ecosystem

Clustered deployment is experimental and not yet operational — see docker-compose.cluster-experimental.yml for details; do not rely on it.

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

The supported backup path today is a verified cold backup:

# stop the server first — the tool refuses live data dirs
python scripts/cold_backup.py backup  ./cortexdb_data backup.tar.gz
python scripts/cold_backup.py verify  backup.tar.gz
python scripts/cold_backup.py restore backup.tar.gz ./restored_data

Every file is SHA-256-manifested; restore verifies each digest into a fresh directory and refuses truncated or tampered archives. The end-to-end drill (tests/smoke/backup_restore_smoke.py) proves IDs, recall, and forget markers survive the round trip.

Online (hot) backup, object-store uploads, and point-in-time recovery are not yet supported — earlier claims about /v1/admin/backup endpoints and PITR described unwired code and have been withdrawn until a verified implementation ships.

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

CortexDB Community License v1.0 — see LICENSE.txt. Client SDKs and integrations published to PyPI/npm carry their own per-package licenses; see each package's metadata.

Documentation | Discord | Twitter