umu-launcher: running Windows games on Linux without Steam

The problem umu-launcher solves for non-Steam launchers

Steam launches a Proton game through a chain of processes: a reaper, a launch wrapper, the Steam Linux Runtime entry point, and finally proton itself. The README shows exactly that chain for Guilty Gear XX Accent Core Plus R, with the game executable at the end. The launch wrapper is described as a process runner whose only real job is forwarding environment variables, and those variables are what Proton expects in order to work. Pull them out and Proton can run without Steam at all, which is the whole premise of this project.

The target audience is not really the end user. The README names Lutris, Bottles, Heroic and Legendary directly and asks what this means for them: shared protonfixes, no per-launcher install scripts, no Steam binaries required, and one online database of game fixes. umu-launcher exists so those launchers can stop maintaining their own Proton plumbing and feed a GAMEID, a STORE, a PROTONPATH and a WINEPREFIX into a single command. If you are a launcher author, that is the pitch. If you are a user, you get the same runtime Steam uses, but you have to drive it yourself or through a launcher that has already integrated it.

How umu-run wraps the Steam Linux Runtime container

The README is unusually direct about the mechanism: umu is a copy of SteamLinuxRuntime_sniper, which is a compiled version of steam-runtime-tools. The bash script that Valve calls _v2-entry-point is renamed to umu, and umu-run is added to replace steam-launch-wrapper. When you invoke umu-run, it takes the WINEPREFIX, Proton version, executable and arguments you supply and runs the game in Proton inside Steam's runtime container, the same way Steam would.

Two details matter for anyone debugging it. First, umu-launcher downloads the Steam Runtime version that Proton requires and moves the files to $HOME/.local/share/umu, so the container is not something you install by hand. Second, GAMEID and STORE are not cosmetic: they are looked up in the umu-database at umu.openwinecomponents.org, and protonfixes uses them to find the fix script for that title before the game starts. The same umu ID is meant to stay identical across stores, with the store type only selecting which folder of fixes to read. That is a cleaner design than per-launcher patch scripts, but it also means an unlisted game gets no fixes at all.

Installing umu-launcher and running your first game

The README points to the project documentation and wiki for setup rather than listing install commands itself, so the exact package name depends on how you get it. What the README does document is the invocation and the environment variables, and those are the part you will actually use. The simplest form passes only the executable and its arguments:

umu-run "$HOME/Games/epic-games-store/drive_c/Program Files (x86)/Epic Games/Launcher/Portal/Binaries/Win32/EpicGamesLauncher.exe" -opengl -SkipBuildPatchPrereq

With no WINEPREFIX set, the prefix defaults to /home/username/Games/umu/GAMEID, and with no GAMEID set it defaults to umu-default. The full form sets the prefix, the game ID, the store and the Proton build explicitly:

WINEPREFIX=$HOME/Games/epic-games-store GAMEID=umu-dauntless STORE=egs PROTONPATH="$HOME/.steam/steam/compatibilitytools.d/GE-Proton8-28" umu-run "$HOME/Games/epic-games-store/drive_c/Program Files (x86)/Epic Games/Launcher/Portal/Binaries/Win32/EpicGamesLauncher.exe" -opengl -SkipBuildPatchPrereq

PROTONPATH accepts either a full path to a Proton build or the literal value GE-Proton, which makes umu-run download and use the latest GE-Proton. The default is UMU-Proton, described in the README as the latest stable Valve Proton with UMU compatibility added. STORE defaults to none. On first run, expect the runtime container to be fetched into $HOME/.local/share/umu before anything launches, so the first invocation is slower than later ones.

Where umu-launcher is the wrong tool

The project is classified in pyproject.toml as Development Status 4 - Beta, and that is not boilerplate. It is a copy of Valve's runtime with modifications, which means bugs can come from either side of that copy, and the README does not describe a rollback path if a runtime download or a Proton build breaks a prefix. There is also no documented GUI. The tool is umu-run plus environment variables, so anyone who wants to browse a library, manage prefixes visually or change Proton versions with a dropdown needs a launcher on top of it.

The bigger constraint is the Proton assumption. umu-launcher runs games in Proton inside Steam's container; it is not a general Wine prefix manager. If your workload is a native Windows application that needs a specific plain Wine build, or a prefix you have already tuned by hand outside Proton, the container and the protonfixes layer are extra machinery between you and the app. And if a title has no umu ID in the database, you are running it with the default fixes, which is the same starting point you would have had with any other launcher. The database is the value, and it only covers the titles it covers.

umu-launcher compared with Lutris and Heroic

Lutris and Heroic are launchers; umu-launcher is the runtime layer they can call. That distinction is the actual difference in approach. Lutris historically managed its own Wine and Proton runners, its own per-game install scripts and its own prefix layout, which is why the README frames the goal as ending individual install scripts per launcher. Heroic targets Epic and GOG specifically and has its own download and library management. umu-launcher does none of that: it takes an executable you already have, a prefix path, a store tag and a game ID, and runs it through the same container Steam uses.

So the comparison is not really versus a competitor. If you want a library, downloads and a settings UI, umu-launcher is not that and never claims to be. If you are writing one of those tools, or you want the smallest possible path from a Windows executable to Proton, umu-run is the layer you want. The README explicitly invites Lutris, Bottles, Heroic and Legendary to use the same umu-run and feed their environment variables into it, which tells you the intended relationship is composition, not replacement. The payoff, if launchers adopt it, is that a protonfix written once applies everywhere instead of being reimplemented per launcher.

Maintenance, packaging and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-09-19, four days before this writing. Release 1.4.4 is dated 2026-07-25, with 1.4.3 the day before and a 1.4.2.rc0 test build on 2026-07-13, so the release cadence is active rather than dormant. The maintainers listed in pyproject.toml are GloriousEggroll and R1kaB3rN, with several other authors credited, and the project requires Python 3.10 or newer. The presence of Cargo.toml, a Rust cdylib named umu_delta and a pyo3 dependency means part of the code is compiled rather than pure Python, which matters if you are packaging it for a distribution: you need a Rust toolchain, not just pip.

The licence is GPL-3.0, and the pyproject.toml license field points at README.md rather than a separate text file, which is unusual and worth checking if you vendor the metadata. For most users this changes nothing. For anyone embedding umu-launcher in a launcher or shipping it in a distribution, GPL-3.0 has obligations that a permissive licence would not, and the practical question is whether your own code links against it or merely invokes umu-run as a separate process. That is a legal question for your own counsel, not something this article can settle. Upgrade cost is mostly the runtime download: umu-launcher fetches the Steam Runtime version Proton needs into $HOME/.local/share/umu, so a Proton upgrade can pull a new container with it.

Editorial conclusion

Adopt umu-launcher if you are building a Linux game launcher, or if you want Epic, GOG or standalone Windows games running through Proton without Steam installed. Do not adopt it if you need native Wine prefixes without Proton, or if you want a graphical front end: umu-launcher is a command-line tool and the README does not describe a GUI. Before relying on it, check that the umu-database has an entry for your GAMEID, confirm which PROTONPATH you will pin, and read docs/umu.1.scd for the flags the README does not list.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Open-Wine-Components/umu-launcher on GitHub
4. README
5. Releases