Playnite: a Windows game library manager for Steam, Epic, GOG and emulators

The problem Playnite solves for multi-store Windows players

A player with games on Steam, Epic, GOG, EA App and Battle.net has five launchers, five account states and no single list of what is installed. Playnite is built for that person. The README describes it as "an open source video game library manager and launcher with support for 3rd party libraries like Steam, Epic, GOG, EA App, Battle.net and others", with emulation support, "providing one unified interface for your games". The target user is on Windows and already owns games elsewhere. Playnite does not sell games and does not replace the stores. It reads them and presents one front end. The README also points to an add-ons page for the full list of supported libraries, which means the set of integrations is not frozen in the README itself and is maintained separately.

How Playnite imports libraries, stores data and launches games

Playnite is a C# and WPF desktop application. The repository layout shows source/, tests/, references/, build/ and appveyor.yml at the top level, so the build is a standard .NET solution with a CI configuration checked in. Library integrations are plugins. The README states that account connection "depends on how a library plugin is implemented, but is usually done via official login web forms and only the web session cookies or tokens are stored". That is the data flow: the user authenticates against the store in a web view, the plugin keeps the session token, and the plugin then enumerates that account's games into the local Playnite database. Nothing about the library is uploaded. The README is explicit that "Playnite itself doesn't store any user information" and that "all game library data is stored locally on your PC". Extension points are broader than library plugins: the README lists "plugins (written in .NET languages), PowerShell scripts and user interface themes". That last point matters for the launcher model. A theme can change the entire interface, and a PowerShell script can add behaviour without compiling a .NET assembly, which lowers the barrier for small customizations compared with a plugin-only design.

Installing Playnite on Windows and running a first import

The README does not document a package manager install. It says to "Grab the latest installer or portable package from the download page", at playnite.link/download.html, and that "Playnite will automatically notify you about a new version upon release". Requirements are stated as Windows 10 or 11. The portable package is the option to note if you do not want a machine-wide install. There is no command line install step in the README, so the closest thing to a reproducible instruction is the download URL itself:

https://playnite.link/download.html

Open that address in a browser and take either the installer or the portable package. After first launch, the work happens in the library import step. The README does not print the exact menu labels, so treat the following as the shape of the task rather than a quoted procedure: open the library import or add-ons area, pick the store you want, complete the login in the web form that the plugin opens, and let the import finish. What you should see afterwards is your games from that store in the local Playnite library. If you want to extend something instead, the README says extensions can be written as PowerShell scripts, and it points to the extension tutorials at api.playnite.link/docs for how those are loaded and run:

https://api.playnite.link/docs/tutorials/index.html

That page is where the README sends anyone writing a script, theme or plugin, so read it before assuming a file path or a loading convention.

Where Playnite stops: platform, emulation and the version 11 rewrite

The hard boundary is the operating system. The README lists Windows 10 or 11 under Requirements and nothing else. There is no Linux, macOS, Android or Steam Deck build described anywhere in the README, which is why searches for Playnite on those platforms have no documented answer here. If your setup is not Windows, Playnite is the wrong tool.

The second constraint is development posture. The README states that "Pull requests are generally on pause because majority of code base is being rewritten for Playnite 11", and that only smaller, safe changes for version 10 might get accepted, depending on what they are and whether they come with test coverage. The rewrite is happening in a private repository until beta, after which the code will be released in this repository under the same license. There is no published list of planned changes for version 11. For anyone evaluating Playnite as a base for their own plugin or fork, that is the real risk: the surface you build against today is being replaced, and the project has not said what the replacement looks like. The last push to the repository was on 2026-09-13, and releases 10.58, 10.59 and 10.60 landed between 2026-09-10 and 2026-09-11.

Playnite compared with LaunchBox

LaunchBox is the comparison that comes up most often, and the difference is in where each tool puts its weight. Playnite's README leads with third party store libraries: Steam, Epic, GOG, EA App, Battle.net and others, with emulation described as an included capability rather than the headline. The extension model is plugins in .NET languages, PowerShell scripts and full UI themes. LaunchBox is built around emulation and front-end presentation first, with store library handling as one part of a broader package that also has a paid tier. The practical consequence: if your library is mostly store-bought PC games and you want a free MIT-licensed manager you can theme and script, Playnite is the closer fit. If emulation organization is the primary job and you want a mature emulator-focused front end with commercial support options, LaunchBox is the one to look at. Neither choice is settled by feature lists alone; it depends on which half of your library is larger.

Playnite licence, releases and the cost of staying current

Playnite is MIT licensed, which is permissive: you can read, modify and redistribute the code, and a fork is legally straightforward as long as the licence terms are kept. The README also commits that the version 11 rewrite will be released "under the same license as current version 10 release", so the licence is not expected to change across the rewrite. That is a meaningful statement for anyone planning to build on it. This is a description of the licence text, not legal advice; read LICENSE.md for the actual terms.

Upgrade cost is low for end users because the README says Playnite notifies you about new versions on release, and the release cadence visible in the repository is fast: three releases in two days in September 2026. The cost is higher for contributors. The README's contribution rules are specific and enforced in review: private fields and properties in camelCase without underscore, all methods in PascalCase, four spaces instead of tabs, a blank line after a closing brace before the next expression, and curly braces around every if, for, foreach and while body. Tests live in the tests/ directory, and the README ties acceptance of version 10 changes to test coverage, so a patch without tests is likely to be declined regardless of how small it is.

Editorial conclusion

Adopt Playnite if you run Windows 10 or 11, own games across several stores, and want one library view plus emulator entries. Do not adopt it if you need Linux, macOS, Android or Steam Deck support, since the README lists Windows 10 or 11 as the requirement and the project documents no other platform. Before installing, verify the download page at playnite.link/download.html is the source you trust, and check the api.playnite.link documentation for the current known issues list.

Frequently asked questions

Official sources

1. JosefNemec/Playnite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases