Retro gaming / emulation frontend as a module
Posted by Nultima
RomM is a self-hosted open-source ROM manager that can support 400+ platforms like PS1, SNES, GBA, N64, etc. It's feature rich, has a large community, and is actively developed. Setup requires the rommapp/romm image, a database (MariaDB, MySQL, or PostgreSQL), and Redis for background tasks. Since TomSparkBox exports everything to plain Docker Compose files, we theoretically could drop RomM's docker-compose.yml in the /opt/sparkbox setup and it should run alongside the rest of the stack. We might be able to just manage those containers with standard docker compose commands rather than the sparkbox CLI. but since SparkBox manages its own Docker network (sbproxy), its own reverse proxy (NPM), its own module lifecycle (sparkbox up/down/update/upgrade all read the enabled-modules list)... manually adding an unmanaged compose stack in the same install root could work fine, or it could collide with SparkBox's own updates/backups/sparkbox up behavior in ways neither of us can predict from here. Still, I think it could be built into SparkBox directly so its managed as a container instead. If not, is there something like a browser-playable retro emulation server (there are self-hosted, containerizable options in that space) that would actually fit SparkBox's model better?
3 replies
Chris wrote:
Thanks for the great question, Nultima\! RomM is indeed a solid choice for a retro gaming setup. Your intuition about the compose approach is spot-on — you absolutely can drop RomM's compose into /opt/sparkbox/modules/romm/docker-compose.yml and manage it through standard Docker commands. You'd use docker compose -f /opt/sparkbox/modules/romm/docker-compose.yml up -d to start it, and it would run alongside the rest of your stack. However, adding it as a first-class SparkBox module (with dashboard integration, the sparkbox CLI commands, automatic backups, and the app store) would require us to build that integration into the core. That's the kind of feature that gets logged for future consideration — RomM specifically, or "games/emulation module" more broadly. For now, the compose-file approach is your best path. Two notes if you go that route: 1. Networking: Add networks: [sbproxy] to RomM's service definition so it can reach your SparkBox apps and they can reach it. 2. Persistence: Mount RomM's database and library outside the container so data survives updates. The compose example usually shows this already. I'll log this as a feature request so the team can track interest in a native RomM module. In the meantime, happy to help troubleshoot the compose setup if you run into any snags. Are you planning to run this on your main SparkBox instance, or a separate one?
Nultima wrote:
I'd ideally like to run this on my main SparkBox instance so that I could visit the :8080 port in my browser and be able to play ROMs directly through there. I'm very interested in a native RomM module if its possible to add, I'd rather not do any side routes without specific CMD commands so i can easily reinstall the networking and persistence etc as needed when updates or backups cause conflicts.
Chris wrote:
Got it — running it as a native module would definitely give you the simplest lifecycle and integration with backup/restore/update cycles. For now, the docker-compose approach is the quickest path. When you set it up, make sure RomM's database (MariaDB/MySQL/PostgreSQL) and the ROM library volume are both mounted to persistent paths outside the container — something like /media/romm-db and /media/roms — so they survive container restarts and updates. Wire it into the sbproxy network and set up an NPM proxy entry (Settings → Proxy Hosts) pointing to RomM's web service so you get it on your domain. The native module request is logged, and the team will evaluate it alongside other feature priorities. In the meantime, if you run into any snags with the compose setup — networking, persistence, or getting NPM to route to it cleanly — holler and I'll help troubleshoot.