Skip to main content

Self-Host Rivaro

Run Rivaro on your own infrastructure when you need full data residency, custom networking, or to keep request bodies inside your VPC. Self-hosting gives you the same proxy, detection pipeline, policy engine, and signed-receipt ledger as Rivaro Cloud — you just own the deployment.

Trying Rivaro for the first time?

For evaluation, Run Rivaro Locally on your laptop in two minutes, or Use Hosted Rivaro for a managed dashboard. Self-hosting is for production deployments that must run inside your own cloud.

Deployment shapes

Two deployment shapes are supported:

  • Docker Compose — the end-to-end production path (proxy, dashboard, MySQL, RabbitMQ on one VM, behind a rivaro CLI)
  • Helm chart — backend-only, for customers who want to run the governance engine on Kubernetes alongside their own MySQL and RabbitMQ

For multi-node Kubernetes deployments, reach out at [email protected] and we'll scope it with you.

What you get​

  • The full Rivaro stack (proxy, detection workers, dashboard, MySQL, RabbitMQ) running in Docker on a Linux VM you own
  • A rivaro CLI for install / upgrade / SSL / backup / logs
  • Pre-built images pulled from ghcr.io/rivaro-ai, version-pinnable via RIVARO_VERSION
  • WorkOS SSO for dashboard authentication
  • Let's Encrypt automation for HTTPS

What you'll need​

  • A Linux VM — 2 CPU, 4 GB RAM minimum (8 GB recommended), 50 GB disk, Docker 20+ and Docker Compose v2+
  • A domain name pointed at the VM (e.g. compliance.yourcompany.com)
  • A WorkOS account for SSO (workos.com)
  • AI provider credentials for at least one of: AWS Bedrock, OpenAI, Anthropic, or Azure OpenAI
  • A Rivaro license key — contact [email protected]

Architecture​

                ┌──────────────┐
   Your Agents ─┤    nginx     ├─▶ Rivaro Proxy ─▶ Detection ─▶ Policy ─▶ Provider
                │ (TLS, Let's  │        │
                │  Encrypt)    │        ▼
                └──────────────┘  Signed Receipt
                                     Ledger
                                        │
                                        ▼
                                     MySQL

The Compose stack runs the backend, frontend, MySQL, RabbitMQ, and an nginx fronting the whole thing on ports 80/443. All services live on a single Docker network on a single host.

Quick start (Docker Compose)​

The full runbook lives in deployment/README.md in the repo. The short version:

# 1. Install the CLI and deployment files
#    Download scripts/get-rivaro.sh from the repo, review it, then run:
bash get-rivaro.sh

# 2. Configure
rivaro config   # opens /opt/rivaro/.env in your editor

# 3. Install
rivaro install

# 4. Get a Let's Encrypt cert (after DNS is pointing at the box)
rivaro ssl

Required .env values: DOMAIN_NAME, MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD, WORKOS_API_KEY, WORKOS_CLIENT_ID, SECRETS_MASTER_KEY, JWT_SECRET, RABBITMQ_PASSWORD, SSL_EMAIL, plus credentials for one AI provider.

CLI reference​

CommandDescription
rivaro installRun the full installation
rivaro statusShow service status
rivaro logs [service]Stream logs (all services, or one like backend)
rivaro start / stop / restartLifecycle control
rivaro upgradePull latest images and restart
rivaro sslSet up Let's Encrypt
rivaro backup [file]Back up the database to a SQL file
rivaro configOpen .env in your editor
rivaro versionShow CLI and image versions

Version pinning​

By default the stack runs latest. Pin a specific build by adding to .env:

RIVARO_VERSION=1.0.0

Run rivaro upgrade after changing the value.

Production checklist​

  • Secrets — keep .env outside source control; consider mounting secrets from your platform's secret manager
  • Database backups — schedule rivaro backup (or a managed snapshot if you swap in an external MySQL)
  • TLS — rivaro ssl handles Let's Encrypt; for internal-only deployments, terminate TLS at your load balancer and skip the bundled cert flow
  • Network egress — the proxy needs outbound HTTPS to the model providers you govern and to api.workos.com
  • Monitoring — rivaro logs is fine for spot checks; for production wire docker compose logs into your log aggregator

Kubernetes (Helm chart, early access)​

A Helm chart for the governance engine backend lives in the repo at helm/rivaro-governance/. Get in touch before using it in production so we can review your topology with you.

What the chart deploys

  • The Rivaro governance engine (ghcr.io/rivaro/governance-engine)
  • Kubernetes Deployment, Service, optional Ingress, HPA, PodDisruptionBudget, ServiceMonitor, and PrometheusRule
  • A bundled Grafana dashboard JSON (dashboards/governance-overview.json)

What the chart does not deploy

  • The dashboard frontend
  • MySQL — bring your own MySQL 8.0+ (e.g. RDS, Aurora, Cloud SQL, in-cluster operator)
  • RabbitMQ — bring your own AMQP-compatible broker
  • TLS — terminate at your ingress controller / LB

Install (from the repo today; no published Helm repo yet)

git clone https://github.com/rivaro-ai/ai-compliance
cd ai-compliance/helm/rivaro-governance

# Customize: database.host, rabbitmq.host, auth.workos.*, providers.*, ingress.*
helm install rivaro . -f my-values.yaml -n rivaro --create-namespace

Required values: database.host + credentials, rabbitmq.host + credentials, auth.jwt.secret, secrets.masterKey, WorkOS keys, and at least one AI provider. See values.yaml for the full set of overrides.

Tunables worth knowing about

  • replicaCount (default 2) and autoscaling.enabled for HA
  • governance.failMode: closed (default) vs open — block vs pass-through on failure
  • governance.gateway.* — rate limits and quarantine/terminate thresholds
  • serviceMonitor.enabled and prometheusRule.enabled for Prometheus Operator users

Next steps​