CortexDB · v0.9.8

Run CortexDB locally

One command, no signup. Self-host the same engine that powers CortexDB Cloud on your own infrastructure at no cost. Source-available, not open source.

Docker

Multi-arch image (linux/amd64 · linux/arm64) on Docker Hub.

Run CortexDB

bash

docker run -d \
  --name cortexdb \
  -p 3141:3141 \
  -v cortexdb-data:/data \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  cortexdb/cortexdb:latest

Browser UI: localhost:3141 · Health: localhost:3141/v1/admin/health

Binary downloads

Single stripped executable plus bundled assets, README, and docs. No Docker required.

Linux · x86_64

cortexdb-0.9.8-linux-amd64.tar.gz

Linux · ARM64

cortexdb-0.9.8-linux-arm64.tar.gz

SHA-256 checksums are attached to every GitHub Release. macOS and Windows builds aren't shipped yet — ping us on contact if you need one.

What's new in v0.9.8

Full changelog →

CortexDB v0.9.8

August 22, 2026

One fix, and it is the other half of the deletion work that shipped in v0.9.7: a scope-wide forget could leave the scope unable to accept new memories.

A forget no longer blinds a scope to everything written after it. After POST /v1/forget with cascade: "redact_events" and confirm_all: true, memories written to that scope afterwards were accepted, acknowledged and durably stored — GET /v1/events/{id} served them — but /v1/recall never returned them again. Not a delay: they stayed invisible indefinitely, and every child scope created under that scope inherited the same blindness. The practical effect was that a scope you had once erased could never be reused, and nothing in the API told you so.

The erasure guarantee is unchanged. Memories written before the cutoff stay suppressed exactly as before; only writes that genuinely postdate the forget come back.

Who was affected. This only surfaced when retrieval fell back to its degraded path — most commonly when the configured embedding provider was failing (an expired or rate-limited API key), so ranked retrieval returned nothing on every query. A healthy deployment would not have seen it, which is why it took a production environment to reproduce. If your logs carry embedding missing for chunk or continuing with WAL-only events, you were in the affected mode, and it is worth checking your embedding credentials as well as upgrading: in that state new writes also get no vectors at all.

Nothing to migrate. Scopes that were already blinded recover on upgrade — the suppression was applied at read time, so the memories were never lost.

Drop-in. No API, schema or configuration changes.

First memory

Store + recall

bash

curl -X POST http://localhost:3141/v1/experience \
  -H 'Content-Type: application/json' \
  -d '{
    "scope": "ws:demo",
    "modality": "observation",
    "content": { "kind": "text", "text": "Priya at Acme signed for 200 seats." },
    "context": { "observed_at": "'\`date -u +%Y-%m-%dT%H:%M:%SZ\`'" },
    "idempotency_key": "'\`uuidgen\`'"
  }'

Once it's running you can:

Open localhost:3141 in a browser for the built-in dashboard.
pip install cortexdbai or npm i cortexdbai for SDK access. Both ship the same CortexDB client.
Read docs/GETTING_STARTED.md (bundled in the tarball + image at /opt/cortexdb/docs/).
Browse the full API at /docs.

What ships in the package

cortexdb — stripped release binary (~80 MB)

assets/ — WordNet synonym map for BM25 expansion

docs/GETTING_STARTED.md — five-minute quickstart

docs/API_DESIGN_V1.md — endpoint design rationale

docs/API_REFERENCE_V1.md — full endpoint reference

docs/CORTEXDB_FOR_THE_ENTERPRISE.md — security, compliance, deployment

docs/cortexdb_customer_deck.html — product overview deck

docs/PRODUCTION_DEPLOYMENT.md — systemd, reverse proxy, secrets

README.md, LICENSE.txt

Or skip the ops

CortexDB Cloud runs the same engine, managed. Free tier with 10K memories, no card required.

Try CortexDB Cloud