Use case

A VPN built by people who write code

For developers who SSH from coffee shops, hate UAC prompts, and would rather read source than marketing.

Three protocols, picked deliberately

Fexyn ships WireGuard, VLESS Reality (XRay), and OpenVPN. Not an arbitrary three. The choice reflects the trade-off matrix every dev VPN user eventually hits:

Fexyn Bolt (WireGuard) — boringtun (Rust) on Windows, ~5% throughput cost on a clean home connection. Use for everything that's not censored or locked down. Why
Fexyn Stealth (VLESS Reality / XRay) — real TLS 1.3 handshake to a real well-known site, your VPN session is indistinguishable from an HTTPS request. For travel to censored countries. Why
Fexyn Secure (OpenVPN) — TCP/443 fallback for hotel firewalls and conference Wi-Fi that block UDP and unfamiliar signatures. 24-hour certificates from Vault PKI because long-lived OpenVPN certs are a known anti-pattern. Why

The app rotates between them when one is blocked. You don't pick unless you want to.

Architecture that doesn't fight Windows

The Windows client is split:

A user-rights UI you sign in to. Tauri-based, no Electron.
A SYSTEM-level helper service (Rust) that owns the tunnel, routing table, and WFP firewall rules.
Wintun for the TUN interface — signed driver, same one WireGuard's official client uses.
IPC over a local socket between the UI and helper. The UI never asks for admin rights to connect, disconnect, or switch protocol.

The result: no UAC prompts in your dev workflow. Connect, disconnect, switch — no popups interrupting your terminal session.

Kill switch that doesn't break localhost

The most common dev complaint about VPN kill switches: they kill your local dev server too. You start the VPN, your localhost:3000 stops responding because the firewall rule doesn't carve out loopback traffic.

Fexyn's WFP rules explicitly allow loopback (127.0.0.0/8 and ::1). They also allow link-local addresses on the LAN — Docker bridge networks, local Kubernetes setups, and dev tools that bind to 0.0.0.0 keep working. The kill switch blocks traffic that would actually leave your machine outside the tunnel; it doesn't block traffic that's already inside it.

SSH and remote dev workflows

SSH-ing into prod from a hotel? The kill switch is what you want there. If the tunnel drops mid-session, the SSH connection times out cleanly instead of silently re-routing through your real ISP IP. From the bastion's side, your source IP is the Fexyn server's, and a tunnel drop just looks like a network blip.

For VS Code Remote / SSH tunnels / Tailscale-into- corp setups, run them through Fexyn at the system level. Two tunnels stack fine because one is at the network layer and the other is application-layer.

No bloatware

Fexyn doesn't bundle a password manager, an ad blocker, a malware scanner, or a "dark web monitor." It runs a VPN. The installer is ~30 MB. The helper service is a single binary. There's no telemetry beyond the connection counters needed to enforce per-plan device limits.

Exact list of what we keep

On the roadmap

CLI client. For headless connections from a terminal, including from a remote box. Engineering target, not promised by a date.
API access. Programmatic management of credentials, devices, and team membership. Behind a flag for team customers first.
Linux client. In development. Same protocol set, same helper pattern with systemd instead of a Windows service.

Today, available: Windows. Android client built; iOS pending. macOS / Linux / iOS in development.

For the curious: what's in the binary

The desktop client is Tauri (Rust) with a React frontend. The helper service is Rust running as a SYSTEM Windows service. Protocol implementations: boringtun for WireGuard, the official xray-core binary for VLESS Reality, OpenVPN community edition for the OpenVPN path. Wintun for the TUN device. All driver components are signed.

Updates are signed twice (Ed25519 manifest + Authenticode binary), checked before any install step runs. Verification details on /security/download-verification.