NonSteamLaunchers on Steam Deck: install Epic, GOG and Battle.net under one Proton prefix

What NonSteamLaunchers actually fixes on a Steam Deck

A Steam Deck ships with Steam and nothing else. Epic Games, GOG, Battle.net, Ubisoft Connect, the EA App, Amazon Games, itch.io, Rockstar Games Launcher, PS Plus, Glyph, VKPlay and HoYoPlay all have Linux or Proton paths, but none of them appear in Game Mode on their own. The usual manual route is: download the Windows installer, add it as a non-Steam shortcut, force a Proton version, run it, find the executable it produced, add that as a second shortcut, then repeat for artwork and controllers.

NonSteamLaunchers automates that sequence. According to the README, it installs the latest UMU and GE-Proton, puts every launcher under one Proton prefix folder named NonSteamLaunchers inside your compatdata path, and adds the launchers to your Steam library. It also watches for installed games and adds or removes them from the library in real time as you install or uninstall them inside a launcher.

The audience is narrow and specific: Steam Deck and Steam Machine owners on SteamOS who want storefront libraries in Game Mode, plus people on Ubuntu LTS, ChimeraOS, Nobara, Arch Linux and KDE environments who are willing to try it. The README says it can be used on Desktop or in Game Mode. It is not a compatibility layer and it is not a way around anticheat. The README states plainly that certain anticheat games will not work in Linux environments, on a game-by-game basis.

One prefix, UMU, and a scanner that keeps your library in sync

The architecture has three moving parts. The shell entry point, NonSteamLaunchers.sh, does the installation and the Steam library registration. A Python component, NSLGameScanner.py, is what the README describes as adding games automatically in real time and removing them when you uninstall them from a launcher. The prefix itself is a single compatdata folder named NonSteamLaunchers, and UMU Launcher is used for each game and launcher, with GE-Proton where necessary.

That single-prefix decision is the interesting one. Sharing one prefix means one Wine registry, one set of installed Windows dependencies, and one place to look when something breaks. It is also why the README can say ProtonTricks works with the default installation: point ProtonTricks at that prefix and you can fix any game or launcher. The trade-off is that all launchers share a Windows environment, so an installer that writes conflicting registry keys or DLLs affects everything in the prefix, not just itself.

The README documents an escape hatch. When installing a launcher you can tick Separate App Id's, which installs launchers into their own prefixes and, per the README, works automatically with ProtonTricks. Choose that if you expect to tinker. Choose the default if you want the smallest number of prefixes to reason about.

Around the core install sit several smaller pieces: .desktop files created per shortcut so games and launchers can run outside Steam, collections created and removed per launcher, playtime tracking, per-shortcut boot videos, game theme music, and metadata cards including player counts where Steam has them. RemotePlayWhatever is bundled for local co-op between non-Steam games, and Ludusavi is pre-installed for save backups.

Installing NonSteamLaunchers on Steam Deck and running a first launcher

The README gives a command-line path that works without cloning anything. It pipes the shell script from the repository into bash and passes the launcher name as an argument. The example in the README installs Epic Games:

/bin/bash -c 'curl -Ls https://raw.githubusercontent.com/moraroy/NonSteamLaunchers-On-Steam-Deck/main/NonSteamLaunchers.sh | nohup /bin/bash -s -- "Epic Games"'

Run it from Desktop Mode, not Game Mode, because the installer needs to write into your compatdata folder and register shortcuts. After it finishes, open Steam and look for the launcher entry in your library. The README says a NonSteamLaunchers shortcut also appears; it does nothing, and the instruction is to right-click it, choose Manage, then Hide this Game.

For the Python side, the repository declares its own environment rather than documenting a separate install procedure. pyproject.toml sets requires-python to ">=3.11,<3.13" and lists four runtime dependencies: python-decouple, python-steamgriddb, requests and vdf. The pinned requirements.txt carries certifi, charset-normalizer, idna, python-decouple, python-steamgriddb, requests, urllib3 and vdf.

There is also a Dockerfile that builds on python:3.11.4-slim-bullseye and creates a non-root appuser, which is useful for testing the Python side away from a Deck but does not install launchers.

Two things happen on first run that are worth knowing. Save backups land in /home/deck/NSLGameSaves, and the README states the Desktop version backs up once, when the script opens and shows the main options list, while the Decky plugin version backs up on every manual scan. Pressing Update Proton GE fetches the latest Proton GE and UMU and applies a patch for Discord game streaming in Game Mode.

Where NonSteamLaunchers breaks, and when it is the wrong tool

The honest limitation is the same one that makes the tool work: it writes into Steam's library configuration. Anything that regenerates or resets shortcuts can undo its work, and the README's own troubleshooting note about a NonSteamLaunchers shortcut that does nothing shows how much of the experience is Steam client behaviour rather than the script's logic. If your shortcuts disappear after a Steam update or a client reset, that is the failure mode to expect.

Save backups are partial. Ludusavi is pre-installed and set up, but the README is explicit that not all games work with it yet and that you should bear this in mind before deleting or uninstalling games that are not backed up. Treat /home/deck/NSLGameSaves as a best-effort copy, not a guarantee.

Anticheat is out of scope. The README states that certain anticheat games will not work in Linux environments on a game-by-game basis. No launcher wrapper changes that.

If you want isolation, NonSteamLaunchers is the wrong shape by default. One prefix for every launcher is convenient until two launchers disagree about a dependency. Use Separate App Id's, or use a tool built around per-application prefixes from the start.

Finally, there is the distribution problem. The README carries a prominent warning that this is the only official GitHub repository and that forks, copies and modified versions are not considered official or affiliated unless they contribute back or have an established relationship with the original project. Downloading from a site that reuses the name and logo is the risk, not the code.

How this differs from Lutris and from Bottles

Lutris is the closest general-purpose alternative, and the difference is in what each one optimises for. Lutris is a desktop application: you install it, it manages runners, and it has its own library window where you launch games. Its model is a runner plus a per-game configuration, and it does not try to make entries appear inside Steam's Game Mode interface.

NonSteamLaunchers inverts that. There is no library window. The Steam library is the interface, and the script's job is to create shortcuts, artwork, collections and metadata so that Game Mode looks populated. That is why it cares about shortcuts.vdf, .desktop files and SteamGridDB metadata, and why it does not care about being a good desktop game manager.

Bottles takes a third position: it builds isolated Wine prefixes as first-class objects, which is the opposite of the single shared NonSteamLaunchers prefix. If your problem is "these two Windows applications conflict," Bottles is the more natural answer. If your problem is "I want Epic and GOG in my Deck's library tonight," NonSteamLaunchers is the shorter path.

The overlap is real, and running more than one of them against the same Steam library is a way to get duplicated or orphaned shortcuts.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent and small: v4.2.90 on 2026-05-28, v4.2.91 on 2026-06-08, v4.2.92 on 2026-09-14. The version in pyproject.toml is 4.2.3, which does not track the release tags, so do not use the Python package version to decide whether you are current.

Upgrade cost is mostly the cost of re-running the installer and letting it re-register shortcuts and metadata. Because the prefix is shared, a Proton or UMU bump applies to everything at once, which is either the feature or the risk depending on how stable your launchers are. The README's Update Proton GE button is the intended path for that.

Licence is MIT, declared in pyproject.toml and present as a LICENSE file at the repository root. MIT permits use, modification and redistribution with the licence and copyright notice retained. This is not legal advice, and it covers this project only: RemotePlayWhatever and Ludusavi are separate projects bundled with it, each with its own licence and its own repository, and UMU and GE-Proton are separate components again. If you redistribute a bundled build, check each one rather than assuming MIT covers the whole payload.

Editorial conclusion

Adopt NonSteamLaunchers if you want Epic, GOG, Battle.net or Ubisoft titles inside Steam Game Mode without hand-building shortcuts, and if you accept that the script rewrites shortcuts.vdf and stores one prefix for everything. Skip it if you need separate prefixes per launcher, if you use ProtonTricks heavily, or if you want a tool that never touches the Steam client's own files. Before installing, check that your SteamOS build still allows third-party .desktop entries, read the repository's official download warning, and confirm where the script will write by looking at the generated NonSteamLaunchers prefix path in your compatdata folder.

Frequently asked questions

Official sources

1. License: MIT
2. moraroy/NonSteamLaunchers-On-Steam-Deck on GitHub
3. Project website
4. README
5. Releases