Get started with Ketebe

Pick the shortest path that matches where you are: evaluate the retrieval model, integrate an SDK, or prepare for the packaged v0.9 release.

Choose a path

RecommendedBuild your first query

Create a collection, ingest a document, and query it through the Python SDK.

Release readinessFollow v0.9 packaging

See the work remaining for image publishing, persistent Compose, smoke validation and release assets.

Agent buildersConnect through MCP

Use first-party MCP for governed discovery, retrieval, context assembly and controlled ingestion.

Platform teamsUnderstand operations

Review durability, recovery, governance, TLS/mTLS, backup and isolation contracts.

Local evaluation

The public v0.9 target is intentionally simple: persistent standalone Docker Compose, then create → write → query. Until packaged artifacts are published, the source repository remains the authoritative way to run Ketebe.

# Target v0.9 onboarding

docker compose up -d
curl http://localhost:7610/health

First-party SDKs

Ketebe maintains first-party Rust, Python, TypeScript, Java and Go SDKs. REST and gRPC remain stable product boundaries underneath them so applications are not coupled to deployment topology.

SDKPython

Fastest path for retrieval experiments, agents and application integration.

SDKTypeScript

For web backends, AI application services and JavaScript ecosystems.

SDKGo / Java / Rust

First-party clients for platform services and strongly typed production stacks.

ProtocolREST + gRPC

Use the product API directly when SDK abstraction is not the right fit.

Path to production

Ketebe does not define production readiness as “the process starts.” The release path includes persistent storage, restart validation, recovery drills, compatibility checks, repeatable benchmarks, security boundaries and upgrade evidence.

Principle: correctness before optimization. Performance claims require repeatable benchmarks, and derived indexes must remain rebuildable from a recoverable source of truth.