The Guardway gateway is a single container that runs inside your network and speaks an OpenAI-compatible API. Your applications send requests to the gateway; the gateway applies guardrails, picks a provider, forwards the request, and returns the response. The dashboard at app.guardway.ai configures and observes gateways but never proxies inference traffic. Prompts and completions stay on the gateway; only aggregate telemetry and administrative audit events are recorded centrally on the platform.Documentation Index
Fetch the complete documentation index at: https://docs.guardway.ai/llms.txt
Use this file to discover all available pages before exploring further.
How the pieces fit together
Gateway (your infra)
A hardened container. Runs in your VPC, on-prem, or on a laptop. Speaks the OpenAI API. Fans out to 20+ providers. Keeps prompts and completions on your infra.
Dashboard (SaaS)
Configures providers, routes, guardrails, budgets, and teams. Reads aggregate telemetry from gateways. Never sees raw prompts or completions.
Control plane
Registration tokens, heartbeats, config sync, health signals. HTTPS only. Outbound from the gateway.
Local connection
For playground, logs, and traces the dashboard talks to the gateway directly over your LAN or a URL you expose. Authenticated with a per-session JWT.
What stays local, always
Prompts and completions never leave the gateway. The gateway forwards requests directly to the provider you configured; only aggregate telemetry (token counts, latency, cost) and administrative audit events flow to the cloud dashboard. See Privacy and Security.
Where to go next
Deploy the gateway
Run the container.
Check requirements
CPU, memory, network.
Functionalities
Auth, RBAC, guardrails, compliance.
Environment variables
Full config reference.