Platform.

The Platform is what makes Kvendra a system instead of a copilot. Three things it gives you that a vector store, a prompt cache, or a chat history cannot:

1. Typed entities, not blobs. Twenty schema'd entity types — components, contracts, requirements, releases, ADRs, runbooks, incidents — with relations and versioned changelog. Your AI reads structure, not paragraphs.
2. Transactional pipeline. Every mutation lands inside a transaction (begin · stage · commit / cancel). Skills group their work, the KB stays coherent, and rollback is a built-in primitive — not an after-the-fact migration.
3. Hybrid search. Semantic (pgvector) plus typed filter — "every component that depends on auth-service" is one query, not a prompt engineering exercise.

The recommended path is Docker — the image ships with the TS service, runs the migrations on first boot, and writes the bearer token to a mounted volume so it survives restarts. Three embedding routes (Kvendra Cloud / Ollama / mock); the Claude Code wiring is identical on all three.

export KVENDRA_EMBEDDINGS_API_KEY=sk_kv_…

docker pull kvendra/kvendra-platform:latest

docker run -d -p 7777:7777 --name kvendra \
  -e EMBEDDINGS_PROVIDER=kvendra \
  -e KVENDRA_EMBEDDINGS_API_KEY \
  -v $(pwd)/data:/data \
  kvendra/kvendra-platform

ollama pull nomic-embed-text

docker pull kvendra/kvendra-platform:latest

docker run -d -p 7777:7777 --name kvendra \
  -e EMBEDDINGS_PROVIDER=ollama \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -e OLLAMA_MODEL=nomic-embed-text \
  -v $(pwd)/data:/data \
  kvendra/kvendra-platform

docker pull kvendra/kvendra-platform:latest

docker run -d -p 7777:7777 --name kvendra \
  -e EMBEDDINGS_PROVIDER=mock \
  -v $(pwd)/data:/data \
  kvendra/kvendra-platform

curl http://localhost:7777/healthz

cat ./data/auth.token

{
  "mcpServers": {
    "kvendra": {
      "type": "http",
      "url": "http://localhost:7777/mcp",
      "headers": { "Authorization": "Bearer <token-from-step-02>" }
    }
  }
}

git clone https://github.com/KvendraAI/kvendra-platform.git

cd kvendra-platform && cp .env.example .env

docker compose up -d --build

Twenty typed entity kinds. Each has its own schema, its own validation rules, its own relation set. The full catalogue:

• PRJproject / workspace root
• CMPcomponent / service
• IFinterface / contract
• REQrequirement
• TESTtest definition
• REGregression run
• ISSUEincident / bug
• RELrelease
• SLAservice-level objective
• ROADroadmap item
• GLOglossary term
• STDcoding standard
• PATpattern / threat model
• ADRarchitectural decision record
• RUNrunbook
• UXUX spec / journey
• DOCmanual / doc entry
• ENVenvironment / deployment target
• COSTcost envelope
• CFGconfiguration / feature flag

The Platform is AGPL-3.0. You can run it free forever, fork it, modify it. There's one clause you should read before going to production:

What this engine is — and isn't

The Platform is the single-tenant KB engine. It runs your KB, your workspace, your typed graph. It is not multi-tenant. It is not the hosted Cloud product (that's the Enterprise tier with shared workspaces, SSO and managed infrastructure).

For most engineers, the right path is: self-host the Platform for free, install the CLI vault for secrets, install the Skills plugin in Claude Code. The whole stack works offline, costs nothing, ships under open licences.