Remote server (closed networks)

Deploy cradle-server on a remote host in a closed network, operator-driven through a jump host, and distribute credentials to clients.

In closed networks, servers are reached through a jump host, so Cradle never pushes a deployment over SSH from a client — there is no cradle deploy user@server. Deployment is always operator-driven on the server itself. This page covers that flow.

The flow

1. The operator logs in to the server (via the network's jump host).
2. Installs the Cradle CLI / server bundle.
3. `cradle server init`   → deploys cradle-server (under systemd)
4. `cradle keys create …` → issues credentials (ck_live_…) for clients
5. The operator transfers the credentials to the Cradle client(s);
   each client connects by address + key.

What actually ships to the server

cradle-server is not a single static binary. The build bundles dist/server/index.js, but deliberately keeps native modules external: better-sqlite3, node-llama-cpp, sqlite-vec, fastify. So the target host needs, at runtime:

A Node 22 runtime.
The bundle dist/server/index.js.
node_modules with native dependencies compiled for the target OS + GPU (better-sqlite3 is an ABI addon; node-llama-cpp pulls a llama.cpp binary for CUDA/CPU).

There are three delivery forms:

Form	What you deliver	Closed network	Effort
A. curl installer	`install.sh` + zip from S3; the host runs `pnpm install --prod` + `pnpm rebuild`	⚠️ needs a registry / internet during install	low
B. Self-contained tarball	archive with bundled JS + `node_modules` prebuilt for linux-x64 + CUDA (optionally Node)	✅ fully offline after delivery	medium
C. VM image / `docker save`	a ready image with everything inside	✅	high to build, trivial for the user

Form A is the default for open / self-hosted cases with internet access. For a closed network, the primary artifact is a self-contained tarball (B), which is also what goes into a VM image (C).

Install flow on the VM (Form A)

# 1. Download the bundle (from the landing page or directly from S3)
curl -fsSL -o cradle-cli-${VERSION}-linux-x64.zip \
  https://download.opencradle.ai/cradle-cli/${VERSION}/cradle-cli-${VERSION}-linux-x64.zip

# 2. Extract to /opt/cradle
sudo mkdir -p /opt/cradle
sudo unzip -o cradle-cli-${VERSION}-linux-x64.zip -d /opt/cradle

# 3. Run install.sh (creates the `cradle` user, installs prod deps,
#    rebuilds native modules, installs the systemd unit)
cd /opt/cradle
sudo ./install.sh

# 4. Bootstrap: create DB, admin key, client credentials, start the service
sudo /opt/cradle/dist/cli/index.js server init \
  --data-dir /var/lib/cradle \
  --port 31416 \
  --bind 0.0.0.0 \
  --install-systemd

# 5. Collect credentials from /var/lib/cradle/client-credentials.json and
#    transfer them to the Cradle client through the secure channel (jump host).

What is inside the zip:

cradle-cli-<version>-linux-x64.zip
  ├─ dist/server/index.js
  ├─ dist/cli/index.js
  ├─ package.json          # production cut
  ├─ pnpm-lock.yaml
  ├─ systemd/cradle-server.service
  └─ install.sh            # run as root on the target host

Fully offline (Form B / C)

For a network with no registry, build a self-contained tarball ahead of time — bundled JS plus node_modules prebuilt for the target platform (and optionally a bundled Node) — and transfer the whole thing:

tar xzf cradle-server-*-linux-x64-cuda.tar.gz -C /opt/cradle
/opt/cradle/cradle server init          # systemd unit + bootstrap admin key
cradle keys create --name client-1 …    # credentials → to the client

Because the llama.cpp binary and the better-sqlite3 addon are platform/ABI-specific, there is a tarball per GPU target (cpu, cuda, optionally rocm), produced by a build matrix in the release pipeline.

Target host requirements

Linux x86_64.
Node 22 + pnpm (corepack enable or npm install -g pnpm@9).
Root for install.sh and cradle server init.
For GPU inference: NVIDIA drivers + CUDA toolkit. CPU-only works without them.

Connect a client

cradle login --url http://<server>:31416 --key ck_live_...

For multi-tenant delivery where each customer gets an isolated instance, see Cradle as a datacenter service.