Mullgate
Architecture

Current Runtime Model

Summary of the shared-entry multi-exit runtime that Mullgate ships today.

The current Mullgate runtime is a shared-entry multi-exit model.

Core characteristics

The shipped design includes:

  • canonical routed config in routing.locations[]
  • one shared Mullvad-provisioned WireGuard entry device
  • one shared entry tunnel inside the runtime
  • one logical Mullvad SOCKS5 exit selection per configured route
  • routing by destination bind IP so hostname-selected behavior stays truthful across SOCKS5, HTTP, and HTTPS
  • a Docker-first runtime bundle that wires together entry-tunnel, route-proxy, and routing-layer

Why this model is coherent

This design keeps route identity explicit while avoiding the old route-per-key scaling problem:

  • each route still maps to its own local entrypoint
  • each route still maps to its own exact Mullvad exit
  • one real Mullvad device powers many routes
  • status, doctor, runtime manifests, and validation reports can describe the topology directly

Scaling result

Fresh setup now consumes one Mullvad WireGuard device slot total for the shared entry path, not one slot per route.

That means route count is driven by:

  • bind-IP planning
  • runtime capacity
  • upstream relay behavior

not by one Mullvad WireGuard key per route.

Practical consequence

Mullgate can expose many concurrent country-specific local proxies from one Mullvad account without taking over the host's default routing.

See also

On this page