Blender Launcher V2: keeping stable, daily and experimental Blender builds in one place

A fork of an archived project, rewritten from the ground up

Blender Launcher V2 is the second generation of a tool that began as the Blender Version Manager by DotBow, then became Blender Launcher by the same author. The relationship is stated plainly at the top of the readme: this project exists because DotBow/Blender-Launcher has been inactive since October 2022, was archived on the 28th of November 2023, and no longer receives updates.

So this is not a new product with an unclear origin. It is a maintained continuation of a specific tool that lost its maintainer, and the second version is described as rewritten from the ground up for better stability and extensibility.

What it manages is the build matrix of Blender and its forks. The launcher covers stable releases, daily builds and experimental branches, with the download endpoints for each named in the readme, and it adds support for the two most popular forks: Bforartists, described as a UI-focused fork, and UPBGE, described as a game engine fork with stable and weekly builds.

That combination is the actual value proposition. Blender publishes a lot of builds, and picking the right one for a task is a recurring decision: a stable release for production work, a nightly to check whether a fix has landed, an experimental branch to test something unreleased, a different fork entirely if you want a different interface or a game engine. The launcher turns that into a library you can browse and a double click, rather than a directory of downloaded archives.

A tray menu is the primary interface

The core feature list is short enough to read in full, and it says what kind of application this is.

There is automatic checking of the latest builds. There is fast access to favourite builds through the tray context menu, or by middle clicking the tray icon, which is the fastest path for someone who launches Blender dozens of times a day. You can register the .blend file extension for a preferred build, so double clicking a .blend file in your file manager opens the version you want rather than whatever was installed last. There are startup arguments for launching Blender, and template installation.

And there is an indication of running builds and the number of instances, which sounds like a small feature and is not. If you have three Blender versions open, knowing which build is which window matters, because a scene saved by a nightly build may not open in a stable one.

The second generation adds what you would expect from a rewrite: faster starting times by caching data, support for high DPI displays, and a set of what the readme calls multiple power user features and quality of life improvements.

The screenshots referenced in the readme show the shape of it, with views for the library of stable builds, daily downloads, user favourites, and the tray. That is a media manager for application builds, with the media being Blender.

Building it is a Python project with a Makefile and a style generator

The repository is a Python project with a pyproject.toml, and the build is driven by a small Makefile with three targets.

Running it locally is two commands:

run:
	python build_style.py
	python source/main.py

The style file is generated before the application starts, which is why build_style.py appears both in the run target and in the build target. The test target is narrower than you would expect, running pytest against a single module, source/modules/version_matcher.py, which tells you the version matching logic is the part with dedicated unit tests.

The build target branches on the operating system. On Windows it runs a batch script, and everywhere else it runs a shell script:

build:
	python build_style.py
ifeq ($(OS),Windows_NT)
	./scripts/build_win.bat
else
	./scripts/build_linux.sh
endif

The project metadata says the package version is 2.7.6, and there is a version.txt at the root of the repository as well as a version_matcher module in the source tree. The declared Python range is 3.11 up to but not including 3.15.

The dependency list is long and tells you what the application actually does. PyInstaller builds the executable, pyside6-essentials provides the user interface, beautifulsoup4 and lxml parse the download pages, urllib3 with socks support handles the transfers, zstandard and py7zr handle the compressed archives, pywin32 is Windows only, python-xlib is there for the X11 side on Linux, pynput handles the middle click on the tray icon, keyring stores credentials, webdav4 and send2trash point at a file management and backup feature, dateparser and fuzzysearch handle the release and search matching, python-i18n handles translations, and semver, distro and certifi handle versioning, platform detection and certificates.

A GPL-3.0 desktop app with an open question about platform support

The licence is GPL-3.0, declared in the project metadata and with a LICENSE file at the root of the repository. There is also a NOTICE file, which is the convention for GPL projects that bundle third party work, and this one bundles a lot: the lxml, json, Qt and other libraries ship inside the executable.

The platform story is specific. The launcher is described as available for 64-bit Windows, Linux with GLIBC 2.31 and higher, and macOS. The GLIBC floor is a real constraint on older distributions, and it is the kind of detail that decides whether a Linux user can run the build at all.

The maintenance picture is good. The repository is not archived, the default branch is main, and the last push was on 2026-10-14, about a week before the current date. The three most recent releases are v2.7.6 from 2026-07-18, v2.7.5 from 2026-07-04 and v2.7.4 from 2026-06-04, so releases are monthly-ish and the patch numbering is plain.

The oddity in the topic list is b3d, which is a file format rather than a feature. That is a hint about what the .blend registration feature is actually about: the launcher is the kind of tool you use precisely because you work with .blend files across multiple Blender versions and need to know which one produced a given file.

The development tooling is modern for a desktop utility. Ruff is the linter, configured with a line length of 120 and a target version matching the minimum supported Python, with a long list of rule sets selected, and pytest for the test extra. The Makefile runs a single module's tests, and there is a .zed/ directory for the Zed editor at the root.

Where a launcher is the wrong answer

A launcher earns its place when there is more than one thing to launch. If you install Blender once and never touch the nightly builds, this is a layer between you and an application that opens in one click.

The official installers already handle the single stable case well, and the launcher does not change what Blender is. It changes how you obtain and start it.

There is a second class of mismatch. The value of the launcher scales with how many builds you actually use. Someone who works on a stable release and occasionally wants to test a nightly gets most of that benefit from the official download pages. Someone who has a stable build for client work, a nightly for development, an experimental branch for evaluating an incoming change, and a fork for a specific workflow is the user this tool is built for.

The dependency profile points at a third consideration. This is a Python application shipping a Qt interface, a WebDAV client, a credential store and platform-specific code for Windows and Linux, packaged with PyInstaller into a single executable. That is a lot of moving parts for a utility, which means the release binary is the sensible way to consume it, and running from source is mainly for contributors.

The fork lineage is worth keeping in mind too. Because this continues an archived tool, the workflow and concepts will feel familiar to anyone who used the original Blender Launcher, and the fact that a community of users and contributors exist for it is what made the continuation possible at all.

Editorial conclusion

Blender Launcher V2 suits a Blender user who juggles stable, daily and experimental builds, or who wants the file association and startup arguments of a given build handled in one place, and it suits anyone who wants the archived original launcher revived. It does not suit a team that just wants one current Blender install, since the official installers already cover that, and it is a single maintainer project rather than a foundation effort. Before downloading, read the installation page for your platform, note that Linux builds need GLIBC 2.31 or newer, and check the version you install against the 2.7.6 release line.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Victor-IX/Blender-Launcher-V2 on GitHub