RivetHub

The stable distribution of RivetOS

Your own mesh of AI agents, on your own hardware.

RivetHub is the stable distribution of RivetOS — a mesh of agent nodes plus a central datahub, with harness-agnostic conversation capture and recall. It ships pinned releases and short, readable install scripts.

Install the datahub Add a node
datahub — run from a checkout
# on the host that will be your hub:
$ sudo bash install/datahub.sh --advertise-host 192.0.2.10

The curl form — curl -fsSL https://get.rivethub.io/datahub.sh | bash — is refused in preflight until the helper files are published. A checkout is the path that works today; the datahub guide explains why.

RivetHub mesh topology A central datahub running Postgres, the mesh CA and mesh.json, connected by mTLS to three agent nodes, with one client talking to a node. datahub postgres 16 + pgvector mesh CA mesh.json node-a rivetos runtime node-b rivetos runtime node-c rivetos runtime your client chat · CLI · channels mTLS mTLS mTLS :3000
Every node keeps a local RIVETOS_SHARED_DIR (default /var/lib/rivethub/shared); the datahub stays the source of truth for mesh.json and the CA.
v0.5.0 distro channel self-hosters comfortable root on a box Debian 12 / Ubuntu LTS x86_64 · aarch64

// how it works

Three steps to your own mesh

One datahub, any number of agent nodes, and whatever client you already talk to. Enrollment and sync happen over SSH; node-to-node traffic is mTLS.

  1. Install the datahub

    One host runs Postgres 16 + pgvector, the memory schema, and the mesh certificate authority. The CA root key never leaves that host.

    datahub
    $ sudo bash install/datahub.sh --advertise-host 192.0.2.10
    Full datahub guide →

  2. Install an agent node

    Each node enrolls against the datahub over SSH and gets a mesh certificate — node-to-node traffic is mTLS on mesh port 3000. The installer runs as root, so BatchMode SSH uses /root/.ssh — copy your key there first.

    agent node
    $ curl -fsSL https://get.rivethub.io/node.sh | bash -s -- --hub owner@192.0.2.10
    Full node guide →

  3. Chat

    Point the node at a model provider and a channel — Telegram, Discord, a CLI front-end — and start talking to your agent. The runtime, its config schema, and channel setup are documented at rivetos.dev; this site only covers the distribution and installers.

    rivetos.dev →

// what you get

Built for operators, not demos

  • Memory, captured and recalled

    Conversations are captured into Postgres 16 + pgvector on your own datahub. Semantic recall comes from the optional embedder and compactor workers — off by default (--memory lite), one flag away (--memory full).

  • Mesh delegation

    Nodes enroll over SSH and identify each other by certificate. Node-to-node traffic is mTLS on mesh port 3000, and mesh.json on the datahub is the shared source of truth for who is who.

  • Harness-agnostic

    The capture pipeline sits below the agent harness, so history is captured and recalled the same way whichever front-end you run. No per-harness plugins, no lock-in to one vendor's memory.

  • Bring your own model

    Point each node at any model provider; memory workers take OpenAI-compatible embed and compaction endpoints. There is no RivetHub-run control plane — nothing phones home.

// honest status

Honest status

RivetHub is built for people comfortable running their own Debian/Ubuntu servers. A few things to know up front:

  • The release channel is not pinned yet — every pin in pins/stable.json is still an UNPINNED placeholder, so clones and images float until the first real stable tag. See Releases.
  • install/datahub.sh curl-pipe is refused until the helper files are published; run it from a checkout.
  • rivetos mesh enroll is not merged upstream yet — the node installer implements the same tarball contract over SSH today.
  • Memory workers (embedder / compactor) are off by default (--memory lite).

Read the scripts first.

Curl-pipe installers should be boring. Both install scripts are short, free of hidden control flow, and meant to be read before they are run — the same posture the rest of the distribution follows. Nothing here phones home; the CA root key never leaves the datahub.