Gaseous Server: a self-hosted ROM manager with in-browser emulation

What Gaseous Server actually manages

The project describes itself as the server for the Gaseous system: ROM and title management plus some basic in-browser emulation. Those are two jobs that are usually split across separate tools. A library scanner walks your files, identifies each ROM, and stores a title record. A separate web player then serves that ROM to a browser session. Gaseous does both from one .NET service.

The audience is narrow and specific. You need a local ROM collection, a machine to host a database, and a willingness to run a service that is not a desktop application. The README notes that version 1.7.0 and later include user authentication and can be exposed to the internet, but it immediately recommends against exposing the server unless you are actively using it remotely or have alternatives such as a VPN. That is a candid warning rather than a marketing line, and it should shape how you deploy it.

The metadata side depends on external services. An Internet Game Database API key is required unless you route through the Hasheous proxy, which the README lists as the way to avoid holding your own IGDB credentials. Signatures are optional but recommended before adding ROMs, per the wiki links the README points to.

How the pieces fit: database, scanner, metadata, EmulatorJS

The repository layout tells you most of the architecture. There is gaseous-server for the web application, gaseous-lib for shared code, gaseous-cli, gaseous-configurator, and gaseous-processhost. The last one is telling: emulation and long-running work are pushed into a separate host process rather than living inside the request pipeline.

Data flows in one direction at scan time. You add ROMs to a location the server can read, a Library Scan background task walks them, and each file is matched to a title record stored in MariaDB. Metadata comes from IGDB, directly with your API key or through the Hasheous proxy. The README is explicit that the Library Scan task is also the recovery path: if you migrate databases, you re-import all titles with it rather than converting the schema.

Playback runs through EmulatorJS, which the README credits as a JavaScript implementation of RetroArch. Gaseous does not ship its own emulator cores; it delegates that layer. The practical consequence is that the set of playable platforms is bounded by what EmulatorJS supports, not by what Gaseous itself implements.

The database requirement is the hard constraint. MariaDB 11.1.2 or later is preferred, MySQL Server 8 or later is supported, and the README warns that earlier versions may or may not work. It also states that moving from MySQL to MariaDB requires rebuilding the database from scratch because the earlier schema used MySQL-specific features. That is a real migration cost, not a footnote.

Installing Gaseous Server and running a first scan

The README does not inline installation steps. It points to the project wiki at github.com/gaseous-project/gaseous-server/wiki/Installation, and there is a docker-compose-build.yml at the repository root plus an installer/ directory, so both container and scripted paths exist in the tree. Because the exact image name, ports and environment variables are not given in the README, treat the wiki as the source of truth rather than guessing.

The one command the README does document verbatim is for the test suite, which is a useful sanity check that your .NET toolchain is set up:

dotnet test gaseous-server.Tests/gaseous-server.Tests.csproj

If that passes, the README says the suite covers JSON and binary response handling in HTTPComms.SendRequestAsync, Retry-After parsing and retry behavior, and cancellation token behavior. Those are all outbound HTTP concerns, which fits a server whose metadata depends on external APIs.

Once the server is running, the README's own order of operations is: optionally import signatures from the Signatures wiki page, then add ROMs following the Adding ROMs wiki page. After that, the Library Scan background task does the identification work. If you skip the signature import, the README presents it as optional, so scanning still proceeds.

For the database, plan on MariaDB 11.1.2+ or MySQL 8+. The README notes MariaDB is preferred and that the two should be interchangeable for existing users, with the MySQL-to-MariaDB rebuild caveat above.

Where Gaseous Server is the wrong tool

The release status is the first limitation. The most recent release listed is v2.0.0-rc.3 from 2026-07-04, preceded by rc.2 and rc.1 in the same June and July window. A release candidate line means the v2 branch is not yet declared stable. If your requirement is a finished, tagged version, the current release list does not give you one.

The database dependency is the second. Gaseous Server is not a single binary you drop on a NAS and forget. It wants a MariaDB or MySQL instance, and the README's own guidance about not exposing the server to the internet means you should think about network placement before you think about features. On a platform where running a separate database container is awkward, this is friction you will feel immediately.

The third limitation is scope of emulation. The README describes the browser emulation as basic, and it is built on EmulatorJS rather than an in-house core. If your goal is accurate, per-platform emulation with fine-grained core options, a browser layer is not the right place to look for it. Gaseous is a catalog and a launcher first; the player is a convenience on top.

Finally, metadata quality is bounded by the external source. IGDB coverage is good for well-known commercial titles and thinner for homebrew, translations and regional oddities. The README does not document a manual override workflow, so if identification fails for a set of files, the documented recovery path is the Library Scan task, not a hand-editing interface.

Gaseous Server compared with RomM

The README itself lists RomM under Friends of Gaseous, describing it as another self-hosted ROM manager. That is the honest comparison point, and the difference is in emphasis rather than category.

RomM is presented in that same line as a ROM manager. Gaseous Server is presented as a ROM manager plus basic in-browser emulation through EmulatorJS. So the split is roughly: if you want the collection organized and browsable, both aim at that; if you want to click a title and have it start in the browser without a separate emulator front end, that is the part Gaseous adds. The cost of that addition is the process host, the EmulatorJS dependency, and a server that the README advises against exposing publicly.

There is also a database story to weigh. Gaseous's MariaDB requirement and the MySQL-to-MariaDB rebuild caveat are specific to this project. Anyone already running RomM is not carrying that constraint, and anyone migrating between the two should expect to re-import rather than convert. The README's own instruction for that situation is to run the Library Scan background task to re-import all titles.

Licence and the cost of staying current

Gaseous Server is licensed under AGPL-3.0. For a self-hosted instance on your own hardware this changes little in practice. The obligation becomes relevant if you modify the server and let other people interact with it over a network, because AGPL-3.0 extends source availability to network users. If you are running an unmodified build for yourself, the licence is not the deciding factor. This is a description of the licence, not legal advice; read the LICENSE file in the repository if your situation is unusual.

Upgrade cost is dominated by the database. Because the README states that moving from MySQL to MariaDB requires rebuilding the database from scratch, and that the Library Scan task is how you re-import titles, a version upgrade that touches the schema is a rescan rather than a migration script. On a large collection that is measured in scan time and metadata API calls, not in downtime alone.

The release cadence visible in the release list is a tight rc cycle: three release candidates inside roughly three weeks in June and July 2026. The last push to the repository is dated 2026-09-08, so the project is being worked on, but the stable v2 tag is not in the release list. Budget for running a release candidate or pinning to the last v1 line if one is available to you.

Editorial conclusion

Adopt Gaseous Server if you already run MariaDB and want a browser front end over a local ROM collection, and accept that the newest line is a release candidate rather than a finished version. Do not adopt it if you need a stable tagged release today, or if you have no way to run a database server alongside it. Before committing, check the Installation wiki page for your platform, confirm your database version is MariaDB 11.1.2+ or MySQL 8+, and decide whether you will supply an IGDB API key or rely on the Hasheous proxy.

Frequently asked questions

Official sources

1. gaseous-project/gaseous-server on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases