Skip to content
RetrogamingDeep Dive Published Updated 7 min readViews unavailable

Lutris vs. Heroic: Managing Non-Steam Libraries, Runners, and Prefixes

Compare Lutris and Heroic for imported PC libraries, then plan store ownership, runners, Wine prefixes, backups, and a portable recovery test.

Lutris and Heroic Games Launcher can put games from several sources behind one library view, but they solve overlapping - not identical - problems. Heroic is a storefront-oriented client for Epic, GOG, and Amazon Prime Games. Lutris is a broader Linux game manager that combines runners and installation recipes for native games, Windows titles through Wine/Proton, emulators, and other launch targets. Neither tool transfers game ownership, makes every storefront title compatible, or guarantees that a copied library will launch on another computer.

The important operational choice is not which launcher has the nicer grid. It is which component owns authentication, the installed files, the runner, the per-game configuration, and the Windows prefix. Map those boundaries before importing or migrating a large library.

The practical division of responsibility

Concern Heroic Lutris
Primary role Store-integrated client for Epic, GOG, and Amazon Prime Games Multi-runner library and installation manager
Library source Store accounts and supported imported game entries Store integrations, local entries, and community installer definitions
Windows-game path Per-game Wine/Proton settings; current Linux releases integrate umu for Proton workflows Wine runner settings, other runner types, and per-game configuration layered over runner/system defaults
Best fit A library centered on the stores Heroic integrates directly A mixed library needing varied runners, custom launch configuration, or emulator support
Migration hazard Store login, install location, prefix, and Flatpak filesystem access may all matter Game database, YAML configuration, runner versions, scripts, and external game paths can be separate

Heroic’s current project information lists Epic, GOG, and Amazon Prime Games support across Linux, Windows, and macOS. On Linux it exposes compatibility-tool management and per-game settings, and its current project documentation describes umu integration for Proton. Lutris describes a wider platform: it links or imports supported game libraries, uses community-authored installer scripts, and delegates launch behavior to runners. That breadth is useful, but it means two neighboring library entries may have completely different install and execution paths.

Inventory the source before importing

For each title, record the storefront or publisher account that owns it, the exact edition and language, where the files are installed, whether it has a native Linux build, and whether the launcher depends on an account client or online service. Keep credentials inside the supported sign-in flow; do not copy authentication tokens into scripts or public configuration. Download or restore game files only from sources you are authorized to use. A launcher entry is metadata, not proof that the files beneath it are present or valid.

If a game is already installed, identify its actual executable and data directory before using an import or “locate existing install” function. Avoid starting a second download into a different directory until you know whether the launcher can adopt the existing files. Store-specific identifiers help a client connect an entry to a catalog record, but the identifier does not validate a manually moved folder or convert a game to a different store edition.

Use Heroic when the library is primarily from its supported stores and you want that client to manage sign-in, downloads, updates, and per-game compatibility options. Use Lutris when the library is mixed across native Linux releases, Wine games, emulators, standalone executables, or custom installer recipes. The choice is not exclusive: the two applications can coexist, but one game should have one clearly documented owner for install paths and launch settings.

Choose a runner per title, not by habit

A runner is the component that actually launches the game: a native executable, a Wine/Proton compatibility stack, an emulator, or another supported program. A launcher can organize many runner types, but it cannot make a runner’s behavior interchangeable with another’s. A Windows title and a native Linux build may use different files and different settings even when they share one store listing.

Lutris stores system-, runner-, and game-level configuration, with the more specific game settings taking precedence over runner defaults and system defaults. Installer scripts can set up files and an initial configuration, but maintainers recommend keeping scripts focused rather than pinning every possible runner option. Treat a community installer as executable setup instructions: read the actions and URLs, confirm the sources, and verify that it asks for files you have a right to install.

Heroic exposes per-game Wine settings and manages compatibility tools through its Wine Manager. On current Linux builds, its official project notes umu integration and recommends a compatible Proton runner for non-Flatpak installs. umu is a separate compatibility layer that lets supported clients run Proton with Steam Runtime components outside the Steam client. This is why “I selected Proton” is not the whole configuration: note which client invoked it, which Proton distribution and runtime were selected, and what game ID or store metadata the integration supplied.

Do not reuse a Wine prefix simply because another game came from the same store. A prefix is a mutable Windows-like environment containing registry and filesystem state; it can also hold settings or local saves. Keep one prefix per game by default unless you have a reason to share one, and preserve a copy before changing major Wine/Proton versions, architecture, or installed dependencies. An update that works for one title may break another application sharing that prefix.

Make portability a tested property

“Portable” can mean that an application starts from a removable drive, that the game files can be moved, or that an entire library can be restored with its launch behavior intact. Those are different claims. A working migration may require the launcher database, game-specific settings, runner binaries, Wine prefixes, artwork, scripts, store authentication, environment dependencies, and the original external path layout. A profile export is not automatically an archive of all game data or dependencies.

Lutris documents export/import commands for game entries and tracks configuration and library metadata in separate files and a database. Heroic’s troubleshooting documentation likewise calls out cases where a game is installed at a different path than the client expects. In both tools, an exported launcher entry or copied executable can still point at an old directory or runner. Flatpak installations add another boundary: the sandbox must be allowed to see a library on an external disk, and access permissions need to be preserved on the destination system.

For a recoverable migration, close the launcher and all games first. Copy - not move - the game files, relevant per-game settings and prefixes, and the launcher data you intend to preserve. Record the versions of Lutris/Heroic, the runner, the source storefront, and the filesystem paths. On the new host, install the launcher from its official source, reconnect accounts through its normal sign-in process, select or install the intended runner, then repair paths deliberately. Keep the old copy untouched until representative titles pass the tests below.

Acceptance test a small representative set

Choose one native Linux title, one Wine/Proton title, and one title with a launcher, installer, or external dependency. For each, verify:

  1. The correct store/account and edition appear in the library.
  2. The expected installed files are present at the path shown in the game settings.
  3. The selected runner and version match the recorded baseline; a native build is not accidentally replaced by its Windows counterpart.
  4. The game reaches playable content and passes input, display, audio, and any required account or online checks.
  5. A save can be created and reloaded after a clean exit; synchronization is tested separately from local save behavior.
  6. The launch still works after restarting the launcher and operating system, not only in the session that imported it.

If it fails, inspect ownership and path resolution first, then the runner and prefix, then game-specific dependencies. Do not delete the prefix or reinstall the game as the first diagnostic step. Preserve logs and the original data, change one variable, and retest. A useful library record names the client, store, install path, runner, prefix path, and tested build for each game. That record - not a launcher icon - is what makes a cross-store library maintainable.

Related:

Sources:

Comments