Fourteen engines address a network-specific failure
MLMVPN is built for a situation where a working tunnel today may be useless on another provider tomorrow. Its Windows interface controls fourteen engines, including Xray, sing-box, Tor, Psiphon, OpenVPN, Lantern, Geph, WARP, and WireGuard-based paths. A clean-IP scanner tests CDN addresses before handing one to a configuration. The app can also manage Workers, KV, and D1 in the user's own Cloudflare account. There is no MLMVPN relay in the traffic path.
That breadth is the reason to consider it, and also the reason to be careful. Our checkout contained 670 files and roughly 159,401 lines of source before dependencies. This is an Electron control plane over many separate executables, network settings, and accounts. It changes DNS, routes, the Windows firewall, and the system proxy with administrator rights. A mistake can affect the whole machine, so the project's recovery journal and kill-switch behavior matter more than its polished desktop.
The source tree omits the binaries that make it useful
Running from source requires more than npm install. The repository deliberately excludes core/, which the build guide describes as roughly 450 MB of third-party software. You must obtain Xray, sing-box, Wintun, Psiphon, Tor, OpenVPN, Lantern, Geph, Tailscale, and other files from their upstream projects, then place each at the exact documented path. The test log made that boundary visible when checks could not find core/tailscale/wintun.dll or xray.exe.
The omission is defensible for licensing and supply-chain reasons, but it shifts verification to you. MLMVPN's own source uses its attribution license, while every bundled engine keeps its separate license. The project says its license is source-available rather than OSI-approved. If you redistribute a derivative, MLMVPN credit must remain in the product, source, and public listing. Teams accustomed to permissive MIT or Apache terms should settle that requirement before writing code.
What happened when we ran it
Our fresh Debian sandbox installed 431 npm packages in 31 seconds, leaving 458 MB on disk. The build then failed after 4 seconds. Electron Builder reached cpu-features, called Electron Rebuild, and node-gyp stopped with a direct message: it does not support cross-compiling native modules from source. That result describes commit 2fa1690 in our unprivileged 3-CPU, 8 GB container. It does not show whether the documented Windows build succeeds.
The test command exited 1 after 2 seconds. One group reported 122 of 147 checks passing and could not find wintun.dll. Another reported 19 of 20 passing because the binary version read back as null instead of 26.7.28. A later group stopped because xray.exe was absent, while several other groups shown in the log passed all their checks. Those are missing-artifact findings; the log does not prove defects in the corresponding engines.
Npm audit found 25 known vulnerabilities in the installed dependency tree: 1 critical, 20 high, 3 moderate, and 1 low. The repository has one CI workflow and a tests directory, but no Dockerfile. A Windows desktop VPN does not need a Docker runtime. Still, the audit result deserves resolution before a developer signs and distributes an installer that runs elevated and controls network traffic.
Windows release users avoid the assembly work
The release page supplies x64 and 32-bit installers plus portable builds for Windows 10 and 11. Version 1.2.4 was published on September 22, 2026 after version 1.2.3 could close during connection and six engines looked for binaries inside app.asar instead of the unpacked directory. The release also added a PowerShell reporting tool that reads startup state without depending on the Electron application, which is useful when the window never appears.
Recent issue activity shows why release choice matters. An open report from September 23 describes version 1.2.4 not opening on Windows 10, though it includes no startup log. Another report filed September 26 concerns version 1.2.3 on Windows 11. Those reports do not establish one shared fault, but they do rule out treating a successful installer download as proof that the app will start on every supported machine. The security policy supports only the latest release.
Recovery design is unusually explicit
The security guide names the failures a VPN client must prevent: traffic or DNS leakage, a silent fail-open state, and Windows left without a working network. Machine-wide changes are recorded before they happen so the next launch can restore stale state after a crash or power cut. Logs stay under the user's profile and are not uploaded automatically. The update path verifies Ed25519 signatures, with the private key kept outside the repository.
Those design choices are reassuring, but our 25-advisory audit keeps this from being an easy recommendation to builders. For an end user facing active censorship, the fourteen-engine fallback and clean-IP scanner may justify trying the signed release on a spare or recoverable Windows machine. For a team adopting the code, first reproduce a native Windows build, populate every core/ artifact from its named source, clear the dependency findings, and test that DNS and firewall state return cleanly after forced termination.