Riven Platform
LiveOne account, one key, one bill across every Riven surface. This page is the architectural map: what the layers are, which service owns what, and where to go next.
The shape of the platform#
Riven is a single platform presented through many surfaces. A surface is a user-facing application — Chat, Computer, Studio, Console. Every surface authenticates against the same identity, spends the same quota, and reaches models through the same gateway. There is no per-product signup and no per-product key.
| Layer | What lives there | Examples |
|---|---|---|
| Surfaces | Applications people sign in to | Chat, Computer, Console, Studio, Discover, Docs, Pages, Evals, Status, Trust |
| Gateway | The OpenAI-compatible API and its routing | Riven API, Ultra Router |
| Identity & secrets | Who you are, what you may do, what you hold | Riven Auth, Keymaster, SCIM Proxy |
| Infrastructure | Scheduling, telemetry, grounding, proxying | Fleet Scheduler, Telemetry, Edge Proxy |
| Inference | The models that actually answer | On-prem fleet, cloud fallback |
| Business | Operations for a company running on Riven | Commerce, Business Suite, ERP |
One request, end to end#
- A surface (or your own code) calls
https://api.rivenai.io/v1/chat/completionswith arvn_key. - Riven Auth resolves the key to an account and plan; Keymaster supplies any upstream provider credential needed.
- Ultra Router resolves the requested alias to a concrete model, preferring the on-prem fleet.
- If no on-prem pool is healthy, the router fails over to a cloud provider — the response reports which pool served it via
x-riven-upstream. - Telemetry records tokens, latency, and cost; quota is decremented against your plan.
Sovereignty by default#
The routing preference is on-prem first, cloud second — not the other way around. Riven runs its own inference fleet, and cloud providers exist as overflow and as access to models Riven does not host. That ordering is what makes a fully sovereign deployment possible: cut the cloud upstreams and the platform still answers.
The same principle applies to the operational stack. Riven is self-hosted on Docker Swarm, deployed with Dokploy and fronted by Traefik. There is no dependency on a managed application platform, so a deployment can be lifted into a customer datacentre without rewriting the delivery pipeline.
Service naming#
Surfaces map to Swarm services under the riven stack, prefixed surfaces_. The docs page you are reading is served by riven-surfaces_website. Each product page in these docs names its service so operators can move between the documentation and docker service ls without a translation table.