Retrom

Last reviewed Sep 13, 2026 · 846 words

Retrom does not play games in a browser. That is the first thing to know, because it is what separates it from RomM, the bigger project in the same space. Retrom is a library server plus a native desktop client: the server catalogues ROMs and installed games and fetches artwork, the client on each PC downloads a game from the server, keeps it locally, and launches it in the emulator you configured. Think of it as a private Steam or a self-hosted Playnite with a shared backend, not a web arcade.

The client is the product, the server is the catalogue

The server runs in Docker and stores metadata in PostgreSQL. The client is a Tauri desktop app for Windows, macOS and Linux with a built-in library view, game pages with box art and descriptions, and an installer that pulls files from the server to a local directory. Once a game is installed it launches locally, so play performance has nothing to do with the server; a Raspberry Pi could serve a library that a gaming PC plays. The server also serves a browser version of the client for browsing and editing metadata, but launching from there requires the desktop app.

That design suits one household with several machines, or a small group who want one curated library and their own local emulators. It does not suit someone who wants to open a tab on a hotel laptop and play; that is RomM's job, with the ceiling that in-browser emulation implies.

The compose and the config file

services:
  retrom:
    image: ghcr.io/jmberesford/retrom-service:latest
    ports:
      - "5101:5101"
      - "3000:3000"
    volumes:
      - ./config:/app/config
      - /srv/games:/app/library
    restart: unless-stopped

Configuration lives in config/config.json, which sets the database URL, the content directories, and the metadata provider credentials. Recent releases can run an embedded PostgreSQL so the compose stays a single service; an external postgres container works as well and is what I would use for anything you intend to keep. Port 5101 is the service the clients talk to; the second port serves the browser client. Give the library mount at least the 512 MB the catalogue suggests for the service, and remember the storage for games sits on the server twice over: once in the library and once on each client that installs it.

The library layout decides whether anything shows up

Retrom's default expectation is one folder per platform, one folder per game inside it, and the game's files inside that folder. A multi-disc PlayStation title with three .bin files and a .cue is one game folder, which is the correct answer and something flat-folder scanners get wrong. A second content directory can use the single-file layout, where each file under a platform folder is a game, which suits cartridge systems where one ROM is one game. Mixing the two layouts inside one directory is not supported, so decide per directory before you copy anything in.

Platform folder names are matched against IGDB platform names during the scan, so Nintendo 64 works and n64 needs a manual mapping. The first scan of a few thousand files takes minutes; the metadata pass afterwards takes longer because IGDB rate-limits requests.

Metadata needs two accounts

IGDB is the primary provider and requires a Twitch developer application for a client ID and secret, the same chore RomM users know. Steam integration is optional and needs a Steam Web API key plus your Steam ID; with both, Retrom lists your Steam library alongside emulated games and launches them through Steam, which is the closest the project gets to a unified launcher. Without IGDB credentials you get a working library with no art, which looks like a broken install and is not.

Where it stands against RomM and GameVault

RomM is the larger project, plays in the browser through EmulatorJS, and has a wider platform-naming and metadata setup. GameVault is closest to Retrom's model, with a Windows-first client and a Docker backend aimed at PC games rather than emulation. Retrom is the youngest of the three, first released in 2024, and is at the stage where the client changes noticeably between releases. It is the best of the three at the specific job of "one library, several PCs, local emulators", and behind the other two at everything else.

What I'd do

Run Retrom if your play happens on 2 or more PCs with proper emulators and you want them sharing one library and one set of art. Set up the content directories before the first scan, get IGDB keys the same day, and put the service behind Tailscale rather than exposing it; there is no reason a game server needs a public port. If your goal is playing from any browser, or your collection is mostly 8-bit and 16-bit cartridges, RomM is the safer and more finished choice, and the folder work you do for one carries over to the other almost unchanged.