GameVault Application: a self-hosted client for DRM-free game libraries

The gap GameVault fills between a file server and a game launcher

A folder of DRM-free installers on a NAS is not a library. There is no cover art, no version tracking, no way for a second person to see what is available without browsing directories. GameVault's stated goal is to close that gap: the README describes it as a self-hosted, source-available alternative to the big storefronts, and explicitly frames it as a way for you and your friends to enjoy DRM-free games stored on your file server in an organized way. The client application, which is what this repository contains, is the part users actually interact with. The README is direct that this is only one half of the system, and the server side lives elsewhere. The intended audience is narrow and identifiable: people who already own legally obtained DRM-free games, run their own storage, and want a shared front end over it. The legal disclaimer repeats the boundary twice, saying GameVault only means games obtained legally and that piracy is neither endorsed nor supported.

What the repository actually contains versus what the README describes

The repository is a C# codebase, and the README labels it the client application. Everything else about the architecture has to be inferred from that label. There is no setup guide, no configuration reference, no environment variable list, and no API description in the supplied material. The README points to gamevau.lt for guides and information, which means the operational documentation is deliberately kept off the repository. That is a legitimate choice for a project that wants one canonical source of truth, but it makes the repository a poor starting point for evaluation. A reader arriving at the GitHub page learns what the product is and how to donate, and learns nothing about how the client discovers a server, how it authenticates, or what it expects to find on disk. Treat the repository as the code, and the website as the manual.

The CC BY-NC-SA 4.0 licence is the first decision, not the last

The README states the licence plainly and then adds a sentence that most projects would bury: this project is not and never was open-source, with a link to a blog post explaining why. The licence identifier is CC BY-NC-SA 4.0. Three of those clauses matter operationally. NonCommercial means you cannot use the work commercially, which rules out anything resembling a paid service built on it. ShareAlike means adaptations have to carry the same licence, so a fork cannot be relicensed under MIT or Apache-2.0. Attribution means you must credit the original. The repository metadata reports the licence as NOASSERTION, which is GitHub's way of saying it could not map the file to a known identifier, so anyone doing automated licence scanning will get an unclear result and should read the LICENSE file directly rather than trust the badge. None of this is legal advice; if the licence terms affect a business decision, that is a question for a lawyer, not a README.

Getting it running: what the material supports and what it does not

The honest answer is that this repository does not tell you how to run it. There is no install command, no build command, no config file example, and no list of required services in the supplied README. What the README does give is a single pointer: the official website at gamevau.lt hosts the guides. The homepage field in the repository metadata points to the same domain. So the sequence a new user has to follow is: read the website, find the server component and stand it up first, then return to this repository for the client. Anyone expecting a docker-compose file or a dotnet run invocation in the README will not find one. That is a documentation gap rather than a technical one, and it is worth knowing before you clone, because the client alone cannot do anything without a server to talk to.

Release cadence and the cost of keeping a client in sync

The release list shows 1.17.3, 1.17.4 and 1.17.5 landing within roughly five weeks in late 2025, with the most recent push to the default branch dated 2026-08-25. Three patch releases in a month is a normal maintenance rhythm for a client that has to stay compatible with a server, but it also tells you something about operating cost: if the client and server are versioned in step, an upgrade is not a single action. You are updating the client on every machine that plays games, and potentially the server too, and a mismatch between them is the obvious failure mode. The README gives no compatibility matrix, no minimum server version, and no upgrade notes, so the only way to judge that risk is to watch the release history and read the changelogs on the website. For a household with two machines this is trivial. For a group spread across several households, it is a recurring chore with no documented procedure.

Where a plain file share or a general launcher does the job instead

The alternative depends on what you actually want. If the goal is simply to let a few people download installers from your storage, a read-only SMB or NFS share, or a small static file index, does the same job with no server component, no client to install, and no licence question. GameVault's difference is the catalogue layer: metadata, artwork, and a shared view of what exists, which a file share does not provide and does not try to. If the goal is launching games you already have installed locally, a general-purpose launcher is a closer fit, because it works with installed titles rather than installers sitting on a server. The trade-off is explicit. GameVault buys you an organized, browsable, multi-user front end over remote DRM-free files, and it charges for that with a server to run, a client to keep updated, and a non-commercial licence. Pick it when the catalogue is the point. Skip it when the files are the point.

Who should adopt it, who should not, and what to check first

Adopt it if you already hold legally obtained DRM-free games on your own storage, you want a shared, organized front end for a small circle of friends or family, and nobody is charging anyone for access. The non-commercial clause is not a formality here; it is the constraint that decides most borderline cases. Do not adopt it if you need a permissively licensed codebase you can relicense, embed in a product, or offer as a paid service. Do not adopt it if you want the server and the client documented in one place, because this repository is only the client and the README is a landing page. Before you commit, three things are worth verifying: read the licence blog post linked from the README so you understand why the project rejects the open-source label, confirm on gamevau.lt whether the server is a separate repository with its own release cycle, and check the changelogs for 1.17.3 through 1.17.5 to see whether client and server versions must move together. If those three answers are acceptable, the project does what it says. If any of them is not, a file share is cheaper.

Editorial conclusion

Adopt GameVault if you already keep legally obtained DRM-free installers on a file server, you want a shared catalogue for a small group of friends or family, and nobody in that group is paying for access, because the CC BY-NC-SA 4.0 licence rules out commercial use. Do not adopt it if you need a permissively licensed codebase you can modify and redistribute under your own terms, or if you expect the repository to contain the server and setup instructions. Before committing, read the licence blog post linked from the README, confirm whether the server component is a separate repository, and check the release history for how often the client ships breaking changes.

Official sources

1. Issues
2. Phalcode/gamevault-app on GitHub
3. Project website
4. README
5. Releases