Core Concepts

Origins, handler chains, and actions vs policies

Origins

An origin is the fundamental unit of configuration in SBproxy. Each origin maps a hostname to an action. When a request arrives for that hostname, SBproxy runs the action.

origins:
  "api.example.com":
    action:
      type: proxy
      url: https://my-upstream.com

Every origin has exactly one action. The action defines what happens after authentication and policy checks pass. You can attach as many policies, modifiers, and transforms as you need, but there is always one action per origin.

The Handler Chain

Every request passes through a chain of processing layers before reaching the action. The chain has 18 layers internally, but the simplified flow looks like this:

Incoming request
  → Security checks (WAF, DDoS, IP filter)
  → Rate limiting
  → Authentication
  → Request modifiers
  → Action
  → Response modifiers + transforms
  → Client

Each layer can short-circuit the chain. A WAF rule can reject the request before it ever reaches authentication. A rate limiter can return 429 before the action fires. This means you only pay the cost of layers that actually run.

Actions vs Policies

Actions determine where a request goes. Policies determine whether a request is allowed.

  • Actions: proxy, ai_proxy, load_balancer. One per origin.
  • Policies: rate_limiting, waf, ip_filter. Multiple per origin.

One origin always has one action and can have multiple policies stacked on top.

What's Next

  • Platform engineers: Your First Proxy walks you through a working reverse proxy in under 5 minutes.
  • AI platform engineers: Your First AI Gateway sets up an OpenAI-compatible gateway with provider fallback.