Gameyfin: a self-hosted library for your game files

Jellyfin's model, pointed at game files

Gameyfin's name and functionality are inspired by Jellyfin, and the analogy is exact. Jellyfin's proposition is that a media collection on your own hardware should be indexed, enriched with metadata and artwork, and then browsed and shared from any device with a browser, with the server doing the work rather than a streaming service doing it for you. Gameyfin applies that to video games.

The README states the promise plainly. It will turn your disorganized collection of video games into a beautiful, easy-to-navigate library that you can access from any device with a web browser. It automatically scans your game folders, downloads metadata and cover images, and presents everything in a user-friendly interface. You can download your game files directly from the web UI, share your library with friends, and enjoy your games.

The framing words are simple, fast and FOSS, and the last of those is a statement of policy as much as of licence. The feature list ends with 100 percent open source and free to use without any paywall, and the blog post linked from the README is titled about why the project is FOSS. For a self-hosted service that people would otherwise run from a commercial product, the no-paywall line is the reason to look at the project at all.

The browser is the only client you install

The feature list is short enough to read as a design brief. It automatically scans and indexes your game libraries. You access your library via a web browser and download games directly from there. You share your library with friends and family. It is LAN-friendly, with everything cached locally except for videos. It runs in a container or on any system with a JVM. It has themes, including colourblind support. It is easily expandable with plugins. And it integrates into your SSO solution via OAuth2 or OpenID Connect.

Two of those deserve more than a mention. The absence of a client application is the point of the whole design: a library you reach from a browser is one you can use from a laptop, a phone or a console's browser without installing anything on each. And the LAN-friendly line, with the parenthetical that everything is cached locally except for videos, is a precise statement of the data model. Metadata, cover images and the index live on your machine; the video files themselves are streamed from wherever they already are, which in a game library is usually the same disk.

The SSO integration through OAuth2 and OpenID Connect is what makes the sharing feature usable in an organisation, since a shared library with per-user accounts is a normal requirement and a homegrown password store is not a good answer.

Kotlin, Spring Boot, Vaadin Hilla, PF4J and H2

The technical details section names the stack for v2, and it is worth knowing because each choice tells you something about the trade-offs.

Gameyfin v2 is written in Kotlin, with Spring Boot 3 for the backend, Vaadin Hilla and React for the frontend, PF4J for the plugin system, and H2 for persistence.

The H2 choice is the one with the most operational consequences. An embedded database means the install is a jar or a container with a directory, with no separate database to administer, which fits the self-hosted, appliance-like shape of the project. The trade-off is that the data model is tied to an embedded database, so a large library with a lot of metadata means the whole state lives in one file that has to be backed up and can grow.

The frontend choice of Vaadin Hilla with React is also telling, since it puts the interface in the browser rather than in a separate native client. That is a coherent choice for an application whose whole value is that it works from a browser, and it also means a Java and Kotlin toolchain is a prerequisite for anyone who wants to change the frontend, which is the usual trade in server-rendered applications.

The build is Gradle, with build.gradle.kts, settings.gradle.kts, a gradle wrapper in both gradlew and gradlew.bat form, and gradle.properties at the root.

The plugin system is a first-class part of the repository

Easily expandable with plugins is in the feature list, and the repository layout backs that up with a dedicated plugin-api/ directory alongside a plugins/ directory. That separation, an API module that plugins compile against and a directory of the plugins themselves, is the standard way to make an extension point stable while the application moves around it.

The plugin system is PF4J, which is a general purpose plugin framework for the JVM rather than something built for this project. The advantage is that the loading, discovery and isolation machinery is solved, and the disadvantage is that the plugin contract inherits the framework's shape rather than being designed for a media server.

Other directories in the tree describe the rest of the delivery. There is a docker/ directory, which lines up with the claim that the project runs in a container, a certs/ directory, which suggests that TLS material is mounted rather than baked in, scripts/ for operational tasks, assets/ with the v2 banner and other media, a.run/ directory for the IDE run configurations, and a.sonarlint/ directory for the SonarLint configuration that matches the SonarCloud badges in the README.

The badges themselves are worth reading as a signal. There are ratings for maintainability, reliability and security, plus a vulnerabilities badge.

Where Gameyfin is the wrong tool

The first wrong-tool case is game streaming. It is easy to read the Jellyfin parallel and expect to play a game in the browser the way you watch a film, and the README does not promise that. What it promises is downloading game files from the web UI, and the metadata and cover art are about organising a collection you then play locally. If remote play is the requirement, this is the wrong project.

The second is a collection that lives on someone else's storage. The design assumes your own hardware and your own LAN, and it says so in the features with the LAN-friendly line. A library in cloud object storage, or one shared across a WAN, is a different deployment with different latency and different access control, and nothing in the README addresses it.

The third is a team that needs an organisational contract. There is no mention of roles beyond sharing with friends and family, no multi-tenancy, and no claim of an audit trail. The OAuth2 and OpenID Connect integration gives you authentication, which is the right first building block, but a company that needs per-team libraries, retention policies or a record of who downloaded what would be building those on top.

One more practical caution is the storage. A game library is large, and while the metadata is cached locally, the files themselves are not duplicated by the server, so the network path between the server and the storage is the throughput limit for every download.

AGPL-3.0, version 2.4.0, and a project that keeps moving

The project is licensed under AGPL-3.0, with LICENSE.md at the repository root. For a self-hosted application, AGPL is the licence most likely to make a corporate legal team read the text, and it is worth understanding why before you deploy: the network clause means that offering the modified service to users over a network brings the source obligation with it. Running the unmodified container for your own use is a different question from modifying and serving it, and that distinction is where the reading effort goes.

On versions, the release list shows v2.4.0 on 2026-03-13, v2.3.3 on 2025-12-22 and v2.3.2 on 2025-12-17. The patch releases days apart in December 2025 and a minor release in March 2026 suggest a project in active use with an active user base, which is a good sign for a self-hosted application, where the alternative is often an abandoned container image.

The repository is not archived, and the last push was on 2026-10-15, so the work is current. The documentation and screenshots live at gameyfin.org rather than in the repository, and the README notes the project is supported by YourKit, the makers of the YourKit Java Profiler, which is a sponsorship arrangement rather than a dependency.

Editorial conclusion

Adopt Gameyfin if you have a large, disorganised collection of game files on a machine you control, and you want a browsable, searchable, shareable library with cover art, on a LAN, without a hosted account. Do not adopt it as a game streaming server, since the README describes downloading the game files rather than playing them in the browser, and do not adopt it if you need a plugin ecosystem with a stable API, since the plugin surface is versioned alongside a project still on 2.x. Before you deploy, read the documentation at gameyfin.org for the container image and the scan configuration, and note the AGPL-3.0 licence, which is the one obligation that matters for an organisation modifying and serving the code.

Frequently asked questions

Official sources

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