IVPN for Desktop: a Go daemon, an Electron interface and a CLI

Three programs, and why the split matters

IVPN for Desktop is the official IVPN app for desktop platforms, and the README describes the project as divided into three parts.

The daemon is the core module of the IVPN software, built mostly using the Go language, and it runs with privileged rights as a system service or daemon. The UI is the graphical user interface, built using Electron. And the CLI is the command line interface.

The split is not a packaging preference, it is a consequence of what the software does. Establishing a tunnel on macOS or Windows means creating a network interface and routing traffic, which needs privileges, and a GUI should not run with those privileges. So the privileged part is a small daemon and the interface talks to it.

That architecture also explains the feature list. The app supports multiple protocols, OpenVPN and WireGuard, and includes a Kill-switch, Multi-Hop, Trusted Networks, AntiTracker, Custom DNS, and dark mode.

Each of those is a feature the daemon has to implement, because each one acts below the application layer. A kill switch has to block traffic when the tunnel is down, which is a firewall rule. AntiTracker has to see the DNS queries. Trusted Networks has to detect that you are on your own network and not route that traffic through the tunnel. Multi-Hop has to chain two servers. None of that belongs in a window.

The app is distributed on the official site at www.ivpn.net, and there is a Snapcraft badge for the Linux package. The licence is GPL-3.0, the default branch is development, and the releases are v3.15.13, v3.15.15 and v3.16.1, the newest one published on 2026-10-08, with the last push to the repository on 2026-10-19.

Security analysis in the continuous integration

The badges at the top of the README are worth reading, because for a VPN client the tooling is part of the product's argument.

There is a CodeQL badge for the codeql-analysis workflow, a gosec badge for the security scan, and a CI badge for the build itself. CodeQL is the analysis engine that queries the code as data, looking for patterns of vulnerable code rather than for the specific mistakes a linter knows about. gosec is the Go-specific scanner that looks for the mistakes that matter in a Go program, such as a subprocess call built from a string or a file path used without validation.

For this codebase the gosec scan has an obvious target. A daemon that runs with privileges, writes firewall rules, manages network interfaces and handles a tunnel configuration is exactly the kind of program where a command injection or a path traversal would be a serious defect, and having a scanner that looks for those in every build is a reasonable baseline.

The three badges are also a statement about what the project expects of itself. This is a client whose whole job is to protect the network, so the security tooling is part of the public face rather than an internal detail.

What the badges do not tell you is whether the third party dependencies are audited, or whether the releases are signed, and the visible text does not cover either. For a project that ships a privileged daemon, those are reasonable questions to ask the maintainers.

The build toolchain, and how heavy it is on each platform

The requirements section is long, and it is a fair measure of what building this client involves.

The common requirements are Go 1.26 or newer, Git, npm, and Node.js 22.12.0.

Windows adds nsis3 for the installer, Visual Studio 2022 with the Windows 10 and Windows 11 SDKs and the MSVC v143 C++ x64 build tools, the C++ ATL for the latest v143 build tools, and a gcc compiler such as MSYS2 MinGW-w64 UCRT. The ATL requirement is the notable one, because ATL is a Windows specific C++ library and it is needed for native components.

The ARM64 story on Windows is spelled out separately. It needs the Visual Studio 2022 ARM64 C++ build tools and the ARM64 version of the ATL components, required for the native DLL, the IVPN Helpers Native, ARM64 build. And it needs the llvm-mingw x86_64-hosted cross-compiler, with the LLVM_MINGW environment variable set to its root folder, for the CGO cross-compilation of the daemon's wifiNotifier targeting ARM64.

That is a lot of machinery, and it exists because the daemon needs a native helper that talks to the operating system's Wi-Fi API, and that helper has to be cross-compiled for a different architecture than the machine doing the build.

macOS is lighter. Go, Git, npm, Node and the Xcode Command Line Tools are the base. Compiling the OpenVPN and OpenSSL binaries locally needs autoconf, automake and libtool from Homebrew, and building liboqs needs cmake, ninja, openssl at 1.1, wget, doxygen, graphviz, astyle and valgrind, plus pytest, pytest-xdist and pyyaml through pip3.

Linux needs gcc, make, FPM for the packages, curl, rpm and libiw-dev, and liboqs adds a longer apt list including ninja-build, libssl-dev, pytest, doxygen, graphviz and valgrind. Cross-compiling for ARM64 on an x86_64 host needs the aarch64 gcc and binutils packages, the arm64 architecture added to dpkg, and the arm64 versions of libssl-dev, liblz4-dev, liblzo2-dev and libpam0g-dev.

Building per platform, and where the artefacts land

The compilation section gives one recipe per platform, and the outputs are different in each case.

On Windows the instructions are to use the Developer PowerShell for VS 2022, which is required for building the native sub-projects, then clone the repository and move into the Windows references directory:

git clone https://github.com/ivpn/desktop-app.git
cd desktop-app/ui/References/Windows

There, build.bat compiles all the binaries with no signing and no installer, and package-release.ps1 builds an unsigned installer. The result appears under ui/References/Windows/bin.

macOS builds a DMG, and the target architecture is a variable:

ARCH_TARGET=arm64 ./build.sh -c <APPLE_DevID_CERTIFICATE>

with an x86_64 variant for Intel. The outputs are named IVPN-X.X.X-arm64.dmg for Apple Silicon machines, the M1, M2 and M3, and IVPN-X.X.X.dmg for Intel. The certificate argument is the Apple Developer ID used for signing, and the README links an issue that has some information about it.

Linux splits the build in two. The base package of the daemon and the CLI is built by the script in the CLI references directory, and the graphical interface by the script in the UI references directory, both natively or with ARCH_TARGET set to arm64 for a cross build. The DEB and RPM packages land in a directory named after the architecture under _out_bin, and there is a note that it is required to have installed the IVPN daemon before running the UI.

That last note is the architecture showing through again: the interface is a separate program that talks to a privileged service, so the order of installation matters.

For Linux there is also a manual installation guide referenced in the repository at docs/readme-build-manual.md, which is where the packaging steps are written down in more detail than the summary gives.

Versioning, and the shape of the repository

The project uses Semantic Versioning for creating release versions, and the README explains the three components: x is the major version, y is the minor and z the patch.

The versioning scheme in the release names is worth reading against the actual numbers. The recent releases are v3.15.13, v3.15.15 and v3.16.1, so the minor number moves when features or behaviour change and the patch number carries the fixes. The gap between v3.15.13 and v3.15.15 also shows that the patch counter does not always advance by one, which is what you would expect from a project that ships fixes as they land rather than batching them.

The repository layout is the three programs and the things around them: the daemon/ directory for the privileged core, the ui/ directory for the Electron interface, the cli/ directory for the command line client, and a snap/ directory for the Linux Snap package. Then docs/, and the project files: the AUTHORS and ACKNOWLEDGEMENTS.md files, the CHANGELOG.md, the CLA.md and the CODE_OF_CONDUCT.md, and the licence in LICENSE.md.

The readme is readme.md rather than README.md, which is a small thing, but it is consistent with a project that has been around long enough to have grown conventions.

One structural detail is worth noting for anybody reading the build instructions: the build scripts live inside the platform directories, under ui/References/Windows, ui/References/macOS and cli/References/Linux, rather than at the top level. Each platform has its own packaging recipe, its own signing story and its own toolchain, and the scripts encode that per platform knowledge in the place where it belongs.

Where IVPN for Desktop is the wrong tool

There are clear cases where this application is not what you want, and the first one is the most important.

This is the client for one provider. The protocols are OpenVPN and WireGuard, which are open, but the account system, the server list, the locations and the subscription are IVPN's, and the features that make the app worth using, the kill switch, AntiTracker, Trusted Networks and multi-hop, are implemented against that service's behaviour. If you want to run a tunnel to a WireGuard server you host yourself, this is the wrong application, and a generic OpenVPN or WireGuard client is the right one.

The second limit is what building it means in practice. You are compiling a privileged system service from source and installing it on your machine. That is a reasonable thing for a developer working on the client, and a poor trade for somebody who simply wants the software, since the signed build on the provider's site is what the released application is for.

The third is the interface technology. The UI is Electron, so it brings a browser engine and a runtime with it, and on a small machine that is more memory than a native client would use. For a VPN client that is usually running in the background, that overhead is the part of the design most worth questioning.

The alternative approach is to run the tunnel yourself with the platform's own tools, WireGuard with a configuration file you control, or OpenVPN with a profile, and to add the protections separately, for instance with a firewall rule that drops traffic when the tunnel is down. The difference in approach is that the generic route gives you full control and no account dependency, at the cost of having to implement the kill switch, the DNS policy and the per-network routing yourself. The IVPN client gives you all of that integrated and maintained, at the cost of being tied to one provider and to installing a privileged service from a binary you did not build.

Editorial conclusion

IVPN for Desktop suits somebody who wants the provider's kill switch, tracker blocking and trusted network behaviour rather than a bare tunnel, and who is willing to install a privileged system service to get them. It does not suit somebody who wants an independent client for their own WireGuard server, since the application is tied to one provider's account and locations, and it does not suit a build machine that cannot run the toolchain, since the Windows build alone needs Visual Studio with specific SDK and ATL components. Check three things before you build it: whether you want to run the daemon from a self-compiled binary at all, because it installs as a privileged system service, which platforms you actually need, since the ARM64 cross-compilation paths are documented separately for Windows and Linux, and whether the official signed build on the provider's site already does what you need, because the repository is mainly for developers working on the client itself. The last push to the repository was on 2026-10-19 and the newest release is v3.16.1.

Frequently asked questions

Official sources

1. ivpn/desktop-app on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases