Dakera Dashboard
The Dakera Dashboard is the admin UI for operating a Dakera server. Version 0.5.1 is released together with Dakera v0.12.2 and works with v0.12.0 and v0.12.1 too: features that need v0.12.2 (Add agent, in-place key edits, rotation grace, session auto-end) fall back to the older behavior or stay hidden there. Pages for features a server has not enabled leave those parts out, and where the server reports nothing the dashboard says "not measured" instead of showing a zero. Image: ghcr.io/dakera-ai/dakera-dashboard:0.5.1.
Current releasedakera-dashboard 0.5.1released 2026-10-08 · release train 0.12.2
- Add agent, edit a key in place, rotate with a grace period, prefix-pattern grant chips (inert entries struck through with why).
- Session lifecycle: last activity, "auto-ends in ~X", "Ended after N h idle", Mark active.
- A calmer, consistent look: new design tokens, WCAG AA semantic colours in both themes, one button/field/table geometry.
- Text truncated by character (Cyrillic, CJK, emoji), no infinite spinners, lists ask for 300-character previews.
docker pull ghcr.io/dakera-ai/dakera-dashboard:0.5.1 What changed → All current versions →
A look inside
Six views of Dashboard 0.5.0 running against a Dakera v0.12.1 server (0.5.1 keeps the same areas with a refreshed look). Swipe, use the arrow keys, or pick a dot, and open any view full screen.
What is in it
The sidebar groups every page in six areas, with breadcrumbs on each page and g + key shortcuts (? lists them). Features show only when the server has them enabled (for example attachments and records).
| Area | Pages and what you do there |
|---|---|
| Overview | What needs attention: degraded components, configuration warnings, re-embedding, exceeded quotas, failed backups, expiring keys. Also stored vectors, agents, storage, recall latency and cache hit rate. |
| Memory | Browse & search: paginated memories with server totals, feedback, entities and links. Recall lab: recall or search for an agent with lang, routing and rerank, and each result's score and rerank_report. Knowledge graph: query, path finder, links, cross-agent network, GraphML / JSON export. Agents and Sessions: Add agent (write scope; POST /v1/agents on v0.12.2), filter, edit, forget and consolidate memories, add a memory with its language; sessions show their last activity and when they auto-end, how they ended (by the client or after N hours idle), and can be marked active. Lists carry a short preview of each memory; opening or editing one reads it in full. Import & export: JSON Lines, CSV, Mem0 and Zep, with import jobs followed to completion. Query tools: query builder, filters, vectors, compare and batch. |
| Namespaces | Sizes, quota usage, contents, semantic and keyword search, full-text statistics and reindex, extractor and memory-policy settings, live events, attachments, records, export, delete and maintenance. |
| Operations | Re-embedding (per-namespace progress, drain, dimension migration), Indexes & compaction (full-text reindex, index rebuild, cache), Background jobs, Backups (create and restore with progress, restore modes, encryption and compression), Decay & TTL, Consolidation (AutoPilot status, last and next run, run now), Cluster (election, replication, held changes, members) and Storage. |
| Observability | Health (degraded components, configuration warnings, readiness, clock drift, model downloads while the server starts), Analytics (overview, KPIs, agents, resources), Audit log (live stream, filters, CSV and JSON export), Slow queries, Live feed, Metrics (the Prometheus output, searchable) and Capabilities (models, index kinds, scoring, query languages, multimodal switches). |
| Access | API keys: create scoped keys pinned to namespaces, agents or prefix patterns ("agents starting with mlx-"), with an expiry; edit a key's name and namespaces in place; rotate with a grace period or replace a key without downtime (see below). Quotas: usage against limits and enforcement mode. Encryption: keyring status, key rotation and re-seal progress. Settings: who is signed in, the server-wide session idle timeout (a super_admin key can change it), and sign out. |
| Developers | SDK, API and MCP server setup snippets, with a YOUR_API_KEY placeholder. |
Every 0.4.0 address redirects to its new home, so bookmarks keep working.
Key grants and editing (Dakera v0.12.2)
Grant chips read prefix patterns in plain words ("namespaces starting with team-"). Entries the server reports as inert, such as a p* saved before v0.12.2 or _dakera_sessions, are struck through with the reason, and a key with legacy patterns offers Re-save to activate patterns. Grants are checked the way the server checks them before anything is sent. A super_admin key edits any key (PATCH /admin/keys/{id}); a namespace admin edits the keys of its namespaces within its own grants. On an older server the edit becomes a replacement key, and the dialog says so.
Rotating a key without downtime
On Dakera v0.12.2, Rotate takes a grace period (up to the server's maximum, 7 days) and shows when the old key stops working; clients keep using the old key until then. The Replace action creates a new key with the same scope, namespaces and remaining lifetime and shows it once. The old key keeps working until you confirm your clients have moved and deactivate or revoke it.
How sign-in works
You sign in at /login with your own Dakera API key. The dashboard server checks it against the Dakera API and keeps it in server memory. Your browser gets only an opaque session id in an HttpOnly, SameSite=Strict cookie (Secure and __Host- prefixed over HTTPS). The key is never sent to the browser, and nothing is stored in localStorage, page HTML or URLs. The dashboard adds the Authorization header to API calls itself and ignores any key the browser sends.
On Dakera v0.12.2 the dashboard learns who you are from GET /v1/auth/whoami (key name, scope, grants and expiry, never the key itself) and re-reads it about once a minute, so a key revoked on the server ends the dashboard session. Sign-in waits up to 20 s for a busy server. Sessions end after DAKERA_SESSION_TTL_HOURS (default 12) or after 2 hours without use.
What each key scope can do
| Key scope | What works |
|---|---|
read | Overview, namespaces, agents, sessions, query tools, knowledge graph, SDK and MCP pages. |
write | Everything read does, plus storing, updating and deleting memories and vectors, adding agents and starting, ending or marking sessions active. |
admin | Everything write does, plus node-wide pages: Operations (cluster, storage, re-embedding, indexes, jobs, backups list, create and delete, decay, consolidation), Analytics, Audit log, Slow queries, Live feed, Metrics, Quotas and Encryption. |
super_admin | Everything, including API keys (all keys, edits included), the server-wide session idle timeout, and backup download, upload and restore. |
admin pinned to namespaces | Its own namespaces and the API keys for those namespaces. The server refuses it on node-wide routes. |
A page your key cannot use says which scope it needs, and the sidebar marks it. Use the lowest scope that suffices.
Run it
Docker Compose
The dakera-deploy compose file has an optional dashboard service in the dashboard profile. It points at the Dakera service and publishes on 127.0.0.1:3002.
docker compose --profile dashboard up -dOpen http://127.0.0.1:3002 and sign in with a Dakera API key. Set DASHBOARD_PORT to change the port and DASHBOARD_IMAGE to pin another image.
docker run
docker run -d --name dakera-dashboard -p 127.0.0.1:3002:3000 -e DAKERA_API_UPSTREAM=http://dakera:3000 ghcr.io/dakera-ai/dakera-dashboard:0.5.1DAKERA_API_UPSTREAM is the Dakera API URL as the dashboard container reaches it, so put both on the same Docker network (or use a host address).
| Variable | Default | Description |
|---|---|---|
DAKERA_ | http:// | Dakera API the dashboard proxies to |
DAKERA_ | 12 | Longest a sign-in lasts (15 minutes to 7 days). Idle sessions end after 2 hours. |
The container serves on port 3000. The healthcheck is /_session/healthz:
curl -fs http://localhost:3000/_session/healthz/health/live and /health/ready stay public for orchestrators; the detailed /health needs a session.
Production notes
- Put TLS in front. The proxy must terminate TLS and forward
X-Forwarded-Protoand the originalHost. The session cookie is markedSecureonly forX-Forwarded-Proto: https, and state-changing requests are accepted only when theirOriginmatches the forwarded host. - Sessions live in memory. A restart signs everyone out. Run one replica, or use sticky sessions, otherwise a request on another replica asks for a new sign-in. No volume is needed.
- Bind to localhost or a private network. Do not expose the plain-HTTP port to the internet, because the API key is typed into the login form.
Upgrading from 0.5.0
Change the image tag to 0.5.1. The deployment is the same as 0.5.0: the same variables, port 3000 and healthcheck. 0.5.1 also refreshes the look (design tokens, consistent controls, colours that pass WCAG AA in both themes), truncates text by character instead of by byte, no longer crashes when you leave a page mid-request, gives every request a time limit instead of an endless spinner, fixes pagination on Browse, Sessions and Namespaces, and keeps the theme choice across reloads. Upgrade the server to v0.12.2 to get Add agent, key edits, rotation grace and session auto-end; see what changed in 0.5.1.
Upgrading from 0.4.0
Change the image tag to 0.5.1. The deployment is the same as 0.4.0: the same variables, port 3000 and healthcheck. Old page addresses redirect to the new ones. 0.5.0 also tightens the browser side: a strict Content-Security-Policy (no inline script, no eval), Cache-Control: no-store on API answers, HSTS on the sign-in, session and API routes, and sanitised Markdown.
Upgrading from 0.3.x
Until 0.3.x the container wrote DAKERA_API_KEY into every served page, so anyone who could load the dashboard held that key. 0.4.0 removed it, and 0.5.x keeps the same sign-in.
- Remove
DAKERA_API_KEYandDAKERA_CLIENT_URLfrom the dashboard container. Both are now ignored with a startup warning. - Rotate the key the old dashboard carried if the dashboard was reachable by people who should not hold it.
- Keep
DAKERA_API_UPSTREAM.DAKERA_SESSION_TTL_HOURSis new and optional. - Update any healthcheck or probe to
/_session/healthz. - Operators now sign in with their own API keys.
Related
- dakera-deploy: compose files and dashboard notes
- Dashboard releases: what changed in each release train · container image
- Deployment: Docker, Kubernetes and systemd
- Security: API keys, scopes and permissions
- Upgrading to v0.12: moving the server to v0.12.2