ThrottleProxy
Interactive request lifecycle

Watch one request move through every protection boundary

Explore the checks between your application and an approved public upstream. Select any stage to see what happens and where the security boundary holds.

Follow the quick startReview technical controls

Lifecycle map

Hover, focus, or select a stage

Request pulse active
Implemented lifecycle boundariesNo secrets displayedKeyboard accessibleReduced-motion aware

How it works

One protected path from your app to every approved upstream

ThrottleProxy authenticates the caller, applies the correct workspace boundary, validates the destination, controls burst pressure, and returns the upstream response with privacy-safe lifecycle context.

Start the guided setupExplore technical features
Exact key lookupWorkspace scopedPrivate targets blockedBounded queues

Request lifecycle

Every stage has a job. Every boundary fails closed.

The flow is deliberately ordered: authenticate first, derive the tenant, validate the destination, then spend network resources.

  1. Ingress

    Request enters ThrottleProxy

    Your application sends an HTTPS proxy request with a ThrottleProxy API key and an explicit upstream destination.

    01

  2. Authentication

    API key is verified

    The presented key is hashed and resolved through one exact Redis lookup. Random invalid keys do not trigger cache scans or database fallback.

    02

  3. Tenant scope

    Workspace boundary is applied

    The key resolves its authorized workspace configuration. Client-supplied object IDs cannot switch the request into another tenant.

    03

  4. Allowlist + SSRF

    Destination safety is checked

    Exact or explicitly wildcarded hosts are checked before routing. Private, local, metadata, reserved, unsafe-port, and self-referential targets are rejected.

    04

  5. Policy

    Rate and resource policy runs

    Redis-backed limits evaluate request pace, concurrency, and queue admission. Per-key, workspace, target, and global caps fail fast under pressure.

    05

  6. Queue

    Protected queue decision

    Eligible bursts may wait briefly in a TTL-bound queue. Queue size and wait time are capped so held connections cannot grow without bound.

    06

  7. Upstream

    Request is sent upstream

    ThrottleProxy credentials, cookies, forwarding credentials, and hop-by-hop headers are stripped. The validated DNS result is pinned while TLS still verifies the intended hostname.

    07

  8. Response

    Response returns within limits

    Request and response bytes are counted while streaming. Absolute and idle timeouts stop oversized or long-lived traffic from holding resources indefinitely.

    08

  9. Visibility

    Lifecycle metadata stays useful

    Sanitized lifecycle events preserve stages, timing, status, and correlation context while redacting credentials, query values, email addresses, bodies, and unsafe error details.

    09

Protection by construction

The proxy path is intentionally difficult to abuse

Private networks stay private

Localhost, private and reserved IP ranges, cloud metadata targets, unsafe protocols, and unsafe ports are rejected before outbound traffic.

Credentials stay separated

The API key used to authenticate to ThrottleProxy is never forwarded as an upstream Authorization or x-api-key credential.

Resource use is bounded

Body sizes, response sizes, queue depth, concurrency, idle time, and total upstream duration all have explicit limits.

Deployment path

Start with one workspace and one approved upstream

The dashboard guides key creation and allowlist setup. Provider templates and request timelines are clearly labeled previews while live provider credential storage remains future work.

Start setupView setup guides