Architecture

rvproxy is deliberately split into a few strong boundaries instead of being a single process with networking logic smeared across unrelated modules.

Control plane

The control plane owns:

• local API routes
• runtime readiness and phase reporting
• lease and stats publication
• forward-rule mutation
• drain lifecycle
• notifications

The key code lives in:

• crates/rvproxy-api
• crates/rvproxy-cli

Dataplane

The dataplane owns:

• packet ingress and egress
• gateway services
• guest egress
• forwarding relay
• packet classification and audit
• transport-boundary tracing
• daemon-socket byte tracing for the local API and tunnel relay paths

The central implementation is in:

• crates/rvproxy-transport/src/dataplane/gateway/mod.rs

Backends and transports

Backends are explicit. The project does not try to infer everything from a socket type and let the rest of the runtime guess.

Current backend families:

• qemu
• firecracker
• vfkit
• vz

Current transport shapes:

• framed Unix stream
• Unix datagram

That split is what keeps future work like vsock or Windows named-pipe support from turning into a cross-cutting rewrite.

Plugins

The plugin runtime is in-process, trait-based, and scoped to the byte path. That gives the project room for inspection, mutation, and durable decision export without introducing another daemon hop into the hot path.

The current built-in plugin is an ingress prompt-injection filter, but the important part is the contract:

• explicit attachment/subscription rules
• fail-open / fail-closed behavior
• bounded inspect limits
• bounded async export queueing
• stats and audit visibility