ReinaManager and the case for a game library that keeps its own data

A desktop app with a Rust core and a web frontend

The stack list is short and it tells you the shape of the project before any feature does.

Tauri 2.0 is the shell, React is the frontend, Material UI supplies the components, and UnoCSS handles the utility styling. Zustand holds client state and TanStack Query handles server state. The data layer is SQLite with Rust and SeaORM as the ORM.

That combination is a modern choice rather than an obvious one. A Tauri application ships a web frontend in a native window with a Rust process behind it, so the app is small to install compared with an Electron equivalent, and the SQLite database and SeaORM give structured query and a real schema rather than a pile of JSON files.

The frontend dependency list in package.json shows how much of the interface is off-the-shelf. Material UI and its icon set at 7.3.11, the charts add-on from Material UI for the statistics screens, the drag and drop kit from dnd-kit with core, sortable and utilities, fuse.js for fuzzy search, i18next with a browser language detector, marked and html-react-parser for rendering text, and notistack for notifications. The Tauri side pulls the api package plus plugins for autostart, dialog, http, shell, store, updater and window state.

The updater and autostart plugins are worth noting, because they tell you the app is meant to live on your desktop permanently rather than be run once.

The multi-source merge is the feature everything else builds on

The first item in the feature list is multi-source data integration, described as fetching and merging game metadata from multiple source APIs.

That is the hard part of a game library manager and the reason the project has the shape it does. No single database has every title, and no single database has every field. Bangumi, VNDB, Ymgal, Kungal, Hikarinagi and Shionlib are all named in the acknowledgements as providing public APIs, data and resources, and the project thanks them for it. The acknowledgements are not decorative here, they are a dependency list for the data layer.

The search feature follows from that, since searching across merged records means matching on titles, aliases and custom names rather than a single canonical title. The filter and sort feature then works across multiple dimensions, such as source, status and tags.

Because a merged record can disagree with itself, the customisation feature is more than cosmetics. You can customize game covers, names, descriptions and tags, which is how you resolve a conflict in favour of the field you care about, and how you keep local notes on a title without fighting the source databases.

The batch operations feature, bulk import and bulk metadata updates from APIs, is the same idea at scale, and the todo list shows that bulk import from folders is already done.

Play time tracking, savedata backup and the two Windows integrations

Three features are about the games on your disk rather than about the catalogue.

Play time tracking is automatic session recording with detailed play time statistics and history. Savedata backup supports both manual and automatic backup of game savedata. These two are related, because savedata is the thing you cannot recreate and play time is the thing you want to accumulate, and the statistics screenshots in the repository show what the tracking produces.

The system integration is auto-start on boot plus minimise to system tray, which for a library manager is the difference between a launcher you open deliberately and a service that is always there.

The tool integration is more specific and more interesting. Games can be launched with Locale Emulator locale switching, which matters because a Japanese-only visual novel running on a system with a Western locale often shows garbled text, and with Magpie upscaling, which is a display scaling tool for putting a small game window on a large monitor at a higher resolution.

Both of those are Windows-first tools, and that is a real constraint rather than a missing feature. The todo list does record basic support for the Linux platform as done, but the two integrations that make launching pleasant are tied to Windows software, and on Linux you get the catalogue and the tracking without them.

Groups, categories and drag and drop for a collection

Collection management is the other half of the app, and it is where the drag and drop dependency earns its place.

You organise the library with groups and categories, with support for drag and drop sorting. That is a different axis from the source, status and tag filters, and the distinction matters: filters are how you look at the library, groups are how you own it. A filter can be applied and removed, a group is a thing you built and maintain.

The play time statistics and history feature is what connects the two halves. If a group is a project, a series you are working through, or a set you want to finish, then knowing how long each entry has taken is the number that tells you whether the grouping is working. The statistics overview and stats screenshots suggest several views on that.

The NSFW filter is a simple toggle that hides or covers that content, which is a practical need for anyone who shares a screen or a library screenshot, and the multi-language support is described as complete i18n, with Simplified Chinese, Traditional Chinese, English, Japanese and more. The project ships separate documentation files for Chinese, Traditional Chinese and Japanese, and the package scripts include i18next-cli commands for status, sync, extract and checking that translation defaults are present, with a script that can write the missing ones.

Migration is handled by a separate tool, not by the app

If you already keep your library somewhere else, the project does not ask you to import it by hand.

A separate tool, reina_migrator, is provided for migrating data from other galgame and visual novel managers into ReinaManager. It transfers the game library, play time records and other data from the supported managers. Currently it supports WhiteCloud v0.4.0 data migration, and Playnite 10 data migration, where the Playnite path requires a companion plugin called the Reina Exporter.

That arrangement is worth noticing. The migrator is a separate repository with its own release cycle, which keeps the main application from growing an import module for every manager someone might have used, and it means the importers can be updated without shipping a new build of the app.

The alternative to migrating is doing it yourself through the batch import, which the todo list marks as done for importing games from folders. So there are two routes: a dedicated tool for known source formats, and the app's own folder import for anything else.

One project is still open in the todo list, beautify individual pages, and the status badge on the project page says beta. The badges also show the project as active, and the release history confirms it: v0.31.0 on 2026-10-01, v0.31.1 on 2026-10-02 and v0.32.0 on 2026-10-15.

Building it locally, and the AGPL decision

The contribution guide gives the build steps, and they are the standard Tauri setup.

You need Node.js and Rust installed, then clone the repository:

   git clone https://github.com/huoshen80/ReinaManager.git
   cd ReinaManager

The dependencies are installed with pnpm:

   pnpm install

The development server is started with:

   pnpm tauri dev

And a production build is:

   pnpm tauri build

The package scripts mirror that structure, with dev running vite, build running tsc -b and then vite build, and tauri as a pass-through to the Tauri CLI. The check script runs format, lint and typecheck in sequence, with Biome doing both the formatting and the linting, and there is a separate typecheck script that runs tsc -b with noEmit.

The changelog is generated rather than written by hand. The changelog script runs git-cliff to bump the version and prepend unreleased entries to CHANGELOG.md, and there is a cliff.toml at the root configuring it, with separate scripts to regenerate the whole file or view the latest.

The licence is AGPL-3.0, and that choice deserves a sentence of care rather than a footnote. AGPL is the strongest of the copyleft licences for network and desktop applications, and for a locally run personal tool that is usually the right trade for the author. For anybody who intends to modify and redistribute it, the obligations travel with the code, and that is a question for your own review rather than a conclusion to draw from a licence identifier. The homepage is reina.huoshen80.top, and the last push was on 2026-10-20.

Editorial conclusion

ReinaManager suits a player with a large visual novel library spread across several databases who wants one local catalogue with their own tags, covers and play time records, since the multi-source merge and the local editing of metadata are the parts it does well. It does not suit someone who only wants a launcher, because metadata editing, batching and collection management are the emphasis, and it does not suit a project that needs to redistribute it without accepting AGPL-3.0 obligations. Before you adopt it, check whether the data sources you rely on still answer, since the whole model depends on public APIs, and note that it is marked beta with the last push on 2026-10-20 and the newest release v0.32.0 dated 2026-10-15.

Frequently asked questions

Official sources

1. huoshen80/ReinaManager on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases