RomM

Last reviewed Aug 26, 2026 · 830 words

RomM will not recognise a single game until your folders are named the way it expects, and it will not show a single box-art image until you have registered a Twitch developer application to get IGDB credentials. Those 2 chores are the entire difficulty of the project. Get them right and you have a 12,000-star, GPL-3.0 library manager that scans a directory tree, pulls metadata and artwork, and plays a large share of the collection in a browser tab on any device in the house. The ROMs themselves are your problem; RomM ships none, and it is the Jellyfin of retro games in exactly that sense.

The folder layout decides whether the scan works

RomM reads one library root and expects one directory per platform, named with that platform's slug: snes, n64, gba, psx and so on. It accepts 2 shapes, library/roms/<platform>/ or library/<platform>/roms/, and it does not accept "Nintendo 64 (USA)" or whatever your last organiser produced. Multi-disc games go in a subfolder per game so the discs group together, and BIOS files go in library/bios/<platform>/, which matters because the browser emulator will refuse PS1 titles without one. Rename before the first scan. Renaming after means RomM sees a new library and you lose the manual metadata fixes you made.

Metadata needs 2 accounts before the first scan

The good artwork comes from IGDB, which is owned by Twitch, so you create an application in the Twitch developer console and copy its client ID and secret into IGDB_CLIENT_ID and IGDB_CLIENT_SECRET. ScreenScraper is the second source, better for European region sets and for older systems; it wants a username and password, and free accounts are rate-limited hard enough that a big first scan runs overnight. MobyGames and SteamGridDB keys are optional extras for coverage and alternative art. Without any credentials, RomM lists files by name with no art, which works but looks like a file browser and misses the point.

Compose: RomM plus a database

services:
  romm:
    image: rommapp/romm:latest
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=romm-db
      - DB_NAME=romm
      - DB_USER=romm
      - DB_PASSWD=change-me
      - ROMM_AUTH_SECRET_KEY=paste-output-of-openssl-rand-hex-32
      - IGDB_CLIENT_ID=your-twitch-client-id
      - IGDB_CLIENT_SECRET=your-twitch-client-secret
    volumes:
      - ./romm/resources:/romm/resources
      - ./romm/assets:/romm/assets
      - ./romm/config:/romm/config
      - /srv/roms:/romm/library
    depends_on:
      - romm-db
    restart: unless-stopped
  romm-db:
    image: mariadb:latest
    environment:
      - MARIADB_DATABASE=romm
      - MARIADB_USER=romm
      - MARIADB_PASSWORD=change-me
      - MARIADB_ROOT_PASSWORD=change-me-too
    volumes:
      - ./romm/db:/var/lib/mysql
    restart: unless-stopped

The 4 volumes have distinct jobs: resources holds downloaded artwork, assets holds emulator saves and states, config holds the YAML for platform aliases and exclusions, and library is your ROMs, mounted read-only if you like. The catalogue's 512 MB minimum is honest because the heavy lifting, the emulation itself, happens in the visitor's browser; the server mostly serves files and thumbnails.

In-browser play is real, with a hard ceiling

The web player covers the 8-bit and 16-bit consoles, Game Boy through GBA, PS1, N64 and DS. It does not cover PS2, GameCube, Wii or anything newer, and no amount of server RAM changes that, since the emulator is JavaScript running on the client. Saves and save states are written back to /romm/assets, so a game started on the living-room TV browser picks up on a laptop. A 600 MB PS1 image takes a noticeable moment to load over Wi-Fi the first time. For the heavier systems, RomM is the catalogue and something like RetroArch on a real device is the player; the web UI serves downloads, and there are community integrations for handheld firmwares and a Playnite plugin that pull from a RomM instance directly.

Users, exposure and the obvious legal note

The first account created is the admin; further users get viewer, editor or admin roles, so a household can share one library without anyone deleting the metadata. Keep the whole thing on the LAN or behind Tailscale. A public RomM instance is a public ROM server, which is a different legal category from a private collection of games you own, and the browser player makes it trivially usable by strangers. More options in this space are listed under game engines and libraries.

What I'd do

Spend the first evening on folders and credentials, not on Docker. Rename platforms to slugs, put BIOS files in place, register the Twitch application, then start the compose file and kick off a scan before bed. Mount the library read-only, keep the instance LAN-only, and treat the browser player as the way you play SNES and GBA on whatever screen is nearest, with RetroArch on a proper device for everything heavier. Run like that, RomM does for a ROM folder what Jellyfin does for a media folder, with about the same amount of upfront tidying.