Retrom: self-hosted game library management for emulation and DRM-free collections

Self-hosted game library as an alternative to commercial launchers

Retrom solves a specific friction point: owning a large collection of emulated or DRM-free games and wanting to play them from different machines without copying files around or maintaining separate emulator configurations everywhere. The README describes it as "a sort of self-hosted Steam for your DRM-free game library."

Hosting the service on 1 device makes that machine the source of truth. Clients on other devices connect to it, browse the library, download or install games, and launch them through emulator profiles that are stored server-side so they stay in sync across installs. A web client adds browser-based play through EmulatorJS when no desktop client is available.

This is a different model from running emulators directly with their own per-machine configurations. Retrom centralizes game files, metadata, artwork and emulator profiles so that reinstalling a client or switching to a different machine does not require reconfiguring everything from scratch.

Rust server, Tauri desktop client and web client via EmulatorJS

The backend is a Rust workspace. Cargo.toml names 8 packages: client, codegen, db, service, grpc-service, rest-service, service-common, telemetry, and webdav-service, along with 8 plugins (retrom-plugin-config, retrom-plugin-installer, retrom-plugin-launcher, retrom-plugin-service-client, retrom-plugin-standalone, retrom-plugin-steam, retrom-plugin-webdav-client, retrom-plugin-save-manager). The presence of grpc-service and rest-service as separate Cargo packages points to a multi-transport architecture rather than a single HTTP API.

Desktop clients are built with Tauri v2, which targets Windows, macOS and Linux. Flatpak packaging files (io.github.jmberesford.Retrom.desktop, io.github.jmberesford.Retrom.metainfo.xml) are present in the repository root, indicating an intent to distribute through Flatpak-compatible stores.

The web client runs EmulatorJS for in-browser play. It does not require any client install, which matters for a device like a smart TV or a borrowed computer where installing a native app is not practical.

Docker for the server, pre-built clients for Windows, macOS and Linux

Getting started requires 2 separate steps: deploying the server and installing a client. The README points to the Quick Start guide on the project wiki for setup details, so the README itself contains no deployment commands.

For the server, the roadmap includes "Publish server binaries, as an alternative to Docker" as an unchecked item. Docker is the only documented deployment path at this stage. A machine that cannot run Docker cannot host the Retrom service. The repository root includes a docker/ directory and a .dockerignore file, but no Docker Compose example or image name appears in the README.

Clients for Windows, macOS and Linux are pre-built and available to download from the project page. Desktop clients support controller input and fullscreen mode alongside the standard window mode, both of which the feature list marks as complete.

Steam integration works today; GoG and multi-user auth are still pending

Steam is the 1 third-party platform the roadmap marks complete. The feature is listed under "Unify your emulation library with third party libraries," with Steam checked and GoG shown as "soon." Native PC, Linux and macOS games appear as experimental.

Multi-user authentication is listed in the roadmap under Basic server functionality with a checkbox that is not filled. This is a significant gap for a multi-device sharing setup. If the intent is for multiple family members to have their own libraries and save states, that separation does not exist yet. All clients connecting to a Retrom server share 1 library.

Metadata download from IGDB is complete. The SteamGridDB provider for artwork and metadata is listed as incomplete. For libraries with games that do not appear in IGDB (many older or obscure titles), that gap means artwork fetching will not work until SteamGridDB support ships.

Cloud saves for standalone emulators are also unfinished. Save syncing works only for emulators built into Retrom, not for separately configured emulator installations.

Emulator profiles stored on the server for cross-device sharing

One of the core arguments for using Retrom over managing emulators directly is the server-side profile store. Each desktop client can configure multiple emulator profiles, and those profiles are stored on the server rather than locally.

The practical result is that reinstalling the desktop app on a different machine does not require rebuilding the emulator configuration. The roadmap item for default profiles for popular emulators is not yet complete, which means initial setup still requires manual configuration even though that configuration is then preserved.

The roadmap also lists a set-default-per-platform feature for desktop clients as complete. That means assigning a default emulator to a console platform is done once on the server and applies when launching any game from that platform, regardless of which desktop client does the launching.

Grid view, server binaries and built-in emulator profiles are still missing

Several features visible in other self-hosted media managers are not available yet. Grid view (as opposed to the default list view) is an open item. Built-in emulator profiles for popular emulators, which would let new users skip emulator configuration entirely, are also pending.

Cloud save syncing covers built-in emulators but stops there. Standalone emulator cloud saves are listed as an open item, so any emulator installed separately on the client machine will not have its save data synced by Retrom.

For a project aiming to be "a sort of self-hosted Steam," the missing multi-user authentication is the most consequential gap. A real Steam replacement needs to give each user a separate library and save space. Retrom does not do this yet, and the roadmap notes it is coming but gives no timeline. Teams evaluating Retrom for a household with multiple players should check the roadmap link (https://github.com/users/JMBeresford/projects/7) for current status, since the README acknowledges that list is often out of date.

Cargo.toml and package.json carry different version numbers in the same repository

Retrom is a mixed-language monorepo and its 2 main manifest files disagree on version. Cargo.toml at the workspace level declares 0.8.4 while package.json at the repository root declares 0.7.51, a gap of a full minor version in the same project.

This discrepancy is easy to miss when examining the repository, and it matters for anyone who checks one manifest as a proxy for the state of the entire build. Build tooling that reads both files will see 2 different answers for the same question. The JavaScript side of the monorepo lags the Rust workspace on numbering, and nothing in the repository documentation explains why.

GPL-3.0 applies to the Rust workspace. Any redistribution of a modified build requires making the source available under the same terms, which matters for teams that plan to package Retrom as a managed appliance rather than self-hosting the stock build.

Editorial conclusion

Retrom works for collectors who want to browse and launch a DRM-free or emulated game library from multiple devices without relying on a commercial platform. Skip it if you need multi-user accounts for separate libraries, a server that runs without Docker, or GoG integration, because those items are all still marked incomplete in the roadmap. Before self-hosting, read the Quick Start guide on the wiki (the README links there rather than including setup steps), confirm your server machine can run Docker, and match the Cargo.toml version number against the feature checklist in the roadmap to understand what the build you downloaded includes.

Frequently asked questions

Official sources

1. Issues
2. JMBeresford/retrom on GitHub
3. License: GPL-3.0
4. README
5. Releases