Workstation WSL Proxy: API Gateway, CDN & Agent Edge

Workstation WSL Proxy (also called WSLProxy) is Workstation’s complete API gateway and CDN edge control plane: live routing, WAF, cache, multi-POP DNS, and MCP for operators and AI agents. This technical brief expands the open product at wslproxy.org and the source at github.com/bwalia/wslproxy. Companion: blog · product: /wsl-proxy.

1. Positioning

Mature organisations already run reverse proxies. What they lack is an edge that is operable like a product: JSON/MCP-driven rules, multi-POP awareness, CDN-style cache, WAF with events, and a control plane agents can call. Workstation WSL Proxy is that product — open source, deployable on Docker, Ansible, or Kubernetes/k3s Helm, and branded for Workstation customer conversations as Workstation WSL Proxy.

2. Capabilities (today)

Area	What you get
Routing	Path / IP / country / JWT / S3 / cookie match → proxy (305), redirect, HTML, CAPTCHA; priority + specificity
Traffic	Weighted / RR / header canary / cookie sticky / least-conn; promote & rollback
WAF	Policy packs, anomaly scoring, monitor/block, events API
SSL	auto-ssl / Let’s Encrypt, per-domain SSL JSON, force HTTPS
CDN / cache	Edge static cache, optional Docker blob cache, Varnish hooks
POPs + DNS	Edge locations; Cloudflare A-record provisioning with guardrails
Control plane	React Admin, Next.js dashboard, Swagger, MCP, CLI
Deploy	Docker Compose, Ansible, Helm ingress-controller (k3s)
Observability	/health /healthz /ready /metrics, traffic stats, AI log hooks

3. Architecture (hot path)

Clients and agents hit a WSLProxy POP. OpenResty runs Lua on the request path (gateway_ack → gateway_resp → balancer). Rules, WAF policies, and traffic splits load from disk or Redis and apply without an nginx reload. Reload only when server-level listen/SSL blocks change.

Clients / Agents
    → Workstation WSL Proxy POP (OpenResty + Lua)
        → match rules (JSON / Redis)
        → WAF · cache · traffic split
        → Origins / k3s / APIs / (future MCP upstreams)
Operators: Admin UI · REST · MCP · wslproxy-cli

4. MCP today vs MCP Gateway roadmap

Two related surfaces — do not confuse them:

1. MCP management server (available): exposes WSLProxy’s own Admin capabilities as MCP tools so Claude/Cursor can configure and inspect the edge.
2. MCP Gateway (in progress): WSLProxy as a governed front door in front of other MCP servers — auth bridging (clients never hold upstream tokens), tool/method allow-deny, audit of tools/call, and per-tool rate limits. Documented in the upstream docs/mcp-gateway.md.

5. Agents Gateway (in progress)

As organisations run multi-agent fleets, they need the same edge policies they already trust for APIs: identity bridging, rate limits, audit, canaries, and POP affinity. Agents Gateway is Workstation’s programme to route and govern agent traffic through Workstation WSL Proxy — alongside MCP Gateway — so agent solutions and API/CDN workloads share one control plane.

6. Deploy options

• Docker Compose — local and lab stacks (docker-compose-*.yml in the repo).
• Ansible — bare metal / VM POP builds.
• Helm — ingress-controller style charts for k3s / Kubernetes.
• CLI: ghcr.io/bwalia/wslproxy-cli:latest for operators and agents.

7. Why Workstation ships it

Workstation builds AI workstations, private AI, and agent platforms. Those products need a serious edge: not a one-off nginx snippet, but a gateway/CDN that ops and agents can both drive. WSLProxy is that shared edge — open at wslproxy.org, integrated into Workstation solutions as Workstation WSL Proxy.

8. Next steps

1. Read the product page: /wsl-proxy.
2. Explore Swagger and star the repo.
3. Talk to Workstation about edge, CDN, Agents Gateway, and MCP Gateway deployments via contact.

Published by Workstation. Upstream docs: README, docs/mcp-gateway.md, WAF and POP guides in the GitHub repository.

Continue on the product site: https://wslproxy.com/