Clients, CLI, and frontend¶

All interfaces can use the Atlas example dataset. Load it into one evaluation server, then use the same Service/Atlas, Server/web-01, Location/Oslo, and Context/Research notes records across clients. Resolve numeric IDs from names; import does not promise fixed IDs.

These are the current companion projects. Their documentation remains with their source so installation details and examples can track each release.

Web frontend¶

Use the frontend for browser workflows. Its server-side backend-for-frontend holds Hubuum bearer tokens; the browser uses a session cookie. Multi-replica installations share session state through Valkey.

The single-host installer can deploy the frontend and server together. Follow its proxy routing instructions: the frontend owns /_hubuum-bff/..., while /api/v0/... and /api/v1/... belong to the Hubuum server. For frontend-only deployment and settings, use the frontend repository.

Command-line interface¶

The Hubuum CLI provides one-shot commands, an interactive REPL, and script execution. Start with its usage guide and release downloads.

The client executable hubuum-cli is different from hubuum-admin. hubuum-cli connects through the HTTP API. hubuum-admin ships with the server and handles local administration such as database migrations, password resets, and the restore executor.

Rust client¶

hubuum_client provides async and blocking clients, typed resource IDs, query builders, and task helpers.

• Versioned setup, examples, and guides.
• Generated Rust API reference.

The HTTP client is distinct from the server's storage adapter SDK. Application integrations normally use the client, not the internal root hubuum crate.

Python client¶

hubuum-client-python provides typed synchronous and asynchronous clients. The distribution is named hubuum-client and its import package is hubuum_client.

• Versioned installation, guides, and API reference.
• Client configuration.
• Queries.
• API guide.

Choose compatible versions¶

Do not infer compatibility from matching version numbers or from a latest tag. Each companion project declares its server targets independently:

Use the records for the version you deploy; the default-branch documents may describe newer behavior. Verify the workflows you rely on, especially credential approvals, imports, schema changes, and backup formats. The server's integration coverage explains which contracts currently have real-system evidence.