Admin Console
The operator UI compiled into the CortexDB binary — served at / on the API port, zero-dependency and air-gap-friendly.
CortexDB ships a full operations console built into the binary. There's nothing to install or host
separately: it's served at / on the API port (so http://localhost:3141/ on a default
self-hosted instance), it's compiled into the binary with no CDN or external assets, and it works
air-gapped.
# With the server running, just open it in a browser:
open http://localhost:3141/ # macOS (xdg-open on Linux, start on Windows)The page returns 200 text/html with title "CortexDB — local"; its JavaScript and CSS are served from
/assets/* on the same origin, versioned to the running server (e.g. app.js?v=v0.9.9), so the console
always matches the binary you're running.
What's in it
The console is a single-page app with a real design system — a live bento Overview, interactive SVG
charts with tooltips, KPI tiles, and a command palette bound to Ctrl/Cmd + K (verified). Its
sidebar groups the pages into three sections — Memory, Operate, and System:
Memory
| Page | What it's for |
|---|---|
| Overview | The state of the instance at a glance — health, capacity, pipelines, and AI wiring. |
| Memories | Capture experiences and browse every layer they derive — events, facts, beliefs, episodes, concepts. |
| Console | Ask questions, compose documents, and run raw recalls against a scope, with full per-query telemetry. |
| Artifacts | The structured memory plane — compiled sessions, dossiers, story arcs, rollups, and certified computations. |
| Code memory | Registered repositories indexed into a typed, versioned code graph — coverage, capability matrix, imports, and GC. |
Operate
| Page | What it's for |
|---|---|
| Observability | Throughput, latency, errors, queues, storage, and provider health — live, while the page is open (/v1/admin/metrics). |
| Logs | Live server log stream — filter by level, search text, pause and resume. |
| Features | Switch capabilities (enrichment, graph, rerank, answer lane) on and off in plain English. |
| Data & scopes | Every scope, what's stored in it, and how much it's recalled — plus JSONL export. |
| Audit & access | Who did what, whether policy allowed it, and the tamper-evident hash chain that proves it. |
| Maintenance | Readiness, snapshots, index integrity, vector hygiene, and restarts. |
System
| Page | What it's for |
|---|---|
| Settings | Connect the AI models and content processors that power search, enrichment, answers, and file understanding. |
| Updates | Version, update checks, and release notes for this build. |
Conflicts is surfaced on demand, not in the sidebar
There's a Conflicts view (#/conflicts, backed by /v1/conflicts) for competing values on the same
claim, but it isn't a fixed sidebar item — the console raises it as a notification that deep-links
there whenever stats.bitemporal.open_conflicts > 0. With no open conflicts, there's nothing to show.
Everything the console shows comes from the same v1 API these docs describe — it's a thin, bundled
client over the admin endpoints. The front-end ships as a few origin-served
bundles (/assets/app.js, pages.js, pages-ops.js, pages-code.js), each versioned to the running
server (?v=v0.9.9) so the console never drifts from the binary.
Access & security
The console lives on the API port, on the same origin and under the same auth as the v1 API:
- Under
CORTEX_INSECURE_NO_AUTH=1(local dev) it's open — bound to loopback with the recommended-p 127.0.0.1:3141:3141. - On a server with
CORTEX_API_KEYset (or OIDC), reaching the API — and therefore the console's data — requires the credential.
Don't expose the console without auth + TLS
Because it's served on the API port, publishing that port publishes the console too. Never expose it to
a network in no-auth mode: set CORTEX_API_KEY (or your IdP), terminate TLS in front, and restrict
access — same posture as the API itself.
See also
- Admin endpoints — the API the console is built on
- Self-Hosting Quickstart · Configuration