RomM turns a ROM folder into a self-hosted library, but you run a database, a cache and Python 3.14 to get there

Enrichment depends on outside metadata services

RomM scans a ROM collection and then enriches it, which in practice means matching your files against outside services. The named providers are IGDB, Screenscraper, LaunchBox and MobyGames for game metadata, SteamGridDB for custom artwork, and RetroAchievements for achievement tracking. The project claims metadata from more than ten providers and metadata coverage for more than 400 platforms, with support for multi-disk games, DLCs, mods, hacks and manuals.

The consequence is that the quality of your library pages is set by those third parties, not by RomM. A platform with thin coverage at the providers will look thin in RomM too, and anything those services change about their APIs reaches your install. The dependency list in pyproject.toml fits this outward-facing design: aiohttp, httpx2 and yarl for HTTP, defusedxml for parsing XML safely, strsimpy for string similarity, and Unidecode for normalizing titles.

Browser play runs through EmulatorJS and RuffleRS

The headline feature is playing directly in the browser with EmulatorJS and RuffleRS, with no client setup on the device you play from. A built-in ROM patcher applies romhacks and translations on the fly, so a patched variant does not need a separate file on disk before you can launch it.

The build side shows how much of this is compiled in. The Dockerfile pins Emscripten (emsdk 4.0.12, with separate amd64 and arm64 image digests) and uses it to build game-music-emu 0.6.5 from a fixed commit, 9e23d10f9fd2a6a2f33b10912dd8dc7153258995, through a script in docker/gme. A comment notes that the development image uses the same bases as docker/Dockerfile so that system tools such as 7zip, libmagic and libarchive match production. Archive handling is therefore a server concern: zipfile-inflate64 and python-magic are runtime Python dependencies, and the image ships the native libraries they lean on.

The stack is an app, a database and Valkey, not a single binary

RomM is a web service with state. SQLAlchemy is installed with the mariadb, mysql and postgresql-psycopg connectors, alembic handles schema migrations, and redis plus rq run background jobs. The repository's own docker-compose.yml, which is the development setup, wires three services together: romm-dev built from the Dockerfile, a MariaDB container and a Valkey container.

  romm-db-dev:
    image: mariadb:13.0.2

  romm-valkey-dev:
    image: valkey/valkey:9.0.6

The compose file opens with a pointer to the full example under examples/docker-compose.example.yml, and that example, not the dev file, is the one to base a home server on. The dev file exposes ports 3000 and 5173 for Vite, 8443 for HTTPS, 5678 for debugpy and the backend API on DEV_PORT, which defaults to 5000. Database credentials come from variables such as DB_ROOT_PASSWD, DB_NAME, DB_USER and DB_PASSWD, with insecure defaults like rootpassword when unset. The practical cost: you are now operating and backing up a database volume, and a lost volume means a lost library index, users and sync state even if the ROM files survive.

Python 3.14 and pinned Alpine images tie you to the container

pyproject.toml declares requires-python = ">=3.14", and the Dockerfile sets PYTHON_VERSION=3.14 with a comment that the base image tag cannot read .python-version, so the two must be kept in sync by hand. The same file pins Alpine 3.24, Node 24.22 and uv 0.13.4, each with a SHA256 digest. Dependencies are locked in uv.lock.

For a reader this has two effects. First, running the backend from source on a distribution whose system Python is older than 3.14 is not an option; you either install a newer interpreter or use the container, and the container is the path the project expects. Second, the pinning is strict on purpose, which makes the published image reproducible but means you get base image and library updates only when the maintainers cut a release. Contributors have a separate DEVELOPER_SETUP.md and a .devcontainer/ directory. Note that pyproject.toml carries version 0.0.1, so do not read the running release from it; releases are tagged on GitHub, most recently 5.4.1.

Save sync, per-user permissions and OIDC make it a shared service

Saves and states sync across your devices with conflict resolution, which is what turns RomM from a catalog into something you play from in several places. Libraries can be shared with granular per-user permissions, and login can go through OIDC single sign-on. The repository ships a separate docker-compose.oidc.yml, and a comment in the main compose file pins the project name so the default network stays romm_default and both docker-compose.oidc.yml and docker-compose.streaming.yml can join it.

Authentication pulls in authlib, joserfc, bcrypt, itsdangerous and cryptography as runtime dependencies. The examples/ directory also carries configuration files aimed at existing frontends: config.batocera-retrobat.yml, config.es-de.example.yml and a general config.example.yml. If you already organize ROMs for Batocera, RetroBat or ES-DE, start from the matching example file rather than reorganizing folders to suit RomM. Apprise is a dependency too, and opentelemetry and sentry-sdk are installed for tracing and error reporting, so check which of those you leave disabled if the no tracking promise matters to you.

Only three clients are official; the rest is unreviewed community code

The team maintains three apps. The Playnite plugin integrates a RomM library into Playnite on Windows desktops with QR pairing. Argosy is an Android launcher with a gamepad-first interface for Anbernic, Retroid Pocket, Odin and similar handhelds, with library sync, downloads on demand, achievement tracking, QR pairing and save sync. Grout is a lightweight Linux client for handheld custom firmwares that downloads games, box art and BIOS files wirelessly and syncs saves automatically; it supports Allium, Batocera, Knulli, MinUI, muOS, NextUI, Onion, ROCKNIX, Spruce and TrimUI.

Everything else is community work: a native iOS app (romm-ios-app), Android TV and Android apps, macOS and cross-platform desktop clients, Steam Deck tools such as the Tender Decky Loader plugin and RomMix, a PS Vita client and a client for jailbroken PS5s. The project states that its team does not regularly review their source code. The consequence is concrete: iPhone, macOS and Steam Deck users have no first-party client, and the app they install receives your server address and credentials without any review by the RomM maintainers. Read that code, or limit the account it uses.

Hosted installs are affiliate offers, and releases come in quick succession

For people who do not want to wire up the stack, the project points to two hosted deploys: Hostinger starting at $6.49 per month and CoreHost starting at $2.30 per month, each with a setup guide on docs.romm.app. Deployment and infrastructure support for those installs is handled by Hostinger and CoreHost, not by the RomM team, the prices are marked as indicative, and both hosts send a share of revenue back to the project. Self-hosters start from the Quick Start Guide and the troubleshooting page in the docs.

The project is under active development. The repository is not archived, the last push was on November 2, 2026, and recent releases landed close together: 5.4.0-beta.1 on October 9, 2026, 5.4.0 the next day on October 10, and 5.4.1 on October 22. The code is AGPL-3.0-only, with no paid features. A beta that became a stable release within a day leaves little time for wider testing, so wait for a point release before moving a household server to a new minor version.

Editorial conclusion

RomM suits people who already keep their own ROM collection, are comfortable running a containerized stack with a database and Valkey, and want browser play, save sync and per-user sharing in one place. It does not suit anyone who wants a single desktop program, or who expects first-party iOS and Steam Deck clients. Before installing, check which metadata providers you will rely on, plan backups for the database volume, and decide whether a community client you plan to use is code you are willing to trust unreviewed.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes