The self-hosted deployment guide

Self-hosted, single-tenant, on your terms

Riven is one OpenAI-compatible API plus a chat and agent platform. In the cloud that means one key, one bill, 160+ models. For enterprises that need it, the same platform runs single-tenant on infrastructure you control. The tagline is literal: self-hosted, single-tenant AI for enterprises that demand control, compliance, and performance. Your infrastructure or ours.

This guide covers the shape of a self-hosted deployment at a high level. It is architecture, not secrets — no keys, no internal hostnames, no config that would help an attacker.

Why single-tenant

A shared SaaS LLM gateway is convenient, but it forces a tradeoff: your prompts, your data, and your usage patterns live in a multi-tenant system someone else operates. For regulated industries, customer data with contractual residency requirements, or workloads that simply cannot leave a network, that tradeoff is not acceptable.

Single-tenant means your deployment serves only you. No neighbor traffic on your instances, no shared model caches that could bleed context, no usage data leaving your perimeter. The control plane is yours, governed by Riven Control.

Architecture overview

A self-hosted Riven deployment has four layers:

• Edge / reverse proxy. Terminates TLS, handles routing, and is the only component exposed externally. Everything behind it stays on private networking.
• Application services. The API, the chat surface, and supporting services run as containerized workloads. They deploy identically every time, so the environment in your data center matches the one we run.
• Model routing. Requests are routed to the appropriate model backend. For self-hosted deployments this can point at models served inside your network or at vendor APIs, depending on what your compliance posture allows.
• Governance via Riven Control. Riven Control is the governance plane. It handles access policies, audit, and configuration for the deployment. It is how an enterprise says who can call which model, from where, with what limits.

The deployment shape

At a practical level, a deployment looks like a set of containers behind a reverse proxy on private networking:

[ Internet ]
     |
[ Reverse proxy / TLS edge ]
     |
( private network )
     |
[ Riven API ] [ Chat ] [ Riven Control ] [ Model routing ]
     |
[ Model backends: self-served or vendor APIs ]

The edge is the only public surface. Application services and Riven Control sit on the private network. Model backends can be entirely internal if your policy requires it, or routed to vendor APIs where that is permitted. The boundary is policy, configured in Riven Control, not a hardcoded assumption.

What Riven Control governs

Riven Control is the difference between "a copy of the software running in your network" and "a deployment you can actually operate and audit." It provides:

• Access policy. Which identities can reach which models and surfaces.
• Audit. A record of what was called, by whom, when — kept inside your perimeter.
• Configuration. Model routing, rate policy, and network exposure, managed as config rather than ad-hoc changes on a box.
• Tenant isolation. Because the deployment is single-tenant, these policies apply to your organization only.

Your infrastructure or ours

Some enterprises want the software in their own VPC or on their own metal. Others want the isolation guarantees of single-tenant without operating the platform themselves. Both are supported. We can stand up a single-tenant deployment in your environment, or run one for you that is logically yours — same software, same governance via Riven Control, different operational owner.

What stays constant either way: single-tenant isolation, Riven Control governance, and the same API surface (https://api.rivenai.io/v1 in the cloud path) your engineers already target.

When this is the right choice

Self-hosted single-tenant is not the default for everyone. It is the right choice when one of the following is true: data residency is a hard requirement, a regulator needs an audit trail you fully own, a workload cannot traverse a shared SaaS boundary, or your organization has standardized on running infrastructure it controls. If none of those apply, the cloud platform gets you the same 160+ models with none of the operations.

Get started

Talk to us about a self-hosted deployment by signing up at /sign-up, or read the deployment and governance docs for the operational reference.