Otari Gateway can run in two modes: standalone and connected to Otari.
The main decision is whether you want to run and manage everything locally. Choose standalone mode if you want the gateway to handle credentials, authentication, budgets, and usage itself. Choose connected mode if you want to keep the gateway in your infrastructure while otari.ai handles the management layer.
Choose a mode
Standalone
Use standalone mode when you want the gateway to manage everything locally.
Best for:
You want the full gateway API in one self-hosted deployment.
You manage provider credentials in config.yml or environment variables.
You want to own keys, budgets, and usage storage locally.
Handles:
Local database for keys, users, budgets, and usage
Provider credentials from config.yml or environment variables
Management endpoints like /v1/keys, /v1/users, and /v1/budgets
Connected to Otari
Use connected mode when you want a self-hosted gateway managed by otari.ai.
Best for:
You want the runtime in your infrastructure and management in otari.ai.
You want provider routing and credentials managed by the platform.
You only need health endpoints and chat completions on the gateway.
Handles:
Provider resolution and fallback through otari.ai
Bearer-token authentication from otari.ai
Usage reporting and MCP server resolution through the platform
Quick comparison
Area | Standalone | Connected to Otari |
Database | Local SQLite or PostgreSQL | No local database |
Provider credentials | Configured locally | Managed by Otari |
Authentication | Local API keys and master key | Bearer tokens from Otari |
Budgets and usage | Managed and stored locally | Reported back to Otari |
Available API routes | Full gateway API surface | Health endpoints plus chat completions |
Multi-provider fallback | Not built in | Handled by Otari |
Connected mode at a glance
Connected mode is intentionally narrower. The gateway stays in your infrastructure, but otari.ai takes over the control-plane work.
What changes
No local database is used.
The
providersblock inconfig.ymlshould be empty or omitted.The gateway exposes only health endpoints and
/v1/chat/completions.Requests use
Authorization: Bearer <otari-user-token>.The
/healthendpoint reports whether the platform is reachable.
How the gateway uses otari.ai
When connected, the gateway calls Otari to resolve providers, report usage, and resolve MCP servers. This page is the high-level view. For the wire-level contract, use Platform protocol.