Gaseous Server: a self-hosted ROM manager with a browser emulator bolted on
A game ROM manager, with a built in web based emulator using multiple sources to identify and provide metadata
At a glance
- What is it?
- Gaseous Server is a C# application that indexes a ROM collection, matches titles against metadata sources, and serves playable games through a web front end. The 2.0 line is still at release candidate, and the README is candid that exposing it to the internet is your own risk.
- Who is it for?
- Adopt Gaseous Server if you already run MariaDB, want a browser front end over a local ROM collection, and are comfortable tracking a 2.0 release candidate rather than a finished version. Do not adopt it if you need a stable tagged release, if you cannot supply an IGDB API key or route through the Hasheous proxy, or if you expect to expose the library to the open internet without a VPN in front of it.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Gaseous Server fills between a folder of ROMs and a playable library
A ROM collection on disk is just files with names that may or may not correspond to anything. Gaseous Server exists to turn that into a browsable, searchable library with artwork and titles attached, and then to let you launch a game without leaving the browser. The README describes it as offering "ROM and title management, as well as some basic in browser emulation of those ROMs". That word basic is doing real work, and it is the honest framing of what the emulation layer is.
The intended user is someone self-hosting on their own hardware who already has a ROM set and wants a single web interface over it. The topics list on the repository (self-hosted, rom-management, retrogaming, emulation) matches that audience. This is not a desktop front end and not a service you sign up for. It is a server you run.
The metadata problem is the part that justifies the project's existence. Matching a file called something like a dump name against a real game title, platform and cover image is tedious to do by hand at any scale. Gaseous Server uses multiple sources for that identification step, which is the core of the pitch in the repository description.
Identification, storage and playback: the three moving parts
The architecture visible in the material splits into three concerns. First, a database layer. MariaDB 11.1.2 or newer is the preferred store, with MySQL Server 8 or newer supported. The README notes these are the versions the project has been tested and developed against and that earlier versions may behave differently. Second, an identification layer that pulls metadata, which is where the Internet Game Database API key comes in. Third, a web front end that renders the library and embeds an emulator.
The emulator is not written by this project. The README credits EmulatorJS, described as a JavaScript implementation of RetroArch, as the component that provides in-browser playback across a range of platforms. So the data flow is roughly: ROM files land in a directory, a scan indexes them, the identification step resolves each to a title and metadata, the database stores the result, and the browser loads the ROM through the EmulatorJS front end.
The README also points to an optional signatures import step before adding ROMs. Signatures appear to be how the server recognises ROM contents rather than trusting filenames, which is the more reliable approach when dump naming conventions vary. The wiki page for signatures is linked but its contents are not reproduced in the README, so the exact signature format and source are not something I can describe from this material.
Getting it running: database, ffmpeg, and an API key you may be able to skip
The prerequisites are short and specific. You need MariaDB 11.1.2 or newer, or MySQL Server 8 or newer. You need ffmpeg on the host. You need an Internet Game Database API key, and the README is explicit that this is "only required when not using the Hasheous proxy". That single sentence matters more than it looks, because it means there is a path to running Gaseous Server without registering for your own IGDB credentials, provided you accept routing metadata lookups through a third party.
Installation itself is not documented in the README. It points to a wiki page at the gaseous-server/wiki/Installation path on GitHub. I cannot reproduce those steps because they are not in the supplied material, and guessing at a Docker invocation or a systemd unit would be fabrication. What the README does confirm is that Docker images are built on release tags, since one of the three build badges is labelled "Build Release Docker Image" and triggers on tag. There is also a nightly build workflow. So container images exist for both release and nightly channels, but the exact image name and run command come from the wiki, not from here.
For contributors rather than operators, the README gives one concrete command: dotnet test gaseous-server.Tests/gaseous-server.Tests.csproj. The test suite is narrow. It covers JSON and binary response handling in HTTPComms.SendRequestAsync, Retry-After parsing and retry behaviour, and cancellation token behaviour. That is a focused set of tests around the HTTP communication layer, not broad coverage of scanning, matching or database logic.
The MySQL to MariaDB migration is a rebuild, not an upgrade
The most concrete limitation in the README is a migration trap. Because the earlier database schema used MySQL-specific features, moving from MySQL to MariaDB "will require rebuilding your database from scratch". The mitigation offered is that the Library Scan background task can re-import all titles.
That is a real cost, and it scales with library size. If you have years of hand-corrected metadata, custom artwork or manual title fixes, a full rebuild means losing them unless the scan reproduces the same corrections, which it will not for anything you edited by hand. Anyone currently on MySQL should treat the move to MariaDB as a project with a data-loss risk, not a version bump. The README presents MariaDB as preferred and MySQL as continuing to be supported for existing users, so staying put is a legitimate choice, but the two are described as interchangeable only in the sense that the project supports both, not that you can slide between them.
The second limitation is the emulation itself, which the README calls basic. EmulatorJS is credited as fast and supporting a wide variety of platforms, but that is praise for the upstream project, not a claim that Gaseous Server exposes every EmulatorJS capability. If browser play is the main reason you are interested, the emulation quality is the thing to evaluate against your own platform list before you invest in the library side.
Exposing it to the internet is explicitly your problem
Version 1.7.0 and later added user authentication, and the README states the server can be exposed to the internet as a result. It then immediately walks that back. The recommendation is not to expose the server if you are not actively using it remotely, or if you have alternatives such as a VPN. And the closing line of that note is blunt: "if you expose the server to the internet you do so at your own risk".
Read those two sentences together and the position is clear. Authentication exists, but the maintainers are not claiming it has been hardened for hostile traffic. For a self-hosted service holding a personal media collection, a VPN or a reverse proxy with its own access control is the sensible posture, and the README effectively says so. This is not a limitation the project hides. It is one it states twice.
The related operational point is that a server which is only reachable on your LAN does not need to be running all the time. The README's advice to avoid exposing it when you are not actively using it remotely suggests the expected deployment is intermittent or at least network-restricted, not a permanently public endpoint.
RomM is the obvious comparison, and the README makes it for you
The README lists RomM under a Friends of Gaseous heading, alongside EmulatorJS. Both are self-hosted ROM managers, so the overlap is direct. The difference in approach is visible in how each project is described here. Gaseous Server is a C# server whose distinguishing feature is the built-in browser emulation layer, delivered by embedding EmulatorJS. RomM is presented without that framing, which suggests its emphasis sits on the management and library side rather than on playing games in the browser.
That is the axis to compare on. If your goal is a well-organised, metadata-rich library that you browse and then play elsewhere, the emulation layer in Gaseous Server is weight you may not need. If your goal is to click a game in a browser tab and have it start, that is precisely what Gaseous Server is built around and the feature that justifies its existence.
The two projects also differ in language and, by extension, in the runtime you have to operate. Gaseous Server is C# and .NET, which is why the CI badges reference a dotnet workflow and why the test command is a dotnet test invocation. RomM's stack is not described in this material, so I will not characterise it beyond the fact that it is a separate self-hosted ROM manager. The README's own framing of the relationship is friendly rather than competitive, and there is a Discord link for each.
Licence and the cost of tracking a release candidate
Gaseous Server is AGPL-3.0. That is a strong copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the AGPL's source-availability obligation is generally understood to apply to your modified version. For a personal self-hosted instance this is unlikely to matter. For anyone considering building a hosted service on top of it, the licence terms are the first thing to read in full. This is a description of the licence's general character, not legal advice, and the actual terms are in the repository's licence file.
The maintenance picture is the more immediate concern. The most recent releases listed are v2.0.0-rc.1, rc.2 and rc.3, dated June and July 2026. The last push to the default branch is September 2026, so the project is active, but the 2.0 line has not produced a stable release in the material provided. Anyone deploying today is either running a release candidate or running the 1.x line, and the README's own notes about 1.7.0 and later suggest that line is where the authentication work landed.
Upgrade cost is dominated by the database. Because the schema changed in ways tied to MySQL-specific features, the README already documents one scenario where a full rebuild is required. That precedent is worth weighing when deciding how much manual curation to invest in the library. The Library Scan background task is the recovery mechanism, and it re-imports titles from the ROM files, which means anything not derivable from the files themselves is at risk.
Editorial conclusion
Adopt Gaseous Server if you already run MariaDB, want a browser front end over a local ROM collection, and are comfortable tracking a 2.0 release candidate rather than a finished version. Do not adopt it if you need a stable tagged release, if you cannot supply an IGDB API key or route through the Hasheous proxy, or if you expect to expose the library to the open internet without a VPN in front of it. Before committing, verify three things: that your MariaDB is 11.1.2 or newer, that the Library Scan background task completes against your actual ROM directory, and that your chosen platforms run acceptably under EmulatorJS, since the README describes the emulation as basic.
Community notes