Skip to content
Esc
navigateopen⌘Jpreview
On this page

What is Switchboard?

Programmable reverse proxy rules, written in Go, compiled to WebAssembly, and hot-swapped without restarts.

Switchboard lets you change what your reverse proxy does to requests (block, redirect, rewrite, route, tag) without redeploying or restarting the proxy.

You write request rules as plain Go, compile them to WebAssembly with TinyGo, and push them to a registry as immutable, content-addressed bundles. Every proxy instance polls a channel pointer and hot-swaps the active rule in the background. The long-lived dataplane stays stable; the fast-changing request policy lives in small, versioned Wasm guests.

func Handle(req sdk.Request) sdk.Action {
	if req.Path() == "/blocked" {
		return sdk.Deny(403).WithReason("blocked-path")
	}

	return sdk.Next().SetRequestHeader("x-powered-by", "switchboard")
}

Why it exists

Request policy changes constantly: a redirect map today, a canary split tomorrow, an emergency block at 2am. Baking that policy into proxy config means every change is a config reload or a redeploy, and a bad change takes the proxy down with it. Switchboard moves that policy into artifacts with their own lifecycle:

  • Deploys don’t restart the proxy. Bundles are downloaded, verified, compiled, warmed, and tested off the request path, then swapped in atomically. In-flight requests finish on the runtime they started with.
  • Activation is gated by the bundle’s own tests. Each bundle embeds a behavioral test suite, and every proxy re-runs it against the candidate runtime before serving traffic through it. A failing bundle is quarantined while the last known-good version keeps serving.
  • Everything is reversible. Deployments are idempotent, recorded as append-only revisions, and rolled back with one command.
  • A bad rule can’t take the proxy down. Guest execution has hard timeouts and memory caps, and every value a rule emits is validated before it touches a request.

How it fits together

Switchboard architecture
Rules flow from build to registry to a hot-swapped runtime pool.

Three pieces:

  1. The CLI (switchboard) builds rule projects into bundles, tests them, and manages deployments against a registry.
  2. The registry is any S3-compatible object store, a local directory, or a read-only HTTPS origin. It holds immutable bundles, channel pointers, and revision history.
  3. The proxy (a Caddy handler module, the standalone switchboard serve binary, or your own Go server embedding the engine) reconciles toward the channel pointer and executes the active rule on every request via wazero.

Where to start

What Switchboard is not

Switchboard is deliberately narrow. It is not a CDN, cache, or hosted control plane, and rules cannot read bodies, make outbound calls, or keep state. Security & reliability covers why those constraints exist and what they buy.


ethndotsh/switchboardPrototype for programmable and hot-swappable reverse proxy rules via Wasm50

Last updated on July 17, 2026

Was this page helpful?