Cradle as a datacenter service

Cradle can be delivered as a managed datacenter service. Rather than renting GPUs, you sell a verified result: the customer provides a task and data, Cradle's agents work under the two-tier risk system, an operator approves or edits, and the customer receives a verified answer with a full audit trail and source citations.

[task + data] ──► [Cradle: triage + agent + RAG] ──► [risk: approve/edit/reject] ──► [result]
                                                          │
                                                          └─► audit: risk assessments,
                                                              cited sources, cost events

This maps onto Cradle almost for free: the two-tier risk system, the audit log, and cost tracking already exist. Billing becomes a hook on the approval of a ticket, not a new subsystem.

Terminology

Getting these straight avoids most of the confusion:

• Tenant — one isolated customer. Each tenant has its own infrastructure and its own database; tenants cannot share a perimeter. A tenant is a separate cradle-server (its own data directory, database, perimeter), not a row in a shared table.
• Project — a subdivision inside a tenant (its own agents, knowledge bases, tickets, keys). projectId splits data within a tenant's perimeter but does not replace isolation between tenants.
• Topology — where each piece physically runs and what talks to what.

Topologies (simple to complex)

T0 — everything on one server (recommended start)

cradle-server plus a local LlamaCppRunner (CUDA) on a GPU node. The client is a thin console over the API. Brain and inference live together. Least new code.

[GPU node]
  cradle-server + LlamaCppRunner(CUDA)   ◄──API── [client] (console)
       ▲ connector traffic (Telegram / widget / API into the server)

T1 — control plane + data plane split

Cradle manages an inference daemon on a separate GPU box: lifecycle and model selection over a control channel, inference traffic over HTTP. Implemented as a remote-gpu provider module plus a thin controller.

[cradle-server]  ──control──► start/stop daemon, load model
        │        ──HTTP─────► generate / embed
        ▼
[GPU box]  llama.cpp-server / vLLM (managed)

T2 — shared GPU pool + queue

Scaling, spot instances, automatic task distribution across a pool. This is the advanced end of the spectrum — not something to build until T0 is working.

Tenant isolation

Hard requirement: every tenant has its own infrastructure and its own database; tenants cannot share a perimeter. Isolation is therefore instance-per-tenant — a separate cradle-server (its own data directory, database, perimeter) per tenant. A shared instance with "project = tenant" is explicitly ruled out, because it would breach the perimeter.

[tenant A perimeter]              [tenant B perimeter]
  cradle-server  ~/.cradle-A        cradle-server  ~/.cradle-B
    ├─ project A1                     ├─ project B1
    └─ project A2                     └─ ...
  (own DB, own keys)                (own DB, own keys)

projectId works inside a tenant's perimeter: it partitions agents, knowledge bases, tickets, and cost events, and supports scoped API keys and per-project budgets. Isolation between tenants comes from separate instances, never from projectId.

Why SQLite, not Postgres

Under an instance-per-tenant model, an embedded SQLite database is a deliberate choice, not a shortcut:

• Embedded, not a service. SQLite lives inside the cradle-server process as a file — no separate daemon, network port, DB roles, or separate backup. "Data never leaves the perimeter" becomes literal: one file in the tenant's data directory.
• Vector search built in. RAG runs on sqlite-vec in the same database and process. The Postgres equivalent would require a pgvector server — trading "zero infrastructure" for a whole database server just for the vector index.
• The load profile fits. One instance per tenant, operator-driven triage (tens to hundreds of messages), single-writer better-sqlite3 with headroom. The bottleneck is the GPU, not the database.

Postgres becomes relevant only at the T2 pool stage, and even there per-tenant isolation still pushes toward a database per tenant rather than one shared one.

Instance isolation ladder

The datacenter chooses the isolation level per its perimeter requirements:

GPU sharing between instances: a whole card per tenant (simplest), a partition via MIG (A100/H100) or time-slicing, or a shared pool through the remote-gpu provider (T1) so tenant instances share the pool rather than the hardware directly.

Delivery models

• Curl installer — for open / self-hosted cases with internet access.
• Self-contained tarball — bundled JS + prebuilt native modules, for closed networks with no registry.
• VM image — the datacenter keeps a golden image with Cradle Server preinstalled; the customer downloads only the client and pastes in credentials.

To talk about a managed deployment, get in touch. For the underlying install mechanics, see remote-server deployment.