umu, Wine and Proton: understanding compatibility tools and choosing Bottles runners

Open Bottles, spot the umu game entry, then open the runner list, and names such as Wine, Proton, Soda, ProtoSoda, Caffe, GE, and Lutris can quickly blur together. Should you switch the launcher or the runner? Can ordinary software and games share the same environment?

You can understand this ecosystem by following the execution chain: Wine provides Windows compatibility, Proton packages it into a gaming solution, umu organizes Proton's runtime outside the Steam client, and Bottles, Lutris, and Heroic handle installation and management. Once you know which step each name covers, choosing a tool is much easier than ranking compatibility by name.

Separate the compatibility layer, suite, runtime, and manager#

Wine provides Windows API compatibility; it does not require installing a Windows virtual machine first. Proton includes Wine, but also other components organized around running games. Having a Wine executable by itself does not give you the complete Proton workflow. The official Proton documentation describes it as a tool for running Windows games through the Steam client.

Graphics translation is one specific part of that stack. DXVK translates Direct3D 8/9/10/11 to Vulkan, while VKD3D-Proton handles Direct3D 12. These components can also be used with other Wine setups, so enabling DXVK in Bottles does not mean you are using Proton.

Wine:
Bottles / Lutris → Wine runner + components → Windows application

Steam + Proton:
Steam → Steam Linux Runtime → Proton → Windows game

umu + Proton:
Bottles / Lutris / Heroic → umu + runtime → Proton → Windows game

The last route makes some of the runtime infrastructure Steam normally organizes available to other launchers. The management interface may look different, while the underlying setup can use a similar Proton suite and the same umu infrastructure.

What umu solves: using Proton#

Proton needs the Linux environment it expects

Proton includes Wine, so invoking its wine directly to run an .exe can look like a shortcut. But this may bypass Proton's launch logic and container runtime, loading the distribution's own shared libraries instead. It might work when library versions happen to match; when they do not, failures can be hard to explain.

umu-launcher prepares the runtime, sets launch parameters, and invokes the selected Proton build; it can work without the Steam client installed. The GE-Proton maintenance notes also explicitly list umu as a supported way to use GE-Proton outside Steam.

The Steam Linux Runtime here is a Linux-side library and container environment. It makes library versions more predictable across distributions; it is not a Windows system image. umu provides this launch infrastructure, but does not replicate Steam's game store, accounts, download management, or full client functionality.

Game-specific fixes can be reused across launchers

Some games need specific dependencies, DLL overrides, or launch settings, which a Wine update alone may not resolve. The umu ecosystem's game-ID database and protonfixes let a launcher pass along game and store information, then allow a compatibility suite with fix support to apply the corresponding rules. This lets some game-specific adaptations be shared across launchers.

The game database identifies and matches games. A program without an entry can still be tried; if a game is not recognized or no ready-made rule exists, there is no corresponding game-specific fix. Understanding umu as shared runtime infrastructure and an entry point for fixes better reflects its role. Whether it improves frame rates still needs to be measured for the specific game.

Choosing a manager after Bottles adds umu#

Bottles 66 integrated umu into the Library and introduced ProtoSoda. Bottles stores game entries, prefixes, compatibility tools, dependencies, and settings; umu prepares Proton's runtime. This expands Bottles' gaming workflow, so it is more than just another Wine version in a drop-down list.

Soda belongs to Bottles' Wine runner line; ProtoSoda is designed for the Proton/umu workflow. Their responsibilities also need to be distinguished: ProtoSoda is the compatibility suite that runs the game, while umu launches that suite in the appropriate environment.

Lutris supports launching GE-Proton through umu; Heroic also uses umu for GE-Proton. Bottles and Lutris can therefore share the same runtime foundation; their differences are more about installation flows, dependency handling, parameter passing, and management.

Sharing a runtime foundation does not mean all installer scripts and settings are automatically interchangeable. When choosing a front end, consider where your games come from, the client installation flow, and whether you want to manage software environments in one place. PortProton, CrossOver, and PlayOnLinux also organize different experiences within the Wine ecosystem.

What runner names trade off#

Soda, Caffe, Kron4ek, and similar entries in Bottles are runners. The Lutris entry in that list usually means a Wine build provided by Lutris; distinguish it from the Lutris graphical manager.

These builds make different choices about patches, update cadence, packaging, and target applications. Wine Staging includes fixes and experimental features that have not entered Wine's main development branch; GE-Proton adds extra patches, media support, and game fixes to Proton. More patches may solve a particular issue, but can also introduce regressions, so runner names do not form a universal compatibility ladder.

Wine-GE and GE-Proton are separate projects. The once-common division of “GE-Proton in Steam, Wine-GE outside Steam” has changed: Wine-GE was archived on July 11, 2025, and its README points to umu as the successor route. You can now use GE-Proton outside Steam through umu. Keeping a Wine-GE version that an older program depends on still makes sense; for a new setup, prefer a currently supported option.

Winetricks helps install components and apply application compatibility settings; ProtonUp-Qt installs and manages compatibility tool versions. They handle supporting tasks in the execution chain; they do not provide the full Windows API compatibility layer or manage an entire game library.

Choosing Soda, ProtoSoda, and other runners#

For a new Bottles setup, you can start with a simple order: use stable Soda for ordinary Windows software; start with ProtoSoda for games managed through umu, and keep GE-Proton as the main fallback. This starting order reduces configuration variables. If a program already works reliably with another runner, you can keep that choice.

Bottles' runner documentation still describes lines such as Caffe and Vaniglia, and explicitly mentions Wine Staging patches for Vaniglia. This documentation reflects an older version context; check the components directory and each runner's release notes for currently installable versions.

Choosing Soda plus ProtoSoda mainly lets you use the two workflows Bottles has already organized. Traditional Wine bottles for ordinary software and a Proton suite for umu games do not mean that software must use Soda or games must use ProtoSoda.

ProtoSoda also combines work from other projects. For example, the ProtoSoda 11.0-2 release notes explicitly say its Wine core comes from Soda 11.0-7, while the launcher, runtimes, DXVK, VKD3D, and protonfixes are updated to versions corresponding to GE-Proton11-6. It is not an entirely separate stack from GE-Proton; compare the components in the specific release to understand the differences. If a game already works well on GE-Proton, keep using it instead of switching back to ProtoSoda just to make the list uniform.

Narrow down choices by use case when troubleshooting#

Ordinary Windows software

Start with stable Soda. If it fails, check the software's known requirements and logs, then try Caffe or Kron4ek with a specific reason. Choosing a build that contains a needed Wine fix is better supported than trying every runner in sequence.

Pay particular attention to the full Kron4ek suffix: vanilla is close to upstream Wine, staging adds Staging patches, and staging-tkg uses another patch combination. These are build differences, not low-, mid-, and high-end tiers. Choose a corresponding build when the program depends on a patch or is affected by a regression.

Games managed through umu

Try ProtoSoda with umu first, then try a recent GE-Proton with umu if you hit compatibility problems. If GE's release notes explicitly mention a fix for your game, start with GE. Reserve Proton-CachyOS for a known feature need or a direct comparison test; the label “optimized” by itself does not guarantee better performance on your machine or in your game.

Versions also need to be assessed individually. As of October 14, 2026, Soda 11.0-10 is a stable release, while 11.0-30-experimental is explicitly marked as a prerelease and says it does not replace the current stable release. A higher number with experimental in its name does not automatically supersede a stable release. Record the full version, release channel, and component makeup to tell what changed later. Specific versions will continue to change, so check the corresponding release page before downloading.

For important software, keep a complete backup of the prefix while it is shut down, and try a new runner in a test bottle; change one variable at a time. If you change the runner, graphics components, and a batch of DLL settings together, it is hard to tell which change caused an improvement or a failure. Before removing an old runner, check that no existing bottle still depends on it.

Applying this to Steam, client games, and NixOS#

Having Steam manage Steam games, Lutris manage other games, and Bottles manage other Windows software remains a convenient daily split. With umu added to Bottles, this split is more a management preference: the compatibility capabilities underneath can overlap, so there is no need to migrate an environment that already works.

Keep Steam games in Steam so the client can coordinate official Proton and the runtime. For client-based games such as Battle.net and Hearthstone, you can keep an already configured Lutris setup; choose based on the client's installation and management flow, while actual compatibility still depends on the client, game, and runner versions at the time. Put ordinary software in Bottles, and feel free to try Bottles' umu workflow for a new standalone Windows game.

A predictable Linux runtime is especially valuable on NixOS. The official umu documentation already explains using pkgs.umu-launcher from nixpkgs, so you do not need to add an Arch Distrobox solely to use umu. Use a distribution package adapted for your system, and still check the graphics drivers, runtime, and program behavior; avoid arbitrarily extracting Wine from inside Proton.

For a performance comparison, align the game version, compatibility tool, graphics components, launch settings, and runtime. The Bottles or Lutris interface name alone says little about which will be noticeably faster; if you see a difference, first inspect the components and parameters they actually invoke. Valve's Proton documentation also explains the conditions for anti-cheat support: a kernel-level anti-cheat unsupported by the game will not become usable just by switching managers or adding umu.

Keep the daily setup simple: retain stable Soda and ProtoSoda, add GE-Proton when a game needs it, use Kron4ek to troubleshoot ordinary software, and turn to other runners for specific needs. Keep combinations that already work, and adjust the relevant layer only when a concrete compatibility problem appears.