Skip to main content

OpenViking

Context database for AI agents. It exposes a viking:// filesystem holding memory, resources, and skills, so an agent has somewhere durable to keep what it knows — the successor to the LightRAG approach of indexing a notes vault.

Containers

ContainerRole
openvikingREST API, MCP server, and Web Studio (port 1933)

The knowledgebase indexer cron runs in the main decree daemon, and the backup of openviking_data in decree-backup — OpenViking ships no container of its own for either.

Access

  • Containers: http://openviking:1933 on the exist network
  • Browser (Web Studio): https://openviking.EXIST_DOMAIN
  • Agents: Hermes connects to it as an MCP server

Enable

EXIST_IS_AI_OPENVIKING=true

Then ./existential.sh && docker compose up -d from the repo root.

What it indexes

workspace/ at the repo root — the same tree Hermes mounts at /opt/data/workspace and code-server mounts at /workspace. Everything you actually work on is searchable without a second knowledgebase directory to keep in step.

The openviking-index-dir routine uploads it into viking://resources/workspace every 15 minutes. It is incremental: unchanged files are skipped, changed files replace their old copy, and files you delete on disk leave the index on the next run. A first pass over a large tree takes a while — each file is embedded on the way in.

The directory is mounted on the decree daemon, not on openviking. OpenViking's HTTP and MCP APIs both refuse host filesystem paths outright, so content only ever reaches it by upload — which is also why there is no watched-directory setup.

workspace/ai/ — where the agent automations write — is indexed like everything else, so an agent can find and build on what an earlier run produced. It is excluded from the MinIO sync instead, which is what stops that output from triggering more runs. See File Processor.

What it stores

VolumeTierContents
openviking_data2 — local, backed upVector store and workspace. Embedded DB, never NFS.

The upload manifest that keeps unchanged files from being re-embedded lives in the decree daemon's own decree_data volume (/data/openviking-index), not in a volume of its own. It is a cache: losing it costs one full re-index, not any content.