Skip to main content
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, completions, and audit logs stay on the gateway.

​
How the pieces fit together

Architecture diagram

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 audit logs local.

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

Audit logs are local-only. They describe actions on a specific gateway instance and are never routed through the cloud pipeline. Filter and export them from Monitoring → Audit logs while connected to the gateway.

​
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.