tygress
Join the waitlist

Enterprise API gateway

Self-hosted enterprise API gateway in Rust

Tygress is a self-hosted API gateway written in Rust, on its own async transport. It routes REST, gRPC, and WebSocket traffic with enterprise identity, rate limits, health checks, and failover, proxies TCP, UDP, and TLS passthrough at L4 with the same load balancing and health checks, and applies the same policy chain to LLM, MCP, and AI agent traffic.

Compare Tygress vs KongSee what has been built

Pre-release · in active pre-1.0 development · Updated

Join the early-access waitlist

Beta availability and product updates. Tygress is pre-release: the gateway is built but not publicly available yet.

Just your email. No payment required. Unsubscribe anytime. Privacy

Platform capabilities

The controls an enterprise gateway must own

A reverse proxy moves traffic. An enterprise gateway makes that traffic identifiable, governable, observable, and recoverable across teams and environments.

  • Identity: tokens are verified against your IdP's published keys before the request reaches the upstream.
  • Limits: each user gets a rate limit of their own, keyed on the token's sub claim.
  • Recovery: health checks and outlier ejection steer traffic to healthy nodes, and retries stay inside a deadline and a budget.
tygress.yaml · upstream and route
upstreams:  - name: orders    algorithm: least_request    nodes:      - { address: 10.0.1.10, port: 8080 }      - { address: 10.0.1.11, port: 8080 }    health_check: { type: http, path: /health, interval: 5 }    outlier_detection: { consecutive_5xx: 5 }    retry_budget: { budget_percent: 20 }routes:  - name: orders-api    match: { hosts: ["api.example.com"], paths: ["/orders/*"] }    upstream: orders    timeouts: { total_ms: 3000 }    retry_policy: { attempts: 3, retry_on: [connect-failure] }    plugins:      - name: jwt        config:          jwks_uri: https://idp.example.com/.well-known/jwks.json          iss: https://idp.example.com          aud: [orders-api]          claims_to_vars: [{ claim: sub, var: user }]      - name: rate_limit        config: { rate: 50, burst: 100, key: "$var_user" }
Failed connections retry with a fresh node pick, inside a 3 s total deadline and a 20% retry budget.

Identity at the edge

Attach OIDC, JWT with remote JWKS, JWE, LDAP and Active Directory, mTLS, OAuth2 introspection, HMAC, basic auth, API keys, and forward-auth per route, with multi-auth to accept any of several. Verified credentials map to consumers; groups drive ACLs and OPA handles external authorization.

Routing on anything in the request

A trie-based router matches host, SNI, path, method, headers, query parameters, cookies, and gRPC service or method, with exact, regex, prefix, and exists operators that can each be negated. Weighted splits handle canaries, and shadow mirroring copies sampled requests to a mirror upstream.

Load balancing and discovery

Round-robin, weighted, least-request, and consistent hashing, plus cookie sticky sessions. Upstream targets come from static lists, DNS A/AAAA or SRV records, or, in an opt-in build, Kubernetes EndpointSlices.

Rate limits and resilience

Token-bucket and fixed-window rate limits keyed per client IP, consumer, route, header, or verified IdP claim, shared across replicas through Redis. Active and passive health checks, outlier ejection, retry budgets, circuit breakers, concurrency limits, and fault injection.

Protocols and TLS

HTTP/1.1, HTTP/2, gRPC, gRPC-Web, gRPC-JSON transcoding, and WebSocket, plus L4 TCP, UDP, and TLS passthrough. TLS termination with SNI and mTLS, ACME certificates, and hybrid post-quantum key exchange offered by default.

Observability

Prometheus metrics, OpenTelemetry traces, and access logs to HTTP, TCP, UDP, syslog, file, Splunk HEC, Loki, Elasticsearch, or, in an opt-in build, Kafka. With PostgreSQL, a control plane keeps append-only records of applied configuration revisions.

No enterprise-only features

Identity, high availability, and AI governance are not upsells. Planned pricing puts every gateway capability in the $0 tier, with an open-source core planned at launch; paid plans are managed hosting, support, and services.

See planned pricing

Engine

Why a Rust API gateway

A gateway parses untrusted input from every client, holds credentials, and sits in the path of every request. Rust suits that job. It is no longer rare among gateways, though, and the language alone is not a reason to choose one; what Tygress does with it is.

Memory safety in the transport

Safe Rust rules out use-after-free, double frees, and data races at compile time, and the transport crate forbids unsafe code outright. HTTP framing comes from hyper and h2, and TLS from rustls on the aws-lc-rs crypto backend.

No garbage-collector pauses

Rust has no garbage collector, so no request waits on a collection cycle; memory is freed deterministically when its owner goes out of scope. Requests run as async tasks on a multi-threaded runtime whose worker count you can set.

Its own transport

Since September 2026, Tygress runs on tygress-proxy, an async transport written for this gateway, and its own request engine. The transport owns the accept loop, connection lifecycle, upstream connection pooling, drain, and listener handoff.

What owning the transport changes

These come from owning the accept loop, the connection lifecycle, and the request engine, not from the choice of language.

No benchmarks are published for this engine yet. They will be published with their methodology; until then, early-access users should measure it with their own policies enabled.

Read the transport changelog entry

  • Upgrades without closing listeners: a new binary inherits the listening sockets of the running one.
  • One transport for HTTP, L4 TCP and UDP, gRPC-Web, WebSocket, and CONNECT traffic, so drain and upgrade cover all of them.
  • Per-attempt signing: provider translation and request signing, such as AWS SigV4, run inside each retry and failover attempt after every plugin edit, so each attempt is signed over the exact bytes it sends.
  • Guardrails on streams: with reply scanning on, DLP and the prompt guard's leak check inspect every chunk of a streamed reply instead of one buffered body.

Protocol coverage

HTTP, gRPC, WebSocket, L4, and TLS in one gateway

All of these run on Tygress's own transport, alongside the same routing, upstreams, and policy model. The last column lists what each one does not do yet.

Protocols Tygress supports, with current limits
ProtocolWhat Tygress doesLimits today
HTTP/1.1 and HTTP/2Inbound protocol chosen by ALPN per listener, with h2c on plaintext listeners. Upstreams use HTTP/1.1, HTTP/2 over TLS, or h2c.No HTTP/3 or QUIC.
gRPCRouting on service and method, grpc-timeout propagation, gRPC health probes, and retries and outlier ejection driven by gRPC status.A status that arrives in trailers after the body has streamed cannot be retried.
gRPC-WebBrowser gRPC-Web, binary and text, translated to native gRPC and back, including server streaming.Needs an HTTP/2 upstream; response bodies are capped (1 MiB by default).
gRPC-JSON transcodingREST and JSON clients call gRPC backends through a protobuf descriptor set loaded at runtime, with no code generation. Server streams return NDJSON.Each JSON request becomes a single request message, so client streaming is not transcoded.
WebSocketOpt-in per route. Authentication and rate-limit plugins run on the handshake, with idle timeouts and per-route connection caps.HTTP/1.1 Upgrade only; no WebSocket over HTTP/2.
TLS and mTLSTermination with per-SNI certificates, wildcards included, and optional or required client certificates; TLS 1.2 and 1.3; certificates hot-swap through the admin API. Upstream TLS verifies against the system store or a private CA and can present a client certificate.The admin API listener serves plain HTTP and binds to loopback by default.
ACMEIn-process RFC 8555 client, Let's Encrypt by default or any directory URL. HTTP-01, and DNS-01 for wildcard certificates; renewed certificates hot-swap without a restart.DNS-01 publishes records through your own command or webhook; there are no built-in DNS-provider integrations. HTTP-01 needs a plaintext listener on port 80.
L4 TCP, UDP, TLS passthroughTCP and UDP proxying, and TLS passthrough routed by SNI without terminating, using the same load balancing and health checks as HTTP upstreams.No HTTP plugins run on L4 routes, and TLS on L4 is passthrough only, never terminated.
Forward proxy (CONNECT)HTTP CONNECT tunnels on a dedicated listener, with proxy authentication or a client CIDR allowlist, destination allow and deny lists, and private and metadata address ranges denied by default.CONNECT only; plain-HTTP proxy requests return 501.

Plugin catalog

60+ built-in plugins, grouped by job

Plugins attach globally or to a service, route, consumer, consumer group, or team, and run in priority order within each request phase. tygress explain-chainprints the resolved order, and which scope's config wins, without booting the gateway.

Authentication

  • Key auth
  • Basic auth
  • HMAC
  • JWT with remote JWKS
  • JWE decryption
  • OpenID Connect
  • OAuth2 introspection
  • LDAP and Active Directory
  • mTLS
  • Forward auth
  • Multi-auth

Authorization

  • ACL by consumer group
  • OPA

Protection

  • IP restriction
  • User-agent restriction
  • Bot detection
  • CSRF
  • CORS
  • Security headers
  • URI blocker
  • Request size limit
  • JSON and XML threat protection
  • Body schema validation
  • pqc-guard
  • Incident response

Traffic

  • Rate limit (token bucket)
  • Request limit (fixed window)
  • Concurrency limit
  • Circuit breaker
  • Fault injection
  • Response cache with PURGE
  • Compression (gzip, brotli, zstd)
  • Request rewrite
  • Header and JSON body transformer
  • Redirect
  • Request ID
  • JSON-RPC batch fan-out

AI

  • AI DLP
  • Prompt guard
  • Semantic cache
  • Token limit
  • USD cost budget
  • Model allowlist
  • Prompt templates
  • Prompt decorator
  • RAG injector
  • LLM-as-judge
  • MCP guard
  • MCP approval
  • A2A approval

Observability

  • Prometheus
  • OpenTelemetry
  • HTTP logger
  • TCP logger
  • UDP logger
  • Syslog
  • File logger
  • Splunk HEC
  • Loki
  • Elasticsearch
  • Langfuse
  • Usage analytics
  • Kafka (opt-in build)

Scripting (Rhai or JavaScript)

  • Hook before other plugins
  • Hook after other plugins

Extend it

Custom logic runs as sandboxed proxy-wasm plugins, with guests in Rust, TinyGo, and AssemblyScript tested in CI, or as inline Rhai and JavaScript hooks. Some proxy-wasm host calls are not implemented yet.

Traffic spikes and recovery

How an API gateway handles traffic spikes and 503 errors

A 503 Service Unavailable response can indicate temporary overload or maintenance. A gateway can reduce avoidable failures by limiting load and routing to healthy upstreams, but it cannot guarantee availability when every backend is overloaded or down.

  1. Bound the work each service accepts

    Set request and concurrency limits against measured upstream capacity. Reserve capacity for critical traffic and scale backends before their queues saturate.

  2. Detect unhealthy upstreams

    Combine health checks with observed request failures. Remove failing targets from rotation and direct traffic only to healthy capacity.

  3. Keep retries under control

    Use timeouts and a retry budget. Retry only operations that are safe to repeat, respect Retry-After when provided, and use backoff with jitter to avoid another traffic surge.

  4. Test the complete failover path

    Simulate an upstream outage and a gateway-node failure separately. Measure recovery with your authentication, plugins, payloads, and real traffic mix enabled.

How Tygress protects upstreams

  • Health checks: active probes over HTTP, TCP and gRPC, plus passive checks and outlier ejection, take failing targets out of rotation.
  • Bounded retries: per-route retry policies with backoff and jitter run inside a total deadline, and a retry budget per upstream caps concurrent retries so they cannot turn into a retry storm.
  • Circuit breakers and bulkheads: a circuit breaker stops sending traffic to a failing upstream, and a per-upstream concurrency cap sheds excess requests with a 503.
  • Shared rate limits: token-bucket and fixed-window limits can share their counters across replicas through Redis.

How Tygress keeps its own nodes available

  • Zero-downtime upgrades: a new binary started with tygress --upgrade inherits every listening socket from the running one over a Unix socket, so the port is never unbound. If the new process never confirms, the old one keeps serving.
  • Graceful drain: on SIGTERM, /healthz returns 503 while the listeners keep accepting, so load balancers deregister the node before in-flight requests drain.
  • Last-known-good configuration: data planes keep serving their current config if NATS becomes unreachable, persist a snapshot to disk for restarts, and reconnect in the background.

Validate these controls against your own availability requirements during early access.

Technical references: HTTP 503 semantics and AWS guidance on timeouts and retries.

Operations

Validate, deploy, and run it like infrastructure code

Configuration is declarative and checkable before it goes live, and the same binary covers a single node or a fleet of data planes.

Validate before you apply
tygress validatechecks a config file offline and exits non-zero on error, so CI can gate on it. The admin API's dry-run (POST /admin/validate, or ?dry_run=1 on a change) runs the same pipeline a real apply uses.
Declarative config, live changes
One YAML file, which also accepts JSON, with environment-variable expansion; a missing variable is a load error, not an empty string. The admin REST API applies live changes, and each change swaps in atomically, so in-flight requests finish on the configuration they started with.
Control plane and data planes
One binary runs all-in-one or in separate control-plane and data-plane roles. Configuration travels over a NATS JetStream bus as versioned snapshots, data planes run without an admin port, and Redis shares counters and state across replicas. Without NATS, admin API changes last until the next restart.
Kubernetes EndpointSlice discovery
In an opt-in build, an upstream follows a Kubernetes Service's ready endpoints by watching its EndpointSlices instead of waiting for the next DNS refresh. If the API server becomes unreachable, the last known endpoints keep serving. It is not in the default image.
Container image and reference stack
The source includes a Dockerfile for a distroless, non-root image that serves every role, and a Docker Compose stack with NATS, a control plane, and two data planes. No image is published yet. tygress healthcheck works as a container probe.
Optional dependencies
A minimal deployment is one binary and a config file. PostgreSQL is optional and never the config store: it keeps config-revision and approval records, usage, budgets, and AI data. NATS and Redis are added only for the topologies that need them.

Post-quantum TLS

Post-quantum key exchange, offered by default and enforceable

The TLS stack, rustls on aws-lc-rs, offers the hybrid X25519MLKEM768 group first on listeners and on upstream connections: ML-KEM-768 (NIST FIPS 203) combined with X25519. Peers that support it negotiate it with no configuration, and classical-only peers fall back to classical key exchange.

Key exchange only: certificates and signatures stay classical. That mitigates harvest-now-decrypt-later for post-quantum-capable peers. This is not unique to Tygress: Kong announced hybrid ML-KEM key exchange and ML-DSA certificates for its non-FIPS builds in September 2026. See how Tygress and Kong compare.

  • A pqc_policy per listener and per upstream: observe, the default, leaves negotiation unchanged; prefer pins the hybrid group first with a classical fallback; require accepts only the hybrid group, on TLS 1.3.
  • The pqc-guard plugin enforces post-quantum handshakes per route or consumer, so sensitive routes can require them while other routes still accept classical clients.
  • Metrics and access logs: setting any pqc_policy on a listener, observe included, records the negotiated group.
  • A crypto-posture report from the admin API lists configured certificates, key-exchange policies, and token algorithms, mapped to PQC-migration deadlines and PCI DSS 4.0.1 Req 12.3.3.

AI traffic

Models and agents go through the same gateway

The same binary is an AI gateway. Clients reach nine LLM provider types through the Chat Completions, Responses, and Messages APIs, bridged where a provider lacks one; a bridge refuses features it cannot carry instead of dropping them. It also handles provider failover, virtual keys, USD budgets for consumers and teams, DLP and prompt guards that can scan streamed replies, semantic caching, MCP tool gating, and A2A routing.

Explore the enterprise AI gateway

Current limits

Not yet supported

Tygress is pre-1.0. These are the gaps an API gateway evaluation is most likely to hit. The configuration schema and admin API may change before 1.0.

  • A published container image, Helm chart, or Kubernetes manifests. The image builds from source, with a Docker Compose reference stack.
  • Kubernetes discovery, the operator console, Kafka logging, and the local semantic-cache embedder in the default build. All four are opt-in builds.
  • HTTP/3 and QUIC.
  • WebSocket over HTTP/2. WebSocket uses HTTP/1.1 Upgrade.
  • SAML authentication.
  • PROXY protocol on listeners.
  • Native Consul or etcd discovery clients. DNS SRV, with a custom nameserver, covers Consul DNS.
  • Some proxy-wasm host calls: HTTP callouts, shared data and queues, and timers.
  • Post-quantum certificates and signatures. Post-quantum support covers key exchange only.
  • Windows. Tygress runs on Linux and macOS, and zero-downtime upgrades need Unix sockets.
  • Published benchmarks. They will be published with their methodology.

Changelog

Recent changes

See all 40 dated updates since June 2026

Platform evaluation

Choosing an enterprise API gateway platform

Evaluate the gateway with your workload and operating requirements. A proxy-only benchmark does not establish performance with authentication, logging, and security policies enabled.

Identity and isolation
Exercise your actual OIDC, LDAP, mTLS, or API-key flow. Confirm that one team's consumers cannot reach another team's routes or exhaust its quota.
Failure recovery
Remove an upstream during a load test. Measure failed requests, recovery time, and tail latency, and how data planes behave when the control plane is unreachable.
Change safety
Check whether a configuration change can be validated in CI and dry-run against the running gateway before it applies, and how a bad change is rolled back.
Upgrades under load
Upgrade a node while it serves traffic. Check whether listeners stay open, whether load balancers deregister the node before connections close, and how long draining takes.
Operational cost
Include gateway instances, databases, telemetry, required plugins, support, and the work of upgrading and recovering the deployment.
What needs a paid edition
Check which identity, high-availability, and governance features sit behind a paid tier. For Tygress, an open-source core is planned at launch, and planned pricing puts every gateway capability in the $0 tier.

FAQ

Enterprise API gateway questions

Related guide: AI gateway vs API gateway

What is an enterprise API gateway?

An enterprise API gateway is the policy and traffic control point in front of an organization's APIs. Beyond reverse proxying, it verifies identity, enforces authorization and rate limits, routes around failing upstreams, translates protocols such as gRPC and REST, and records metrics and traces for every route, across many teams and environments. Tygress is a self-hosted enterprise API gateway that applies the same policy chain to LLM, MCP, and AI agent traffic.

Can an API gateway prevent every 503 error?

No. Rate limits, health checks, circuit breakers, and failover can reduce avoidable failures, but healthy upstream capacity is still required. Test overload, retries, and upstream outages with your actual workload; no gateway can guarantee that an unavailable backend will serve a request.

Can Tygress replace Kong or Apigee?

Tygress is built for the same API gateway role: REST, gRPC, WebSocket, and L4 traffic, enterprise authentication, rate limiting, health checks, failover, 60+ built-in plugins, and observability, with an AI gateway in the same binary. Kong and Apigee are generally available today. Tygress is pre-release, with no published container image or Helm chart yet, so plan any migration around the release and your own validation.

Does Tygress run on-premises or air-gapped?

Tygress is self-hosted by design. A minimal deployment is one binary with a YAML config; NATS, PostgreSQL, and Redis are added only for the topologies or features that need them, such as split control and data planes, durable usage records, or counters shared across replicas. It is designed to run in a private VPC or on-premises. Fully air-gapped operation also needs your identity provider, certificate authority, and other dependencies inside the boundary.

Which API protocols does Tygress support?

HTTP/1.1 and HTTP/2, negotiated by ALPN, with h2c on plaintext listeners; gRPC, gRPC-Web, and gRPC-JSON transcoding from a descriptor set loaded at runtime; and WebSocket over HTTP/1.1 Upgrade. TLS termination covers SNI, mTLS, and ACME certificates. L4 routes proxy TCP, UDP, and TLS passthrough by SNI, and a forward-proxy listener handles HTTP CONNECT. HTTP/3 and WebSocket over HTTP/2 are not supported yet. The same route and plugin model also governs LLM, MCP, and A2A traffic.

How do I add custom logic to Tygress?

Start with the 60+ built-in plugins. For custom logic, Tygress runs sandboxed proxy-wasm modules, with guests written in Rust, TinyGo, and AssemblyScript tested in CI, and inline Rhai or JavaScript hooks configured in YAML. Each request gets its own proxy-wasm guest instance, plugin configuration is checked against the plugin's schema at load, and changed modules recompile on an admin reload without a restart. Some proxy-wasm host calls, such as HTTP callouts, shared data, queues, and timers, are not implemented yet.

Does Tygress run on Kubernetes?

Not with packaged manifests yet. Tygress builds as a distroless container image, but there is no Helm chart, Kubernetes manifest, or operator, and no image is published. An opt-in build watches EndpointSlices so an upstream follows a Service's ready pods, and keeps the last known endpoints if the API server becomes unreachable. The tygress healthcheck command works as a probe in the distroless image, and the SIGTERM drain lets load balancers deregister a pod before its connections close.

Early access

Evaluate Tygress during early access

Join the waitlist for beta availability and build updates. No payment required.

Just your email. Unsubscribe anytime. Privacy