# Vnite review: game collection management, playtime tracking, and cloud sync > Vnite is an Electron and React desktop application for cataloging games, recording play sessions, and synchronizing records and saves across devices. It suits players with mixed local libraries, especially visual novels and folder-based games. **ximu3/vnite** — A unified platform to organize your game collection, track gameplay, with real-time cloud sync across devices and detailed gameplay reports. - Repository: https://github.com/ximu3/vnite - Website: https://vnite.ximu.dev/ - Stars: 1,367 · Forks: 52 - Language: TypeScript - License: GPL-3.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/ximu3-vnite ## What Vnite centralizes beyond a store launcher Vnite addresses players whose game collection crosses launchers, stores, local folders, emulators, and visual-novel sites. A platform launcher generally manages games that its store can recognize. Vnite instead presents a broader catalog built around configurable scanners and metadata sources. Its README lists Steam, IGDB, Bangumi, VNDB, YMGal, DLsite, and Erogamescape among the available sources. The practical target is a player who wants one interface for game records, saves, settings, and play sessions across several computers. Vnite can import a Steam library while preserving recorded game time, but it is not limited to Steam entries. Local folders can be scanned, categorized by developer or tags, and enriched with transformed metadata. The application can launch files, links, or scripts, giving it a different role from a read-only collection catalog. This focus is relevant to visual-novel and galgame collections. Releases may be organized outside a commercial launcher, and descriptive records may come from specialist databases. Vnite can record sessions against individual files or folders. That may represent a local game more accurately than a store-level record, although the README does not document automatic session-detection rules for every title. Some launch targets and scanner patterns will therefore need configuration. Vnite is aimed at people who actively maintain a sizable collection. A player with one game and no interest in reports, scanners, plugins, or cross-device state may get little value from an additional desktop application. ## How Vnite records, transforms, and synchronizes game data The repository identifies an Electron application with a React and TypeScript user interface. The `package.json` names `electron-vite` as the development and preview framework. This structure separates the desktop shell from the rendered interface rather than implementing the collection as a browser-only web service. Vnite's library flow begins with configurable scanners. Each scanner can define its folder structure and metadata source. Vnite then provides a metadata transformer with regular-expression modification, replacement, merging, and exclusion. These controls address a common problem in mixed collections: records from different services may disagree about titles, developers, artwork, or other fields. Filters can also use custom metadata rather than only built-in categories. Playtime is captured through session-based timers. A timer can be associated with an individual file or a folder, allowing the recording scope to match the configured launch entry. Vnite also supports launching through files, links, and scripts. The README mentions integrations for LE region switching, Magpie scaling, and emulator launching. It does not document the full setup or failure behavior of each integration, so those functions should be evaluated individually. Cloud synchronization is described as real-time and covers game records, saves, and settings across devices. `.env.example` contains `VITE_COUCHDB_SERVER_URL` together with Authentik-related variables, showing that the synchronization configuration expects external services. The README does not document the CouchDB deployment process, account creation, conflict handling, offline behavior, or restore procedure. The same file lists credentials for several metadata providers. Cloud sync should therefore be treated as configured infrastructure rather than an automatic hosted service bundled with every installation. ## Reports, filters, plugins, and launch automation Vnite uses recorded sessions as historical data. The README promises annual, monthly, and weekly reports intended to show a player's gaming history. It does not define report calculations, timezone handling, idle detection, or overlapping-session rules. Users who depend on exact statistics should inspect those settings and report output rather than assume a particular methodology. Organization extends beyond a flat launcher list. The README documents categorization by developer and tags, custom metadata fields, and configurable filters. This helps when a collection contains commercial releases, visual novels, regional editions, patches, and folder-based installations. The same flexibility creates configuration work. Scanner folder patterns may differ between titles, while metadata rules can need separate treatment for records imported from different providers. Plugins and a built-in plugin marketplace extend the application beyond the documented core. The README does not state plugin permissions, compatibility guarantees, or update behavior. That omission matters because plugins can add another source of upgrade and troubleshooting work. Launch configuration is another area where control replaces convenience. Files, links, and scripts can represent executables, launchers, emulators, or helper programs, but all can fail after a file moves or an external tool changes. Vnite can retain the catalog entry and timer configuration even when a configured target no longer works. The project does not claim that it can diagnose or recover a game from an invalid launch command. Compared with relying on a store launcher, Vnite provides more control over a mixed library but assigns more discovery and launch responsibility to the user. ## Building Vnite from the repository The README documents a development setup rather than a complete installation procedure for each packaged platform. It requires Node.js 20.19 or newer within the 20.x line, or Node.js 22.12 or newer. `package.json` pins pnpm to `pnpm@10.34.5`. The application and `native` package share a workspace with a root `pnpm-lock.yaml`. On Windows, building the native module also requires the Rust MSVC toolchain and Visual Studio C++ Build Tools with the Windows SDK. Run the documented commands from the repository root. The first installs locked dependencies and applies patches from `patches/`. The second builds the native workspace package. The third starts the Electron development environment. ```bash pnpm install --frozen-lockfile pnpm build:native pnpm dev ``` A source developer should expect the Electron development application to start after the native package has been built. The README also lists commands for type checking, compilation, and installer creation: ```bash pnpm typecheck pnpm build pnpm build:win ``` `pnpm typecheck` checks the Node and web TypeScript configurations. `pnpm build` automatically builds the native module before compiling with `electron-vite`. `pnpm build:win` creates the Windows installer. The repository also defines `build:mac`, `build:linux`, and `build:unpack`, but the README only explains the Windows installer command directly. Separate prerequisites for those targets are not documented. For API-backed metadata or cloud services, use `.env.example` as the configuration reference. It names `VITE_IGDB_API_ID`, `VITE_IGDB_API_KEY`, `VITE_STEAM_API_KEY`, `VITE_STEAMGRIDDB_API_KEY`, `VITE_BANGUMI_API_KEY`, `VITE_AUTHENTIK_SERVER_URL`, `VITE_AUTHENTIK_CLIENT_ID`, `VITE_AUTHENTIK_CLIENT_SECRET`, and `VITE_COUCHDB_SERVER_URL`. The README does not say which keys are mandatory, so users should configure only the services needed for their setup rather than treat every example value as required. ## Operational limits and synchronization boundaries Vnite combines a desktop application, a native workspace package, external metadata APIs, plugins, and cloud configuration. A source build is not limited to React dependencies. Node.js and pnpm versions affect setup, while Windows source builds require native compilation tools. The `postinstall` script invokes `electron-builder install-app-deps`, so dependency installation also prepares native application dependencies. The largest documentation gap concerns cloud synchronization. The README claims real-time synchronization of records, saves, and settings, and `.env.example` exposes Authentik and CouchDB variables. The repository files do not explain CouchDB deployment, the authentication flow, conflict resolution, offline behavior, account creation, data export, or backup retention. Vnite's separation of program data from the application can assist local backup, but the README does not define a complete migration or disaster-recovery procedure. Game execution is another boundary. Vnite can launch files, links, and scripts, but it cannot be assumed to understand the internal state of every game. Emulator integration, region switching, scaling, and session timing depend on valid paths and correct behavior from external software. The README gives no troubleshooting procedure for missing executables, failed scripts, or inaccurate timers. Customization brings a related constraint. Scanner patterns and transformations can accurately represent an organized library, but inconsistent directory names may require many rules. The README does not document a global validation or automatic repair workflow. Before importing an entire collection, test representative games covering local folders, Steam imports, emulators, and any saves intended for synchronization. ## Vnite versus a platform launcher A platform launcher is the clearest alternative for a collection confined to one service. Vnite's documented difference is that it can import a Steam library while preserving game time, then add scanners and data sources for games outside that store. Vnite is more useful when the collection is heterogeneous. It can associate visual-novel folders with metadata from VNDB, Bangumi, YMGal, DLsite, or Erogamescape. It can also launch scripts and emulator targets. A native platform launcher remains simpler when every title is installed, launched, and tracked by the same service. It avoids custom scanner patterns, launch scripts, field transformations, and optional API credentials. The trade-off is ownership of configuration. Vnite gives users more control over local records and folder scanning, but they must define how games are discovered, categorized, and launched. Its cloud synchronization may help across personal devices, yet the README does not establish that it replaces platform services such as store updates, entitlement management, or game-specific cloud saves. Vnite should be selected for mixed-library organization and local control, not merely for a different launcher interface. ## Maintenance, releases, and GPL-3.0 implications The repository is not archived, and the last push was on 2026-10-11. Recent releases include v4.14.0 on 2026-10-11, v4.13.0 on 2026-09-07, and v4.12.0 on 2026-07-16. The visible release history is recent, although the README does not publish a support policy, operating-system compatibility matrix, migration guide, or long-term support schedule. Upgrade work may include local data, scanners, metadata transformations, environment variables, and plugins. The repository's separation of program and data can simplify backup and customization, but it also means that an upgrade should not be judged solely by the installer. The pinned pnpm version and `pnpm-lock.yaml` provide an explicit workspace setup. Patches under `patches/` are applied during installation, so changing dependencies or reviewing those patches can affect local builds. Vnite uses the GPL-3.0 license. Redistribution and modification are governed by that license's terms, including applicable source-availability and license-notice obligations. This is not legal advice. Anyone distributing a modified build should review the repository `LICENSE` and comply with the GPL-3.0 text rather than assuming that the Electron application can be redistributed under unrelated terms. ## Conclusion Vnite fits players who want local game folders, saves, metadata, and play sessions in one desktop catalog, especially when platform launchers do not cover their collection. It is a poor fit for users who only need a single store's native library or cannot maintain a source build with Node.js, pnpm, Electron, and a native workspace. Before adopting it, verify that its data sources match the collection, that cloud synchronization meets the required authentication and privacy conditions, and that every launch preset points to a working executable or script. ## FAQ ### What runtime versions does Vnite require for development? The README requires Node.js 20.19 or newer within the 20.x line, or Node.js 22.12 or newer. The project also pins pnpm to `pnpm@10.34.5` in `package.json`. ### Can Vnite manage games outside Steam? Yes. Vnite supports custom folder scanners and metadata sources including IGDB, Bangumi, VNDB, YMGal, DLsite, and Erogamescape. Launch presets can use files, links, or scripts. ### Does Vnite include cloud synchronization and gameplay reports? The README describes real-time synchronization for game records, saves, and settings, along with annual, monthly, and weekly reports. It does not document synchronization conflict handling, offline behavior, or the complete CouchDB and Authentik setup. ## Sources - [License: GPL-3.0](https://github.com/ximu3/vnite/blob/main/LICENSE) - [Project website](https://vnite.ximu.dev/) - [README](https://github.com/ximu3/vnite/blob/main/README.md) - [Releases](https://github.com/ximu3/vnite/releases) - [ximu3/vnite on GitHub](https://github.com/ximu3/vnite) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ximu3-vnite