The Vencord Installer is a Go program that patches Discord's app.asar

What the installer actually does to Discord

The Vencord Installer allows you to install Vencord, which the README describes as the cutest Discord Desktop client mod. The tool itself is described as a cross platform GUI and CLI app.

The mechanism is visible in the repository file names, and they are the whole story. There is app_asar.go and openasar.go, which together handle reading and writing the app.asar archive, the single packaged file that Electron applications ship their code in. There is patcher.go, which does the patching. There is github_downloader.go for fetching the mod, and self_updater.go for keeping the installer itself current.

Then there is the platform discovery layer, with one file per operating system: find_discord_windows.go, find_discord_darwin.go and find_discord_linux.go, plus find_shared.go for the parts they have in common. Finding the Discord installation is the step that differs between platforms, because Discord installs to a different place on each and, on macOS, ships as an application bundle.

So the sequence is: locate the Discord installation, download the Vencord payload, open the app.asar, inject the mod, and write the archive back. The complexity of this project is not in the patching, which is a well understood operation, but in finding Discord correctly on three operating systems and in shipping a graphical interface from Go without dragging in a large toolkit.

The GUI is a third party immediate mode layer over CGO

The dependency list in go.mod explains the GUI decision. The primary dependency is github.com/AllenDang/giu, a Go port of the immediate mode GUI pattern, built on github.com/AllenDang/imgui-go. The supporting cast is github.com/fatih/color for terminal colours, github.com/manifoldco/promptui for interactive terminal prompts, and golang.org/x/sys for system calls.

The indirect dependencies tell the rest of the story. There is go-gl/gl and go-gl/glfw/v3.3/glfw, which is the OpenGL and windowing layer that the immediate mode interface draws through, and github.com/faiface/mainthread, which exists to keep certain calls on the operating system main thread, a requirement of macOS GUI code. There is github.com/pkg/browser for opening links, and github.com/mattn/go-isatty and go-colorable for terminal detection.

None of that appears in the CLI build. The Makefile turns CGO off by default and adds a cli tag, and it only turns CGO on and pulls in the GUI dependencies when the GUI variable is set. That is a sensible split: the CLI variant is a static binary with no cgo, and the GUI variant needs a C toolchain and a graphics stack.

The consequence for a user building from source is that the GUI build needs considerably more than the CLI, and on Linux it needs the display libraries listed in the next section.

Building the GUI on Linux needs an X11 or a Wayland dependency set

The build prerequisites are Go and GCC, with MinGW on Windows. The Linux case is expanded in a details block with three dependency groups, and the split is by display server rather than by convenience.

The base dependencies cover the graphics libraries the interface needs to draw at all:

apt install -y pkg-config libsdl2-dev libglx-dev libgl1-mesa-dev
dnf install pkg-config libGL-devel libXxf86vm-devel

The X11 group is what you need on a traditional X session:

apt install -y xorg-dev
dnf install libXcursor-devel libXi-devel libXinerama-devel libXrandr-devel

And the Wayland group is for a Wayland session:

apt install -y libwayland-dev libxkbcommon-dev wayland-protocols extra-cmake-modules
dnf install wayland-devel libxkbcommon-devel wayland-protocols-devel extra-cmake-modules

That the project carries both lists, and a separate Makefile flag for each, is a reasonable position for a desktop tool in a period when Linux sessions are split between the two display protocols. The cost is that a Wayland user who wants the GUI has to install a fairly long list of development packages before anything compiles.

The build itself is then three commands, with a different make invocation per target. Dependencies first, then the GUI or the CLI:

go mod tidy

make GUI=1

make GUI=1 WAYLAND=1

make

The last one builds the CLI. The README also notes that you might want to pass some flags to get a better build, and points at the project's GitHub release workflow for the flags the author uses, or for more precise instructions.

The Makefile encodes the platform differences as variables

The Makefile is short but it is where most of the platform knowledge lives, and reading it tells you what the installer has to cope with.

The PLATFORM and ARCH variables come from the Go environment by default, and they can be overridden. VERSION comes from git describe --tags --abbrev=0, and HASH from the short commit hash, and both are baked into the binary through linker flags so that the installer can report which build it is. The buildinfo directory in the repository is the Go package that receives those values.

The GUI, DMG and WAYLAND variables default to 0, and the presence of GUI changes the build in three ways. CGO is enabled only for the GUI, the cli tag is dropped in favour of nothing, and the output name gains a Cli postfix for the non GUI build, so the two binaries can coexist in the same directory.

Windows gets its own treatment. When the platform is Windows and the GUI is off, the linker flags add a static external link. When the GUI is on, they add -H=windowsgui, which is what stops a console window from appearing behind the graphical interface on Windows. This is the classic Go GUI on Windows problem, and handling it in the build is the correct place for it.

macOS is handled differently again, with a loop that builds for each architecture and then, when ARCH is universal, uses lipo to create a combined binary and PlistBuddy to set the version and build number in the application bundle's Info.plist. The macos directory holds the application bundle template that gets copied into the build directory.

A self updater and a PowerShell script sit beside the Go code

Two files in the repository deserve a mention because they are not what you would expect from a Go program.

There is install.ps1, a PowerShell script sitting at the repository root, and a winres directory that is almost certainly the resource file for the Windows executable icon and version metadata. The PowerShell script is a separate installation path for Windows users who want to run the installer from a script rather than downloading a binary.

Then there is self_updater.go, alongside github_downloader.go. The downloader fetches the Vencord payload from GitHub, and the self updater handles the installer updating itself. The split matters: the tool that modifies your Discord installation is a separate program from the thing it installs, and both are updated independently, which means the installer can fetch a newer mod than the version it was built to expect.

The README's usage section does not document any of this. It says simply to see vencord.dev/download, which is where the prebuilt binaries and the guided instructions live. That is a reasonable division of labour, with the download page as the entry point and this repository as the source, but it does mean the source tree is the more informative document for anyone who wants to understand what the installer does to their system.

Where the Vencord Installer is the wrong tool

Four situations rule it out.

The first is a machine you do not own. The installer modifies the Discord desktop application's app.asar, which is a filesystem write into a program's installation directory, and on Windows that usually means administrator rights. On a work machine with a managed Discord install, or one where Discord came from a store that keeps it in a protected location, the install will fail or require elevation you should not grant. Some organisations also consider client modification a policy violation, and the installer does not check for that.

The second is the browser version of Discord. The whole mechanism depends on the desktop client being an Electron application with an app.asar on disk. The web client has no such file, and neither does the mobile app.

The third is a Linux session you cannot compile for. If you are on a distribution whose package manager does not have the X11 or Wayland development packages, or you are on a platform with no display server at all, the GUI variant will not build, and the CLI is a different tool with a different interaction model.

The fourth is a need for a reversible, scripted install across many machines. This is a GUI first tool with a CLI variant, and neither is described as having an unattended or declarative mode. For a fleet of machines you want a script that you can audit and run, not an installer that opens a window.

The alternative worth naming is the manual patch. The Vencord project documents how to patch a Discord install yourself, and doing it by hand is what the installer automates. The difference in approach is that the manual route leaves you in control of exactly which files change and lets you keep a backup you control, while the installer searches for the installation, downloads and patches in one flow. For one machine you do not care about, the manual route is arguably the better choice precisely because it is transparent. For a machine you are about to forget about, the installer's self update and download handling is the reason to prefer it.

Editorial conclusion

Vencord Installer fits a user who wants the Vencord mod on a Discord desktop install and prefers a guided tool to a manual patch, particularly on Linux where the X11 and Wayland dependency lists are the fiddly part. It is the wrong choice for a Discord client you do not own, such as a managed work machine, and it is the wrong choice if you need to install on a platform the project does not cover, since the discovery code is explicitly per operating system. Before you run it, check three things: that you have write access to the Discord installation directory, since patching an app.asar is a filesystem modification of a program you did not install, that your Discord installation is the desktop client rather than the browser version, and that you have a working restore path, because a failed patch of the archive can leave you with a client that will not start.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Vencord/Installer on GitHub