Windscribe Desktop App: a GPL-2.0 VPN client you can build yourself

A mirror of the client, not the service

The Windscribe Desktop App repository is described as a public mirror of the Windscribe VPN desktop client for Windows, Mac and Linux. The primary language is C++, the licence is GPL-2.0, and the homepage is windscribe.com. The last push was on 2026-10-13, with release tags v2.25.2, v2.25.3 and v2.25.4, all marked as alpha builds.

The word mirror is worth pausing on. The client is not a VPN service, and nothing in this repository gives you a tunnel. What it gives you is the software that talks to Windscribe's servers, which matters for a specific set of readers: developers who want to build and patch the client, and users whose platform needs a build the packaged installers do not cover.

The feature list is what the client does once it is talking to the service. It offers six protocols, along with more than 20 different connection ports. The protocols are WireGuard, which the README notes now has post-quantum encryption, OpenVPN over UDP and TCP, IKEv2, Stealth and WSTunnel.

Two features are unusual enough to be worth calling out. The first is the ability to create a secure HTTP or SOCKS5 proxy server on your own computer, so any device on your network can make requests over the VPN tunnel. The second is MAC address spoofing, which makes the machine appear as a brand new user on every connection.

There is also a proactive firewall that the README says eliminates the chance of any kind of leak, network and per-app split tunnelling, network rules that connect or disconnect automatically, custom config support for importing any VPN config, and content filtering through R.O.B.E.R.T., the integrated DNS-based blocker covering ads, trackers, malware and custom domains. Custom DNS is supported, including the ctrld project as a sister product, and there is CLI support on all platforms, including a pure CLI environment for Linux.

The OS support matrix

The supported platforms are listed precisely, which is what you want from a client that has to deal with a Windows service, a tunnel driver and a firewall on each platform.

On Windows, Windows 10 and 11 on amd64 with a minimum build of 17763, Windows 11 on arm64, and Windows Server 2022 on amd64. On macOS, version 13 or newer, on both amd64 and arm64. On Linux, Ubuntu 22.04 or newer and Fedora 36 or newer on both amd64 and arm64, plus openSUSE Leap 15.6 and Arch with a minimum glibc version of 2.35 on amd64. The list also names immutable distributions, giving Fedora Silverblue 40 and openSUSE Aeon and MicroOS as examples, which tells you the AppImage and Flatpak style packaging is treated as a first-class target rather than an afterthought.

The subscription model is stated in the feature list: there are no per-device or simultaneous connection restrictions, and one account can be used across all your personal systems.

For a reader deciding whether the client is usable, the matrix is the thing to check, since the answer depends on your distribution and your architecture rather than on anything more subtle.

Building on Windows, and the signature check you cannot skip

The Windows build process is the more thoroughly documented of the two in the README, and the prerequisite list is long. You need Windows 10 or 11 on x86_64, with the note that building on WoA arm64 is not currently supported. Then Git, Visual Studio Community Edition 2022, Python 3 with a minimum tested version of 3.6.8, CMake v3.28.x or newer, Ninja v1.10.2, and the Windows 11 SDK at 10.0.22000.

The vcpkg setup is a separate step, because the project keeps its own registry:

git clone https://github.com/Windscribe/ws-vcpkg-registry.git
ws-vcpkg-registry\install-vcpkg\vcpkg_install.bat C:\path\to\vcpkg

After that you set `VCPKG_ROOT` to the path you chose, and verify that `C:\Program Files\Git\cmd`, the folder containing ninja.exe and the folder containing cmake.exe are in the System PATH, and that `python3` is available there too. The README is specific about the Windows Store case, telling you to enable the python3.exe execution alias in the App Execution Aliases settings, or to symlink python3.exe to python.exe if you installed from python.org.

The build script dependencies come next, and the pyyaml build issue on Windows has a documented workaround:

pip install setuptools wheel
pip install "cython<3.0.0" && pip install --no-build-isolation pyyaml==6.0

The dependency libraries are built with three scripts run in order from the `tools/deps` subfolder, `install_openvpn_dco`, `install_wintun` and `install_wstunnel`, with the note that appending `--arm64` builds for Windows arm64. The wstunnel step needs Go at a minimum version of 1.23 and an llvm-mingw msvcrt x86_64 package, with `LLVM_MINGW_ROOT` set to the extracted folder.

Then the app itself, from the `tools` subfolder, with `build_all --dev-mode`, and the installer lands in `build-exe`.

The `--dev-mode` flag is the detail that catches people. It disables run-time signature verification and relaxes the security checks, which is what you want for local development and debugging. Omitting it produces a build that performs run-time signature verification on its executables, and that build must be code-signed with `--sign-app` and `--sign-installer` or `--sign-bootstrap` as needed, otherwise it rejects its own unsigned executables at run time. The signing certificate step is optional and documented separately, with the PFX file going to `installer/windows/signing/code_signing.pfx`, a `windows-signing-cert-password` line added to `tools/notarize.yml`, and the `WINDOWS_CERT_SUBJECT_NAME` entry in `client/common/utils/executable_signature/executable_signature_defs.h` set to match the certificate's name of signer field.

Where the logs live

The README lists the log paths for each component, which is the kind of detail that saves an afternoon.

The client app, the location pings and the installer helper all log to `C:/Users/<user_name>/AppData/Local/Windscribe/Windscribe2`. The service logs to `<Windscribe_installation_path>/windscribeservice.log`, and the installation path defaults to `C:/Program Files/Windscribe`.

The installer writes to `C:/ProgramData/Windscribe/installer.log`, with the previous attempt kept as `installer.log.1`. The uninstaller writes to `C:/ProgramData/Windscribe/uninstaller.log`, with the previous run at `uninstaller.log.1`.

The rotation convention is worth noting: the previous file is kept rather than deleted, so when you are diagnosing a failed install you have both the current attempt and the one before it to compare.

A Linux build environment in one Dockerfile

The repository's Dockerfile is a Linux build environment, and it is a good way to see the full dependency surface of the client in one place.

It starts from `ubuntu:22.04`, copies the tools requirements file in, and installs a long list of build dependencies with apt, including build-essential, cmake, git, patchelf, libpam0g-dev, libgl1-mesa-dev, fakeroot, libnl-genl-3-dev, pkg-config, libcap-ng-dev, libacl1-dev, libnftables-dev, autoconf, libtool, and the X11 and Wayland development packages that a GUI client needs.

Two things are fetched and verified by checksum rather than by version manager. Go is downloaded as a tarball, and the SHA-256 is checked before it is extracted into `/usr/local/go` with a symlink into `/usr/local/bin`. The same pattern is used for CMake, downloaded as the 3.29.6 linux-x86_64 installer, checksummed, and installed to `/opt/cmake`.

The `ENV PATH=/opt/cmake/bin:$PATH` and the later symlink into `/usr/bin/cmake` are there because the base image's CMake is not the version the project wants.

The `.github/` and `.gitlab-ci.yml` directories in the tree show the project builds on both CI systems, and the `skills/` directory is a recent addition worth knowing about if you are contributing, since it suggests a set of task-oriented instructions for coding agents working in the repository.

Editorial conclusion

Windscribe Desktop App suits a developer who wants to build and modify the client themselves, or who needs features the packaged builds do not expose, such as the local proxy server for other devices on the network. It does not suit someone who wants a VPN without a Windscribe subscription, since the client is a front end for that service. Before building, note that the non-dev-mode build enforces run-time signature verification on its own executables, so a local build needs the `--dev-mode` flag, and read the log paths listed in the README before you start debugging.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. Windscribe/Desktop-App on GitHub