Production Readiness

The short version is simple: the architecture is in decent shape, the feature surface is substantial, and the remaining work is mostly proof and hardening.

The current honest claim is narrower than “all backends are production-ready”:

• native macOS VZ/vfkit is the current production path
• Firecracker on macOS via Lima is the current development and pre-release path
• final Firecracker production parity still needs native Linux /dev/kvm evidence

What is already strong

• control-plane / dataplane separation
• real backend runtime paths
• guest gateway services
• forwarding and tunnel surfaces
• payload-inclusive byte audit for packet transports, the local API socket, and tunnel relay sockets
• plugin-aware byte processing
• parser hardening and fuzz-target scaffolding
• native macOS VZ/vfkit traffic and soak evidence
• local daemon-path benchmarks for control plane, forwarding, and /tunnel

What still blocks full backend parity

• native Linux Firecracker guest-real traffic proof
• native Linux Firecracker guest-real cutover-under-traffic proof
• longer-running guest-real soak evidence
• native-host throughput and cutover timing evidence
• vsock
• Windows runtime completion

Firecracker development rule

If you are developing on macOS today:

• use Lima for Firecracker work
• keep native macOS VZ/vfkit as the production-ready host path
• add a real Linux /dev/kvm host later when you are collecting final Firecracker release artifacts

Where the active plan lives

The detailed checklist is maintained in the repository:

• specs/plans/002-production-network-parity.md
• specs/parity/network-proxy-compatibility-matrix.md
• specs/SPRINT.md

This page is intentionally the readable summary, not the exhaustive tracker.