Dakera Deploy
Dakera-AI19 Sterne
Self-hosted Dakera AI memory server — Docker Compose, Kubernetes, Helm, HA cluster setup, and monitoring.
- Transport
- stdio
- Status
- Lokal
Agenten stärken
Installation vom Herausgeber. Kein PlugMCP-Endpunkt.
Host a copy with our keys and logs.
Noch kein paketiertes Release in der Registry. Folgen Sie der README des Repositorys.
Remote-URL oder ein Befehl auf Ihrem Rechner? Worin sich die beiden Installationen unterscheiden
Auf PlugMCP ausführen
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
StartenVom Herausgeber
Self-hosted Dakera AI memory server — Docker Compose, Kubernetes, Helm, HA cluster setup, and monitoring.
| v0.12.3 |
main: compose files, Kubernetes manifests and guides in this repo target v0.12.3 (Dashboard 0.5.2) |
| Previous | v0.11.x (last: v0.11.108) | the release/0.11 branch, kept unchanged |
On v0.11? Use the release/0.11
branch (git clone -b release/0.11 https://github.com/Dakera-AI/dakera-deploy): everything in it
keeps working as before. Its Helm counterpart is the 0.11.x chart on the
release/0.11 branch of dakera-helm.
On v0.12.2? Follow Upgrading from v0.12.2 to v0.12.3: pull the new
images; nothing is migrated by hand. On v0.12.0? Take Upgrading from v0.12.0 to v0.12.1
on the way: a cluster needs DAKERA_CLUSTER_SECRET on every node and, if it ran without one, an upgrade in
one window.
Moving from v0.11? Follow Upgrading from v0.11. Going back is supported (Rolling back to v0.11).
Dakera is the agent-native memory platform — purpose-built for AI agents that need persistent, session-aware, cross-agent memory. A single self-hosted Rust binary gives you vector search, hybrid retrieval (BM25 + HNSW), knowledge graphs, session management, and built-in embeddings. No external dependencies. Your data stays on your infrastructure.
88.2% on the LoCoMo benchmark — 1,540 questions testing long-conversation memory across temporal reasoning, multi-hop retrieval, and event ordering.
All use cases deploy identically — the profiles below configure storage backend and scale.
No config required. Dakera runs in-memory by default — great for local testing and development.
git clone https://github.com/dakera-ai/dakera-deploy
cd dakera-deploy/docker
docker compose -f docker-compose.local.yml up -d
That's it. Dakera is now running at http://localhost:3000.
# Verify it's healthy
curl http://localhost:3000/health
To persist data across restarts, use the Development profile (MinIO-backed) or the Default profile (production-grade).
For IDE-integrated development, see the VS Code / Cursor Devcontainer below.
The fastest way to get a full Dakera dev environment — no local installs required.
Prerequisites: Docker + VS Code with the Dev Containers extension, or Cursor.
git clone https://github.com/dakera-ai/dakera-deploy
# Open the folder in VS Code / Cursor, then:
# "Reopen in Container" when prompted (or Ctrl+Shift+P → Dev Containers: Reopen in Container)
That's it. The container build will:
Service endpoints (available on localhost):
Auth is disabled for local dev. See docker-compose deployment for production auth setup.
Fastest way to get Dakera running. No external dependencies.
cd docker
docker compose -f docker-compose.local.yml up -d
Includes MinIO for S3-compatible persistent storage.
cd docker
docker compose -f docker-compose.dev.yml up -d
Production-grade single-node deployment with MinIO, caching, and health checks.
Version pinning: The default images are pinned to Dakera v0.12.3 and Dashboard 0.5.2 (v0.11:
release/0.11). To run a specific version, setDAKERA_IMAGEandDASHBOARD_IMAGEin your.env:DAKERA_IMAGE=ghcr.io/dakera-ai/dakera:0.12.3 DASHBOARD_IMAGE=ghcr.io/dakera-ai/dakera-dashboard:0.5.2Pinning to explicit versions prevents unexpected upgrades in production.
First-time setup — configure credentials before starting:
cd docker
cp .env.example .env
# Edit .env — set DAKERA_ROOT_API_KEY and MinIO credentials
# Generate a strong key: openssl rand -hex 32
docker compose up -d
Production HA deployment with Traefik load balancer, 3 Dakera nodes, gossip-based clustering, and MinIO storage (one bucket per node).
cd docker
docker compose -f docker-compose.ha.yml up -d
Set DAKERA_CLUSTER_SECRET first: at least 16 characters, the same on every node, generated with
openssl rand -hex 32, in the env file you start the stack with (.env, or .env.ha with
--env-file .env.ha). From v0.12.1 a cluster node without it exits with code 78, fresh install or upgraded,
so the file has no development default and refuses to start without it. Each node uses its own MinIO bucket.
Authentication is on (DAKERA_AUTH_ENABLED
defaults to true here too: the load balancer port is published on every interface). The nodes share no
Redis: with one Redis shared by the three nodes, v0.12.0's replication applied nothing on some peers
(measured: 3 of 6 node pairs never converged); without it every write reached the two other nodes within
0.1 s.
Dashboard 0.5.2 (with Dakera 0.12.3; it works with 0.12.0 – 0.12.2 too) deploys like 0.5.1, with three things to check:
/tmp (a read-only root filesystem works with a writable /tmp).curl: a health check that ran curl in it must change. The compose files here use
python3 (works with 0.5.1 too); Kubernetes uses httpGet probes.DAKERA_API_UPSTREAM must be a plain http(s)://host[:port][/path] URL. New, optional:
DAKERA_TRUSTED_PROXIES, the addresses / CIDRs (comma or space separated) of the reverse proxies in front of the
dashboard whose X-Forwarded-For names the client, so the sign-in throttle counts the real client. Unset, the
connecting peer is the client (behind a proxy, every user shares the proxy's address).Dashboard 0.5.0 deploys exactly like 0.4.0: same image name, same variables (DAKERA_API_UPSTREAM,
optional DAKERA_SESSION_TTL_HOURS), port 3000, healthcheck /_session/healthz. Coming from 0.4.0, change
the image tag and nothing else (DASHBOARD_IMAGE, or docker compose pull dashboard). The navigation is
regrouped into six areas and every 0.4 URL redirects to its new home, so bookmarks keep working. 0.5.0 also
adds the Operations hub (background jobs, re-embedding, indexes, consolidation), analytics and metrics pages,
and the server audit log, and serves a strict Content-Security-Policy. Release notes: the dashboard's
CHANGELOG.
The dashboard (docker compose --profile dashboard up -d, or always on in the HA file) no longer carries an API key.
Operators open /login and sign in with their own Dakera API key; the dashboard's session service keeps it in
server memory behind an HttpOnly, SameSite=Strict cookie, and nginx adds Authorization: Bearer <key> to API
calls itself. Until 0.3.x the container wrote DAKERA_API_KEY into every served page (Dakera-AI/dakera-deploy#296).
Upgrading from 0.3.x (breaking for deployments; introduced in 0.4.0):
DAKERA_API_KEY and DAKERA_CLIENT_URL from the dashboard service. Both are ignored with a startup
warning. Rotate any key the old dashboard carried (the compose files used DAKERA_ROOT_API_KEY) if the
dashboard was reachable by people who should not hold it: that key was readable in every page it served.DAKERA_API_UPSTREAM (unchanged; the compose files set it). DAKERA_SESSION_TTL_HOURS is new and optional
(default 12, the longest a sign-in lasts; idle sessions end after 2 hours).3000 (the session service listens on loopback 3001 inside the container; do not
publish it). The healthcheck is /_session/healthz; /health/live and /health/ready stay public.python3, used by the session service).TLS in front. The session cookie is marked Secure (and __Host- prefixed) only when the request arrives with
X-Forwarded-Proto: https, and state-changing requests are accepted only when their Origin matches the Host (or
X-Forwarded-Host) the proxy forwards. So the proxy in front must terminate TLS, forward X-Forwarded-Proto and keep
the original Host. The compose files publish the dashboard on 127.0.0.1 (single node) so a proxy on the same
host can reach it; do not expose the plain-HTTP port to the internet (the API key is typed into the login form).
# Caddy: sets X-Forwarded-Proto/-For and keeps Host by default
dashboard.example.com {
reverse_proxy 127.0.0.1:3002
}
# nginx
server {
listen 443 ssl;
server_name dashboard.example.com;
# ssl_certificate / ssl_certificate_key ...
client_max_body_size 200m; # backup uploads
location / {
proxy_pass http://127.0.0.1:3002;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off; # live feed (SSE)
proxy_read_timeout 300s;
}
}
Traefik and ingress-nginx forward both headers by default; behind a cloud load balancer that terminates TLS, make
sure the controller trusts and passes its X-Forwarded-Proto (ingress-nginx: use-forwarded-headers: "true").
Add observability to any deployment profile.
# Start Dakera with monitoring (standalone monitoring compose)
cd docker
docker compose up -d
cd ..
docker compose -f docker/docker-compose.yml -f monitoring/docker-compose.yml up -d
Or use the monitoring profile in the HA stack:
cd docker
docker compose -f docker-compose.ha.yml --profile monitoring up -d
admin, password GRAFANA_PASSWORD from your env file: required, no default)The "Dakera Overview" dashboard is the server's v0.12 dashboard: request rates and latency percentiles,
HTTP statuses and errors, health and configuration (config warnings, degraded components, WAL and
memory-read failures, backups), models and memory admission, recall and ingest stage latencies, derived caches
and late interaction, tiered storage, cluster replication, encryption and the RocksDB hot tier. Prometheus loads
the server's alert rules (monitoring/dakera.rules.yml) next to the deploy-side ones
(monitoring/alerting-rules.yml); the HA stack scrapes its three nodes (monitoring/prometheus.ha.yml) and alerts
on the node count. Every expression reads a metric the v0.12 server emits.
Production deployment via kubectl or Helm. See Kubernetes Deployment below.
Once Dakera is running, connect with the official CLI and MCP server:
# dk CLI — inspect memory, run queries, manage namespaces
brew install dakera-ai/tap/dk # macOS
# or: curl -fsSL https://dakera-ai.github.io/apt-repo/install.sh | sh # Linux
dk store --namespace myagent "User prefers concise replies"
dk recall --namespace myagent "communication style"
# dakera-mcp — expose Dakera tools to AI agents via Model Context Protocol
npx @dakera-ai/dakera-mcp # zero-install, latest version
# or: brew install dakera-ai/tap/dakera-mcp
# Add to Claude Desktop: { "mcpServers": { "dakera": { "command": "npx", "args": ["@dakera-ai/dakera-mcp"] } } }
See dakera-cli and dakera-mcp for full documentation.
Nothing is migrated by hand: v0.12.3 starts on v0.12.2 data as it is, and v0.12.2 starts again on data v0.12.3 wrote. The server's guide: UPGRADE.md, "Upgrading from v0.12.2 to v0.12.3".
POST /admin/backups).git pull on main): images ghcr.io/dakera-ai/dakera:0.12.3 and
ghcr.io/dakera-ai/dakera-dashboard:0.5.2. If you pin DAKERA_IMAGE / DASHBOARD_IMAGE in .env, change
them there. Your own compose files: the server image has no curl any more, so a health check that execs
curl in it must change to dakera healthcheck /health/ready (the files here run either, whichever the image
has); the dashboard image has no curl either (the files here check it with python3).docker compose run --rm --no-deps dakera --check-config
(exit 0 = it would start).docker compose pull && docker compose up -d (Kubernetes: kubectl apply -k k8s/).What behaves differently (all of it in the server's CHANGELOG):
DAKERA_AUTOPILOT_DEDUP_MODE=merge to keep that (report lists what it would merge and changes nothing).
Merges and consolidations now keep sessions apart and keep what they remove restorable for 7 days.429 + Retry-After (it was 503). The SDKs, the CLI, the MCP server and the
dashboard already retry on it.200 with no memories (they answered 404).DAKERA_RERANK_MAX_CANDIDATES). Under a container memory limit with room for them, the embedder and the
reranker prepack their weights (faster, more memory): docker-compose.yml's 12G limit turns this on, about
+2.8 GB resident; set DAKERA_EMBED_PREPACK=0 and DAKERA_RERANK_PREPACK=0 to keep the previous footprint./health/live during crash recovery (with its
progress in /health/ready), and returns freed memory to the system after bursts.DAKERA_DOCUMENTS; .env.example, "Document import").POST /ops/shutdown needs a super_admin key; four admin routes refuse unknown fields (422);
idle keep-alive connections close after DAKERA_HTTP_HEADER_READ_TIMEOUT_SECS (30 s), so a proxy in front must
drop its idle upstream connections sooner (the Traefik and Caddy files here use 25 s); with authentication off,
a request by an unlisted DNS name gets 421 (DAKERA_ALLOWED_HOSTS). The :gpu image needs NVIDIA driver
R580 or newer.The new settings are listed in examples/environment-variables.md and
docker/.env.example; every one is optional.
Stop v0.12.0 and start v0.12.1 on the same data and environment; nothing is migrated by hand (the stored formats are v0.12.0's). The server's guide: UPGRADE.md, "Upgrading from v0.12.0 to v0.12.1".
Back up (POST /admin/backups).
Take the new files (git pull on main): image ghcr.io/dakera-ai/dakera:0.12.1 (dashboard 0.5.0).
If you pin DAKERA_IMAGE / DASHBOARD_IMAGE in .env, change them there.
Clusters only (docker-compose.ha.yml): DAKERA_CLUSTER_SECRET is required on every node. A 0.12.1
cluster node without it exits with code 78 before serving, fresh install or upgraded (v0.12.0 let an
upgraded node run without it, which left POST /internal/sync/key/add open to anyone reaching the API port).
Nodes with and without the secret do not see each other, so:
cd docker
openssl rand -hex 32 # -> DAKERA_CLUSTER_SECRET=<value> in .env (or .env.ha, with --env-file .env.ha)
docker compose -f docker-compose.ha.yml pull
docker compose -f docker-compose.ha.yml run --rm --no-deps dakera-1 --check-config # exit 0
docker compose -f docker-compose.ha.yml down # volumes kept
docker compose -f docker-compose.ha.yml up -d
GET /admin/cluster/status lists the two others as healthy members and the same leader. Rotating the
secret later needs the same one-window restart.Single nodes are not affected, nor are the k8s/ manifests (one server, no cluster mode); a cluster
built from them (one release per node) needs the same secret on every node, from the dakera-secrets Secret.
Start v0.12.1: docker compose pull && docker compose up -d (Kubernetes: kubectl apply -k k8s/).
On the first start, with nothing to do:
Full-text index re-analysed under the configured analyzer). The v0.12.0 manual
POST /admin/fulltext/reindex {"rebuild": true} step is no longer needed; if you already ran it, nothing
is left to do.DAKERA_MODEL is no longer refused: the store is re-embedded in the background, each
namespace answered with its own model until its turn (progress: /health embedding_model_change).
Still refused, as on v0.12.0, with DAKERA_TIERED=1 (the quick-start files' default), late-interaction
scoring, the visual lane, or a recorded model the build does not know.Memory and session counts change meaning. Memory totals stop counting sentence sub-memories and
drop; session totals count ended sessions too and rise (GET /v1/agents memory_count /
session_count, GET /v1/agents/{id}/stats total_memories / total_sessions,
GET /admin/memory-type-stats total, GET /v1/kpis session_count_weekly). The old GET /v1/agents
figure is the new vector_count. Data, recall and quotas are unchanged. The Prometheus rules and Grafana
dashboards in monitoring/ read none of these fields (dakera_memories_total and dakera_sessions_active
keep their meaning); annotate the step in any report or alert of your own built on them.
Check: /health is ready, GET /v1/agents lists every agent, and a keyword search returns hits.
Going back to v0.12.0 is not part of the server's release checks: restore the backup from step 1.
An unchanged v0.11.108 deployment upgrades in place: stop v0.11, start v0.12.1 on the same data and the same environment. It starts, keeps its data and answers as before, except for the defects v0.12 fixes on purpose. The full guide is the server's docs/v0.12/UPGRADE.md (release notes: RELEASE_NOTES.md). Summary for the files in this repo:
POST /admin/backups).0 (would start) or 78
(would refuse):
cd docker
docker compose run --rm --no-deps dakera --check-config # single node
docker compose -f docker-compose.ha.yml run --rm --no-deps dakera-1 --check-config # HA
git pull on main) and review what changed for your setup:
ghcr.io/dakera-ai/dakera:0.12.1;DAKERA_L2_CACHE_PATH is gone (v0.12 reads no such name; an upgraded deployment warns, a fresh
install refuses): the data root is DAKERA_STORAGE_PATH (/data), and every local path derives
from it. The compose files mount the data volume there and keep your old volumes where the
tiers expect them (/data/cache for the warm tier, /data/hot for the hot tier);DAKERA_CACHE_REDIS_URL is gone (use DAKERA_REDIS_URL), DAKERA_NODE_ID is now
DAKERA_CLUSTER_NODE_ID (the old name is still honoured as an alias),
DAKERA_S3_ACCESS_KEY/DAKERA_S3_SECRET_KEY are not read (use
AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), DAKERA_LOG_LEVEL is not read (use RUST_LOG);/health/ready with a 10-minute start period (the port answers while models
load; Kubernetes uses /health/live for liveness and /health/ready for readiness);dakera-models at /app/models): the image ships bge-large and the reranker
itself; any other model downloads there on first use. A model volume kept from v0.11 can be
freed with docker compose run --rm dakera models prune once you are staying on v0.12;docker-compose.ha.yml): set DAKERA_CLUSTER_SECRET (>= 16 characters, the same
on every node; the file refuses to start without it). Each node now has its own bucket
(dakera, dakera-2, dakera-3); nodes sharing one bucket are refused on a fresh install.
dakera-1 keeps dakera; dakera-2/dakera-3 fill from their peers at start. v0.11 nodes send no
secret and 0.12.1 nodes require one, so they do not see each other: upgrade every node in one window
(see Upgrading from v0.12.0 to v0.12.1, step 3).smart_score should re-check their
threshold. Details: the server UPGRADE.md, "Before you upgrade".docker compose pull && docker compose up -d (Kubernetes: kubectl apply -k k8s/).
Watch GET /health (config_warnings, embed_migration).v0.12.1: nothing to do. Full-text indexes built by v0.11 (without stemming, so release missed
released and keyword-style recall could return nothing) are re-analysed under the configured analyzer in
the background at startup, one namespace at a time, while they keep serving; a restart resumes, and each
cluster node does its own. Watch the log for Full-text index re-analysed under the configured analyzer.
An index holding documents that exist only in the index (POST /v1/namespaces/<ns>/fulltext/index) keeps
its analyzer instead of dropping them (logged).
Still on v0.12.0 with data from v0.11.108: rebuild them by hand, once, with a global admin key, after
GET /health/ready answers 200 (about 18 s for 18,000 memories; memories are not touched):
DAKERA_URL=http://localhost:3000 DAKERA_ROOT_API_KEY=... scripts/post-upgrade-reindex.sh
# or: curl -X POST $DAKERA_URL/admin/fulltext/reindex -H "x-api-key: <global admin key>" \
# -H "content-type: application/json" -d '{"rebuild": true}'
Without namespace it covers every agent memory namespace; add "namespace": "<ns>" (or
DAKERA_NAMESPACE) for one. On Kubernetes, kubectl port-forward svc/dakera 3000:3000 first.
Check it: a keyword search (POST /v1/namespaces/<ns>/fulltext/search with a common word) returns
hits, and a short keyword recall returns memories.
Going back from v0.12 (v0.12.0 or v0.12.1) to v0.11.108 is supported (every v0.11 embedding model, encrypted or not),
except for a store that uses a v0.12-only feature: dakera downgrade refuses (exit 78, nothing changed)
a store on bge-m3 (multilingual), colbert-small / late interaction or the visual lane. Move such a
store to a v0.11 model under v0.12 first, or restore a backup taken before you turned the feature on.
dakera downgrade converts the data back, and must run as a one-off job after the server has
stopped (it refuses, exit 78 with nothing changed, while a server runs on the data):
cd docker
docker compose stop dakera-watchdog dakera
docker compose run --rm -T dakera downgrade > downgrade-report.json # JSON report on stdout (the log goes to stderr); exit 0 = data is v0.11.108's
# then start v0.11.108 with the v0.11 files (git checkout release/0.11):
DAKERA_IMAGE=ghcr.io/dakera-ai/dakera:0.11.108 docker compose up -d
0: done. Exit 1: not yet (do not start v0.11; fix the cause and rerun). Exit 78: refused,
nothing changed: a server still runs on the data (its marker is refreshed every few seconds; a killed one
stays live up to 120 s), the store uses a v0.12-only feature, or no data was found where the
configuration looks (an empty or wrong volume / bucket).kubectl apply -f k8s/dakera/downgrade-job.yaml after scaling the Deployment to 0.docker run --rm <same env and volumes> ghcr.io/dakera-ai/dakera:0.12.1 downgrade.docker/docker-compose.ha.yml).dakera models prune: re-seed the model volume first (server UPGRADE.md, "Going back to v0.11").v0.12.0 adds multilingual search, multimodal memory, multi-vector records, late interaction, a RaBitQ search mode, rerank controls, a model store, a keyring for encryption keys, and a reworked reliability and observability layer. Every new feature is off by default: the files above deploy a server that behaves like v0.11.108's. Each feature is switched on by an overlay file, a Kustomize component or a Helm value, and is described, with its variables, resources, constraints and how to verify it, in docs/features-v0.12.md.
cd docker
docker compose -f docker-compose.yml -f docker-compose.multilingual.yml -f docker-compose.multimodal.yml up -d
docker compose -f docker-compose.ha.yml -f docker-compose.ha.multilingual.yml up -d
kubectl apply -k k8s-features/overlays/multilingual-multimodal
Things to know before you switch one on:
/health embedding_model_change). Late interaction and
vision are still refused on a store embedded otherwise: use a fresh store, or migrate
(DAKERA_ALLOW_MODEL_CHANGE=1 for one start, then POST /admin/namespaces/migrate-dimensions). They set
DAKERA_TIERED=0: the tiered embedding engine, which the quick-start files enable, pins bge-large and
refuses late interaction.bge-large and the reranker are not in the image: they download into the
dakera-models volume on first use (docker compose run --rm dakera models pull bge-m3 whisper vision
ahead of time; HF_ENDPOINT, HTTPS_PROXY and HF_HUB_OFFLINE in .env for mirrors, proxies and
air-gapped hosts).GET /v1/capabilities, and GET /health.Step-by-step guides in the examples/ directory:
dakera-deploy/
├── .devcontainer/ # VS Code / Cursor devcontainer
│ ├── devcontainer.json # Container config (extensions, ports, env)
│ └── docker-compose.yml # Dakera + MinIO dev services
├── docker/ # Docker deployment configs
│ ├── Dockerfile # Production multi-stage build
│ ├── Dockerfile.dev # Dev build with fast incremental compilation
│ ├── Dockerfile.local # Lightweight build from pre-built binary
│ ├── docker-compose.yml # Default: Dakera + MinIO
│ ├── docker-compose.dev.yml # Dev: MinIO only (run Dakera locally)
│ ├── docker-compose.local.yml # Local: single instance, in-memory
│ ├── docker-compose.ha.yml # HA: 3-node cluster + Traefik LB
│ ├── docker-compose.<feature>.yml # v0.12 opt-in overlays: multilingual, multimodal, vision,
│ │ # late-interaction, records, rabitq
│ ├── docker-compose.ha.<feature>.yml # their HA twins (all but vision)
│ └── traefik-dynamic.yml # Traefik routing and load balancer config
├── k8s/ # Kubernetes manifests (production)
│ ├── namespace.yaml # dakera namespace
│ ├── configmap.yaml # Non-secret server configuration
│ ├── secret.example.yaml # Secret template (never commit secrets)
│ ├── dakera/ # Dakera server
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ ├── hpa.yaml # Horizontal Pod Autoscaler (not applied by default in v0.12)
│ │ ├── check-config-job.yaml # One-off: pre-upgrade `dakera --check-config`
│ │ └── downgrade-job.yaml # One-off: rollback `dakera downgrade`
│ ├── dashboard/ # Dashboard UI
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ ├── mcp/ # MCP server manifests (not applied: dakera-mcp is stdio-only)
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ ├── minio/ # MinIO (use native S3 in cloud)
│ │ ├── statefulset.yaml
│ │ └── service.yaml
│ ├── monitoring/ # Prometheus + Grafana
│ │ ├── prometheus.yaml
│ │ └── grafana.yaml
│ ├── ingress.yaml # Nginx ingress (edit hostnames)
│ └── kustomization.yaml # kubectl apply -k k8s/
├── k8s-features/ # v0.12 opt-in features for Kubernetes (Kustomize)
│ ├── components/ # models-cache, multilingual, multimodal, vision, records,
│ │ # late-interaction, rabitq
│ └── overlays/ # ready-made combinations: kubectl apply -k k8s-features/overlays/<name>
├── docs/
│ └── features-v0.12.md # What v0.12.0 adds, per feature: variables, resources, constraints, verify
├── monitoring/ # Observability stack
│ ├── docker-compose.yml # Standalone monitoring compose
│ ├── prometheus.yml # Prometheus scrape configuration (single node)
│ ├── prometheus.ha.yml # ... and for the 3-node HA stack
│ ├── alerting-rules.yml # Deploy-side alert rules (latency, resources, MinIO)
│ ├── alerting-rules.ha.yml # HA node-count alerts
│ ├── dakera.rules.yml # The server's v0.12 alert rules (copied verbatim)
│ └── grafana/ # Grafana provisioning
│ └── provisioning/
│ ├── datasources/
│ │ └── datasources.yml # Prometheus + Jaeger datasources
│ └── dashboards/
│ ├── dashboards.yml # Dashboard auto-provisioning config
│ └── json/
│ ├── dakera-overview.json # The server's v0.12 dashboard
│ └── dakera-memory-api.json # Memory API throughput and latency
├── examples/ # Deployment guides and references
│ ├── quickstart.md # Zero-to-running tutorial
│ ├── environment-variables.md # Complete env var reference
│ ├── production-checklist.md # Pre-production checklist
│ └── backup-restore.md # Backup and restore procedures
├── LICENSE
├── CHANGELOG.md
└── README.md
Dakera sends product telemetry by default, to count how many engines run and how they run. In v0.12 it is lifecycle events (engine_started, engine_stopped, engine_crashed, engine_version_changed) and a heartbeat every 6 hours: version, platform, deployment kind, storage topology, resource use, request counts and latency bands by type, memory / agent / namespace counts, the names of the configuration variables that are set and the values of the non-text ones. It also sends the machine's hostname, and PostHog keeps the connecting IP address and derives a coarse location from it, so it is not anonymous at the network level. Memory content, queries, ids, keys, secrets, paths and URLs are never transmitted, and there is no license check against a remote server. Everything sent is listed in the server's docs/telemetry.md.
To disable it, set either of:
DAKERA_TELEMETRY=off # or 0 / false / no
DO_NOT_TRACK=1 # honored as an unconditional opt-out
Fully air-gapped operation is supported (a failed send is one debug log line). Inspect the exact payload before it is sent with DAKERA_TELEMETRY_DEBUG=1.
The image ships bge-large and the reranker and loads them in seconds with no network. Any other
model (DAKERA_MODEL=bge-m3, whisper, vision, GLiNER) downloads on first use into the model cache
(/app/models, the dakera-models volume). Pre-pull / air-gapped:
docker compose run --rm dakera models pull <model>; inspect with models list; free space with
models prune. Mirrors, proxies and offline hosts: HF_ENDPOINT, HTTPS_PROXY / HTTP_PROXY / ALL_PROXY / NO_PROXY and HF_HUB_OFFLINE in .env. See docs/features-v0.12.md and the server's models-and-docker.md.
Set by the overlay files listed under Features in v0.12.0; the variables, their defaults
and constraints are in docs/features-v0.12.md and docker/.env.example.
┌─────────────────────────────────────────────┐
│ Client Applications │
└──────────────────┬──────────────────────────┘
│
┌────────▼────────┐
│ Traefik LB │
│ :3100 (HTTP) │
│ :50151 (gRPC) │
│ :8080 (Admin) │
└───┬────┬────┬───┘
│ │ │
┌─────────────┼────┼────┼─────────────┐
│ │ │ │ │
┌─────▼─────┐ ┌────▼────▼┐ ┌▼──────────┐ │
│ Dakera-1 │ │ Dakera-2 │ │ Dakera-3 │ │
│ (primary) │ │ (replica)│ │ (replica) │ │
│ :3000 │ │ :3000 │ │ :3000 │ │
│ :50051 │ │ :50051 │ │ :50051 │ │
│ :7946 │ │ :7946 │ │ :7946 │ │
└─────┬─────┘ └────┬─────┘ └─────┬─────┘ │
│ │ │ │
│ Gossip Protocol │ │
│ (cluster membership) │ │
│ │ │ │
└────────────┼──────────────┘ │
│ │
┌───────▼───────┐ │
│ MinIO │ │
│ (bucket/node) │ │
│ :9000 / :9001 │ │
└───────────────┘ │
│
┌──────────────────────────────────────┘
│ Monitoring (optional)
│
┌─────▼──────┐ ┌────────────┐
│ Prometheus │───▶│ Grafana │
│ :9190 │ │ :3203 │
└─────────────┘ └────────────┘
Key HA Features:
All three build from a dakera source checkout (run them from its root); the published image,
ghcr.io/dakera-ai/dakera:0.12.3, is what the compose files and manifests here use.
curl http://localhost:3000/health
curl http://localhost:3000/admin/cluster/status
# All services
docker compose -f docker-compose.ha.yml logs -f
# Specific node
docker compose -f docker-compose.ha.yml logs -f dakera-1
docker compose -f docker-compose.ha.yml stop dakera-3
docker compose -f docker-compose.ha.yml start dakera-3
docker compose -f docker-compose.dev.yml up -d --build
Production-grade deployment on Kubernetes. Covers the Dakera server, the Dashboard, MinIO and monitoring (the MCP server is stdio-only and runs next to the MCP client; k8s/mcp/ is not applied). Use docker-compose for local/development; use Kubernetes for production.
# 1. Create secrets (replace values)
kubectl create namespace dakera
kubectl create secret generic dakera-secrets \
--from-literal=DAKERA_ROOT_API_KEY=$(openssl rand -hex 32) \
--from-literal=MINIO_ROOT_USER=minioadmin \
--from-literal=MINIO_ROOT_PASSWORD=$(openssl rand -hex 16) \
--from-literal=AWS_ACCESS_KEY_ID=minioadmin \
--from-literal=AWS_SECRET_ACCESS_KEY=<minio-password> \
--namespace dakera
# Cluster mode only: add --from-literal=DAKERA_CLUSTER_SECRET=$(openssl rand -hex 32)
# 2. Edit ingress hostnames
# Edit k8s/ingress.yaml — replace yourdomain.com with your real domain
# 3. Apply all resources
kubectl apply -k k8s/
# 4. Verify pods are running
kubectl get pods -n dakera
# 5. Check Dakera health
kubectl port-forward -n dakera svc/dakera 3000:3000
curl http://localhost:3000/health/ready # 503 while models load, then 200
The Helm chart has moved to the dedicated dakera-helm repository, which publishes to ArtifactHub and GHCR OCI. Helm 3.8+ required.
# Install from GHCR OCI
helm install dakera oci://ghcr.io/dakera-ai/dakera-helm/dakera --version 0.12.3 \
--namespace dakera --create-namespace \
--set dakera.rootApiKey=$(openssl rand -hex 32) \
--set minio.rootPassword=$(openssl rand -hex 16)
# Install from ArtifactHub index
helm repo add dakera https://dakera-ai.github.io/dakera-helm
helm install dakera dakera/dakera \
--namespace dakera --create-namespace \
--set dakera.rootApiKey=$(openssl rand -hex 32) \
--set minio.rootPassword=$(openssl rand -hex 16)
# Upgrade to a new version
helm upgrade dakera oci://ghcr.io/dakera-ai/dakera-helm/dakera --version <new-version> --reuse-values
# Uninstall
helm uninstall dakera -n dakera
See dakera-ai/dakera-helm for chart source and full documentation.
DAKERA_S3_ENDPOINT to your provider's endpoint and disable MinIO (minio.enabled=false in Helm)k8s/dakera/hpa.yaml is not applied by default. Scale out with cluster mode (one release per node: own bucket, own volume, shared DAKERA_CLUSTER_SECRET)DAKERA_API_KEY is gone, rotate any key the old dashboard carried). It runs as uid/gid 10001 with a read-only root filesystem and a /tmp emptyDir. Keep replicas: 1 (sessions are in memory, or add sticky sessions), enable TLS on the dashboard host in k8s/ingress.yaml (ingress-nginx forwards X-Forwarded-Proto and Host), probes use /_session/healthz. See Dashboard 0.5.2 and Dashboard 0.5.0k8s/ingress.yaml or ingress.annotations in Helm valueskubectl create secret for productionGET /metrics — pods have prometheus.io/scrape: "true" annotations for auto-discoveryBefore deploying to a production or internet-facing environment:
See the Configuration Reference for the full authentication and security documentation.
See the integration guides on dakera.ai for setup walkthroughs.
Self-hosted Dakera AI memory server — Docker Compose, Kubernetes, Helm, HA cluster setup, and monitoring.
Tools
Noch keine Tool-Liste. Remote-Server erhalten eine nach dem ersten Health-Check.
FAQ
Kopieren Sie auf dieser Seite die stdio-Konfiguration für Cursor, Claude Desktop, Claude Code oder VS Code. Sie nutzt die Installation des Herausgebers, keinen PlugMCP-Proxy.
In diesem Eintrag ist keine erforderliche Umgebungsvariable aufgeführt.
Dakera Deploy läuft lokal über stdio.
Zuletzt geprüft: 2026-10-28. Self-hosted Dakera AI memory server — Docker Compose, Kubernetes, Helm, HA cluster setup, and monitoring.