Docs

Getting started

Architecture

How the RenLayer Proxy, Platform API, and Console fit together, one shared PostgreSQL schema, one multi-tenant data model, three deployable components.

RenLayer is split into three deployable components that share a single PostgreSQL schema. Each component owns its concerns; together they form one governance plane.

The three components

  • Proxy (renlayer-proxy): a Rust + Axum reverse proxy that sits in the request path. It receives agent traffic, classifies the call, evaluates policies, runs DLP detectors, forwards to the upstream provider (OpenAI, Anthropic, internal MCP servers, third-party APIs), captures the response, and writes a trace row.
  • Platform API (renlayer-api): a Rust + Axum REST API that owns tenant management, authentication (JWT + OTP), agent and API-key lifecycle, policy CRUD, and trace queries. It is the only component the console talks to.
  • Console (renlayer-console): a Next.js application that renders the dashboard, sessions explorer, agents, policies, DLP rules, and audit log. It is a thin client over the Platform API.

Shared data plane

All three components read and write to the same PostgreSQL database (renlayer schema). This is intentional:

  • The proxy can apply a policy update the moment it lands, with no event-bus lag.
  • The console can drill from a high-level dashboard chart into the exact request body without crossing a service boundary.
  • Tenants, agents, API keys, policies, and traces all share the same multi-tenant identity model.

Request flow

A typical request follows this path:

  1. Your agent calls a model provider through the proxy URL instead of the provider’s URL directly.
  2. The proxy authenticates the agent via its API key, identifies the tenant, and resolves the agent record.
  3. The proxy evaluates policies in priority order. A matching policy can ALLOW, FLAG, or DENY the call.
  4. DLP detectors scan the prompt and response for PII, secrets, source code, and custom patterns.
  5. If the policy allows the call, the proxy forwards it to the upstream provider; otherwise it returns a structured error.
  6. The proxy writes a trace row with status, latency, token counts, redacted body, and any DLP findings.
  7. The console queries the API to surface the trace in the sessions explorer and the audit log.

Multi-tenancy

Every row in the schema (agents, API keys, policies, traces, DLP findings) carries a tenant_id. The Platform API enforces tenant scoping on every query; the proxy resolves a tenant from the API key on every request. There is no shared global state between tenants.

Where to go next

Last updated: