Ultrahost/ docs
ProductGet early access

Design proposal · not an implementation specification

Proposed v1.0

The Ultrahost SDKCreate, configure, use.

A TypeScript, React, and REST surface for Ultrahost's building blocks. Common work is one function call. Infrastructure stays out of application code.

Ultrahost is a managed backend you can take home. This reference describes the SDK and API a developer — or a coding agent — would use to build on it. It covers all 14 building blocks. It is a design proposal, not a shipped client and not a description of the current Renglo backend.

A client

ts
import { createClient } from "@ultrahost/sdk";

const ultrahost = createClient({
  projectId: "my-project",
  token: userAccessToken
});

Every building block hangs off that client:

documents · timeseries · cron · llm · vectors · contracts · search · auth · authorization · sessions · files · rag · graph · functions

The browser client uses the signed-in user's permissions. Creating resources, managing secrets, and other privileged work use createAdminClient() from @ultrahost/admin. The catalogs in this reference describe the full surface. They are not a promise that every method is safe to call from a browser.

Five principles

  1. Create, configure, use. Each building block follows the same lifecycle, and each reference page is organized that way.
  2. Simple things are one call. A document, a search, or a grounded answer should not require a ceremony.
  3. Complexity is optional. Advanced settings exist, and an application can ignore them.
  4. Cloud independence. The SDK does not expose AWS, Azure, DynamoDB, or other infrastructure concepts. Resources have names such as "projects" and "daily-report".
  5. Agent-friendly. Names are predictable and strongly typed, so a coding agent can discover them. Capabilities tell the agent what a project actually supports.

Building blocks

P0Document Database

Store structured JSON without rigid tables.

P0Federated Auth

Sign users in and manage identities.

P0Authorization

Decide who can act on which resource.

P0File Server

Upload, transform, and deliver files.

P0Custom Functions

Run application logic without servers to maintain.

P1Search Engine

Full-text search, ranking, and suggestions.

P1Vector DB

Find information by meaning.

P1LLM Plane

One interface for models, budgets, and fallbacks.

P1RAG

Answers grounded in your own documents.

P2Timeseries

Measurements, aggregates, and trends.

P2Graph DB

Entities, relationships, and traversals.

P2Cron

Scheduled work without a resident process.

P2Agent sessions

Context, history, and checkpoints for agents.

P2Schemas & ontologies

Versioned structure and meaning for your data.

P0 is the foundation to implement first. P1 is intelligence and discovery. P2 is the specialized systems. The sequence is about implementation, not about hiding later blocks. All 14 should have a defined contract before implementation starts. Read Architecture for why the groups are split that way.

What a call looks like

ts
await ultrahost.documents.create("projects", data);

await ultrahost.search.query("projects", {
  text: "renovation"
});

await ultrahost.vectors.search("projects", {
  query: "home improvement ideas"
});

await ultrahost.llm.generate({
  capability: "project-advisor",
  input: data
});

await ultrahost.functions.invoke("process-project", data);

Start with Getting started, then Conventions for the rules every endpoint shares.