DwaraAPI gateway
One Rust binary. One YAML file. Every protocol, every policy, every provider -- from a single edge to a fleet.
Single Rust binaryZero-buffer streamingDeclarative YAML
Skip to content
Why dwara
A streaming reverse proxy written in Rust, built for operators who need predictable latency, defense-in-depth traffic policy, and a single declarative config for the edge in front of their APIs.
- Single static binary -- no runtime, no garbage collector, no shared-library dependencies. Ship one file, run it anywhere.
- Streaming by default -- HTTP/1.1, HTTP/2, SSE, and large bodies pass through under frame-based backpressure with zero buffering.
- One declarative YAML -- the routing chain, identity, policy, and observability in a single strict config that validates before it goes live.
- Defense in depth -- rate limiting, circuit breaking, WAF-lite, authn/authz, and secret redaction composed at five scopes with deny-anywhere-wins semantics.
- Open core -- every dataplane capability is in the Apache-2.0 build. Enterprise adds fleet coordination, not paywalled features.
Get started in under a minute
Three commands. Start any HTTP server, run the gateway against the sample config, and send a request through.
dwara -- quickstart
sh
python3 -m http.server 9000
DWARA_CONFIG=crates/dwara-bin/dwara.yaml cargo run -p dwara-bin
curl http://127.0.0.1:8080/v1/The request streams to the backend unbuffered and the response streams back the same way. A path with no matching route returns 404; a dead backend returns 502. Stop with Ctrl-C -- in-flight requests drain before the process exits.
This exact command assumes a source checkout with Rust 1.94+, cmake, and a C compiler. A released binary or Docker image works the same way: point DWARA_CONFIG at your YAML -- Installation covers binaries, Docker images, OS packages, and systemd, no toolchain needed.
New to Dwara? Follow this order:
- Getting started -- a first config, line by line.
- Concepts -- the vocabulary the rest of the docs use: consumers, policy scopes, config generations and snapshots.
- First scenarios -- task-oriented guides for day-one goals.
- OSS quickstart demo -- every OSS capability in one
docker compose up.
By scenario
New to Dwara and not sure where to start? These task-oriented guides walk through the common goals an operator has on day one:
- Protect a public API -- rate limiting, WAF-lite, and JWT authentication in one config: Traffic policy
- Proxy to LLM providers -- one OpenAI-shaped endpoint that translates to OpenAI, Anthropic, or Gemini with token budgets and guardrails: AI gateway.
- Migrate from NGINX, Kong, or Envoy -- import an existing config and diff against a native Dwara config: Config import.
- Run on Kubernetes -- translate Gateway, HTTPRoute, and Ingress resources and run the controller beside your cluster: Kubernetes Gateway API.
- Operate a fleet -- a control plane pushing config generations to edges, shared rate-limit budgets, and workspaces with RBAC: Enterprise and fleet.
For more, see First scenarios.
Built for your team
One gateway, four audiences. Each gets the controls it needs without the noise of the others.
Platform engineers
One declarative YAML for routing, policy, and identity. Validate before publish, hot-reload without restart, and diff configs like Terraform state.
SREs and operations
Retries, circuit breaking, health checks, admission queues, and zero-downtime binary upgrades. Prometheus metrics on every listener and an embedded analytics store.
Security teams
Five authn methods, a deny-anywhere-wins authorization chain, Cedar/OPA policy engines, secret redaction, WAF-lite, and FIPS 140-3 mode.
AI and ML teams
One OpenAI-shaped endpoint in front of every provider. Token budgets, cost attribution, guardrails, semantic caching, and the MCP gateway.
Works with your stack
Keep your existing providers, SDKs, and infrastructure. Dwara speaks every protocol your clients use and translates between them.
| Layer | What it speaks |
|---|---|
| Protocols | HTTP/1.1, HTTP/2, HTTP/3 (QUIC), gRPC, gRPC-Web, WebSocket, L4 TCP/UDP |
| AI providers | OpenAI, Anthropic, Google Gemini, Azure OpenAI, AWS Bedrock, any OpenAI-compatible endpoint |
| Import from | NGINX, Kong, Envoy, OpenAPI specs |
| Run on | Bare metal, Docker, systemd, Kubernetes (Gateway API controller) |
| Observe via | Prometheus /metrics, OTLP traces and metrics, NDJSON analytics firehose, alert webhooks |
| Extend with | Proxy-Wasm (Kong/Envoy filters), native Rust filters, Extism PDK, WASM nano-services |
Explore the capabilities
Everything below ships in the default OSS build unless marked otherwise. Badges match the guides: partial means config-accepted and partially wired, experimental means runtime-stubbed, and enterprise marks fleet-scale features of the enterprise edition.
Streaming proxying HTTP/1.1 + HTTP/2, no buffering, SSE-safeTLS termination Multi-SNI certificates or SNI passthroughRouting and matching Exact, regex, prefix -- fixed precedenceRewrites and redirects Strip/replace/regex, direct responsesLoad balancing and splitting Canary, blue-green, sticky sessionsDynamic discovery DNS A/SRV pools, TTL refreshgRPC proxying Native gRPC over HTTP/2, trailersWebSockets Upgrade handling, managed tunnelsHTTP/3 ingress QUIC listeners with Alt-SvcH3/QUIC upstream Gateway-to-upstream over QUICL4 TCP/UDP proxying partialRaw listeners with SNI routingPost-quantum TLS X25519 + ML-KEM hybrid key exchange
CORS Cross-origin policy with preflightsCompression Response compression at the edgeRequest limits and validation Size caps + JSON Schema bodiesTransforms Header, query, and JSON-body rewritesSecurity headers HSTS, nosniff, CSPResponse field masking Per-consumer redaction, fail-closedResponse caching TTL, SWR, coalescing, tag purgeAPI versioning Path/header/Accept + Deprecation/Sunset
gRPC-Web and transcoding gRPC-Web framing, JSON transcodingProtocol translation REST, gRPC, GraphQL, SOAP/XMLGraphQL awareness partialDepth/complexity limits, persisted queriesAPI aggregation Multi-upstream JSONPath compositionOpenAPI import and mocks Scaffold config; mock routesOpenAPI response validation Validate upstream responses, dry-runAPI lifecycle and dev portal partialCatalog, env profiles, journeys
Timeouts Dial, headers, and body-idle boundsRetries Budgeted attempts, jitter backoffCircuit breaking Fail fast, half-open probesHealth checks Passive + active checks, ejectionRate limiting GCRA and stacked windows, five scopesRequest hedging Speculative duplicates, race-and-cancelAdmission queues Bounded queues, per-priorityConsumer quotas Daily/monthly request budgetsWAF-lite filtering SQLi/XSS/traversal heuristics, dry-runMaintenance and dry-run Per-route 503; policy monitor modeMirroring Shadow traffic to a test upstreamFault injection Aborts and delays for testing
Authentication methods API keys, Basic, JWT, mTLS, HMACHMAC request signing HMAC-SHA256, replay protectionOAuth2 Client-credentials token fetch, cachingmTLS Client certs, upstream mutual TLSOpenID Connect Introspection, PKCE, token exchangeAuthorization rules ACLs, JWT claims, IP, GeoIP; monitor modeCedar authorization In-process Cedar policy engineOPA authorization OPA callout, Rego policiesCEL expressions Sandboxed policy expressionsSecrets Reference resolution, redactionACME certificates experimentalLet's Encrypt over TLS-ALPN-01FIPS 140-3 mode enterpriseaws-lc-rs provider, restricted ciphers
Provider adapters and aliases OpenAI, Anthropic, Gemini, Azure, BedrockRouting policies Cheap-first escalation, cost/latencyToken budgets Token + cost budgets, billing exportsPrompt experimentation Versioning, A/B splits, evalsPrompt logging PII redaction, sampling, retentionGovernance and agents Model allowlists, agent principalsGuardrails Injection, PII, schema rulesSemantic caching Embedding-similarity prompt cacheMCP gateway experimentalHTTP services as MCP toolsA2A protocol partialAgent Card discovery and routing
Structured logs JSON logs with request IDsPrometheus metrics /metrics on every listenerOTLP export Traces + metrics to any collectorSLOs and error budgets SLOs from request outcomesEmbedded analytics Rollups, retention, forecastsAnalytics stream NDJSON firehose to a sinkAlert and event webhooks Breaker/endpoint/config eventsSynthetic monitoring Per-route probes, alertingReplay debugging Record routing, replay offline
Hot config reload File watch/SIGHUP, atomic swapZero-downtime upgrade SO_REUSEPORT hand-off, drainAdmin API mTLS config + credential surfaceWeb console Embedded read-only dashboardCLI validate, fmt, lint, diff, loadgenTerraform state Export, plan, applyConfig import NGINX, Kong, Envoy, OpenAPIKubernetes Gateway API Gateway/HTTPRoute/Ingress controllerAgent-operable admin experimentalMCP tools for AI operators
CP/DP split Controller pushes config to edgesCluster sync Redis convergence, split-brain guardsDistributed rate limiting Shared GCRA buckets in RedisDistributed cache Two-tier cache, fleet invalidationVault secrets HashiCorp Vault source, fail-closedKMS secrets Cloud KMS source, fail-closedWorkspaces Multi-tenant isolationRBAC and audit log Role-based access, audit trailFederated analytics Per-edge analytics, rolled upController persistence PostgreSQL controller stateService mesh experimentalSidecars, SPIFFE/SPIRE identityLicensing Ed25519 license files, grace period
One gateway, from single binary to fleet
The OSS core -- proxying, TLS, routing, resilience, security, observability, analytics -- is complete and production-shaped, and everything in the cards above ships in it. Every dataplane capability (Proxy-Wasm plugins, CEL expressions, Cedar/OPA authorization, aggregation, HTTP/3, protocol translation) is compiled into the default OSS build, and fleet-scale features (CP/DP split, Redis-backed rate limiting and convergence, Vault/KMS secrets, workspaces, FIPS enforcement) make up the enterprise edition. The editions guide has the full comparison matrix.
Open source core
The default build: a complete, production-shaped gateway in a single static binary.
- Proxying, TLS termination, and routing
- Resilience and traffic policy
- Security, observability, and analytics
Complete capability set
Every dataplane capability compiled into the default OSS build.
- Proxy-Wasm plugins and native filters
- CEL expressions and Cedar/OPA authorization
- Aggregation, protocol translation, HTTP/3
Enterprise edition
Fleet-scale operation across many gateway instances.
- CP/DP split and workspaces with RBAC
- Redis-backed rate limiting and convergence
- Vault/KMS secrets and federated analytics
Feature reference
Every dataplane capability is compiled into the default OSS build -- there are no optional packs to enable. The feature reference carries the maturity matrix showing which capabilities are wired end to end and which are still landing, plus build commands and enterprise-only config blocks.
Questions teams ask before they deploy
Dwara is a high-performance, streaming reverse-proxy API gateway written in Rust. It terminates TLS, routes traffic, enforces policy, authenticates callers, and observes everything -- from a single static binary configured by one YAML file.
Every dataplane capability: proxying (HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, L4), TLS termination, routing, load balancing, traffic policy and resilience, security and authentication, AI gateway, plugins and extensibility, observability and analytics, and operations. There are no optional packs to enable.
Features that span multiple gateway instances or require external infrastructure: CP/DP split with a leader-elected control plane, Redis-backed distributed rate limiting and cache, config convergence, workspaces with RBAC and audit, Vault/KMS secrets, federated analytics, FIPS 140-3 enforcement, and service mesh mode.
No. Dwara is a reverse proxy -- point it at your backends and send traffic to it. For AI gateway usage, change only the base URL and credential in your OpenAI-compatible SDK; Dwara translates the request to whichever provider serves it.
Anywhere a single static binary runs: bare metal, Docker, systemd, or Kubernetes. The OSS edition is a standalone binary; the enterprise edition adds a controller and edge binaries for fleet operation. See the deployment guide.
One strict YAML file declares the entire gateway: listeners, routes, services, upstreams, consumers, policies, and observability. The config pipeline (parse, validate, compile, publish) runs on every change -- file watch, SIGHUP, admin API, or controller stream -- and swaps atomically behind an ArcSwap. A failure at any stage never replaces the running snapshot.
Yes. The dwara CLI has an import command that reads NGINX, Kong, or Envoy config and emits a Dwara YAML draft. Use dwara diff to compare it against a hand-tuned config before cutover.
The OSS core (proxying, TLS, routing, resilience, security, observability, analytics) is stable and production-shaped. Some advanced capabilities (L4 proxying, GraphQL awareness, API lifecycle, MCP gateway, service mesh, Extism PDK) are partially wired or experimental; each guide page carries a status note. See the feature reference for the maturity matrix.