Hi everyone,
I’m working on an experimental Go infrastructure project called Dun.
Dun explores how far a small Go-native HTTP data plane can go when application-specific behavior runs behind a capability-scoped WebAssembly boundary.
The basic architecture is:
client
↓
Go router / HTTP data plane
↓
request extension pipeline
↓
upstream service
The trusted core handles routing, reverse proxying, configuration and lifecycle.
Application-specific extensions run in WebAssembly through wazero. The runtime currently provides explicit capabilities, execution timeouts, memory limits, failure classification and isolated Wasm instances per request.
The prototype currently supports:
-
exact, prefix, host and method-based routing
-
HTTP/HTTPS reverse proxying
-
ordered per-route Wasm extensions
-
capability-gated host imports
-
fresh Wasm instances per request
-
memory and execution limits
-
atomic extension reloads
-
optional SHA-256 artifact pinning
-
health/readiness endpoints
-
Prometheus-compatible metrics
-
initial TinyGo and Rust SDK support
The project is still pre-1.0, and I’m particularly interested in the architecture and extension model, rather than simply adding features.
Repository:
Documentation:
I’d like to hear from people who have experience with Go HTTP servers, reverse proxies, plugin systems, Wasm runtimes, or infrastructure software.
A question I’m currently thinking about:
Is WebAssembly a sensible extension boundary for a small Go-native data plane, or would you choose a different plugin model?
What are the main architectural problems or limitations you see with this approach?