R3PLAYX is a NetEase Music client that dropped the social features
a music player forked from YesPlayMusic。高颜值的第三方网易云播放器，支持 Windows / macOS / Linux :electron/Docker:
At a glance
- What is it?
- R3PLAYX is a fork of YesPlayMusic, an Electron and React desktop client for NetEase Cloud Music with MV playback, lyrics, private FM and Docker deployment. The fork's own pitch is what it removed as much as what it added, with the feature list stating no social features at all, and the licensing terms are strict enough that any derivative must credit it in the README and the about page.
- Who is it for?
- Adopt R3PLAYX if you want a NetEase Cloud Music client on your own machine rather than the official app or the browser, and you are comfortable with the AGPL terms and the account login it requires. Skip it if you need an official supported client, or if you plan to ship anything derived from it without following the attribution requirement, since the licence asks for a visible credit and a link in the README and the about page.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A fork that removed the social layer and kept the player
R3PLAYX is a music player forked from YesPlayMusic, and the description calls it a third-party NetEase Cloud Music player with support for Windows, macOS and Linux via Electron and Docker.
The feature list is where the fork's identity shows. It is developed with React and Electron, it supports NetEase account login by QR code, phone or email, it supports MV playback, it displays lyrics, it adds a global background, it supports more audio sources, it can be deployed with Docker, and it supports private FM.
And then the line that defines the project: no social features at all.
That is a deliberate subtraction rather than an omission. YesPlayMusic was built as a complete client including the community and social surface, and this fork keeps the parts that are about listening, drops the parts that are about being visible to other listeners, and adds the ones that were missing.
The global background is the visible design change, and the screenshots for the lyrics feature, the audio sources and the global background are given their own entries in the screenshot section, which suggests they are the features the fork wants to be judged on. There is also a struck-through entry for lyrics effects that were removed for performance reasons, which is a small and telling detail about what a music client actually costs to render.
The project is TypeScript, AGPL-3.0 licensed, with the last push on 2026-10-03. The default branch is dev, and the releases are v2.8.0 from 2026-05-13, 2.7.6 from 2025-11-23 and 2.7.5 from 2024-02-18, with the later two tagged under the R3PLAYX name.
The original design credit goes to JACKCRING, and the API source code is attributed to Binaryify/NeteaseCloudMusicApi.
Beta status comes with an instruction to uninstall first
There is a section on the Beta status, and it sets the expectations plainly. R3PLAYX is in the Beta stage, still in development, with features not yet complete. The advice is to uninstall the old version of R3PLAY before installing the new one every time you update, and to open an issue if you hit problems.
Uninstalling before upgrading is unusual advice for a desktop app, and the reason is implied by the rest of the project. The Electron app is packaged and installed, and a partially replaced installation is a common source of confusion when the user data directory and the new binary disagree.
The feature list also carries an invitation at the end, with more features and an expectation of suggestions and involvement.
The community links are in the header, with a Telegram group for development discussion and a developer guide in the project wiki, and a demo site linked alongside the original demo.
The download route is the releases page, and for NixOS there is a separate repository, EndCredits/R3PLAYX-nix, to follow for the install. The link in the install section of the documentation points at the YesPlayMusic releases page rather than the fork's own, which is a leftover from the fork that a new user could stumble over.
The project is AGPL-3.0 licensed, and the terms are spelled out rather than left as a link. The project is for personal study and research only and must not be used for commercial or illegal activity. Any project built on this one must comply with the open source agreement and must state clearly in the project README, the about page inside the application and the introduction website that it is based on this project, with a link to the project's GitHub page.
The API is a separate project, which is where the licensing gets subtle
The most consequential line in the licensing section is that the API source code comes from Binaryify/NeteaseCloudMusicApi, a different project with its own licence.
That matters because the app is not self-contained. The player is the visible part, and the thing that actually talks to the platform is an API server that is a separate codebase. The fork's own repository lists a Dockerfile.server and a Dockerfile.web, so the server is bundled and run as part of the deployment, but the code in it originates elsewhere.
For anyone considering running it, the practical implications are that the API layer has to be present and reachable, that its behaviour is outside the fork's control, and that the platform's own terms of service apply to what is done with an account. The disclaimer in the documentation makes the same point from the user's side. This codebase is for personal online learning and research only and must not be used for commercial purposes. Beyond the matters stipulated in the licence terms, you also know that using this codebase for commercial or other competitive behaviour may carry legal risk. And if you believe this codebase infringes your intellectual property, you are asked to publish a PR, an issue or a DMCA request stating your intention to have the relevant engine or code removed.
The requirement to request removal of the engine or code is a notable one, and it tells you the project expects forks and modifications rather than treating them as infringement.
Docker deployment splits the web frontend from the API server
The compose file is the clearest picture of the architecture, and it is a two-service split with an internal port.
The frontend service builds from Dockerfile.web into an image named xtify-music-web, publishes port 2222 to the host on container port 80, and depends on the backend. The backend builds from Dockerfile.server into xtify-music-server, exposes port 35530 only to the compose network, and the comment says it directly: 35530 stays internal to the compose network and the frontend proxies it.
So the API server is not published to the host at all. The browser talks to the frontend, and the frontend proxies to the server. That is the right arrangement, because the server holds the account session and the token.
The backend environment sets NODE_ENV to production, a DATA_DIR of /app/data, a DATABASE_URL pointing at a SQLite file inside that directory, and an APPLE_MUSIC_TOKEN passed through from the environment with an empty default. A named volume, server-data, is mounted at /app/data, so the database survives a container rebuild.
The healthcheck is a wget spider against the server on 127.0.0.1 on port 35530, every 30 seconds with a 5 second timeout, 3 retries and a 20 second start period. The start period is there because the server needs time to come up before the first check is meaningful.
The .env.example shows the local development shape rather than the container one. It sets the Electron web server port to 42710, the Electron dev NetEase API port to 30001, the Vite app's NetEase API URL to the /netease path, and the database URL to a local file.
The repository also has build-local-docker.sh and build-linux-docker.sh for the two build paths, a .env.example, a Dockerfile.server and Dockerfile.web, a docker/ directory, and a vercel.example.json, which suggests a deployment path beyond the desktop app.
The build stack is Turbo with pnpm workspaces and an Electron wrapper
The package.json shows a modern monorepo setup, and it is worth reading because the scripts tell you how the desktop app and the web build relate.
The package is private, named r3playx, with the product name R3PLAYX, and it requires Node 22.12 or newer with pnpm 8.6.12 as the package manager. The description calls it a nifty third-party NetEase Music player.
The scripts are Turbo-driven. The install script runs the post-install task across all packages in parallel without cache. The build script sets IS_ELECTRON through cross-env-shell and runs the Turbo build, and there is a separate build:web that does not set that flag, which is how the web version is produced without the Electron layer. The package script builds and then runs the packaging step filtered to the desktop package. The dev script sets IS_ELECTRON and runs the Turbo dev task in parallel.
The lint and format scripts are direct rather than Turbo-wrapped, with eslint over the whole tree and prettier writing over the ts, tsx, mjs, js, jsx, md and css files.
The dependency set for the root is small and mostly tooling, which is normal for a workspace root. TypeScript at 5.9.3, the eslint plugins for TypeScript, React and React hooks, prettier with the tailwindcss plugin, tsx for running TypeScript directly, and turbo at 2.10.9 as the task runner and build cache. There is a turbo.json in the repository root and a pnpm-workspace.yaml alongside a pnpm-lock.yaml and a package-lock.json.
One inconsistency in the metadata is worth flagging. The package.json says the license is MIT while the repository licence field and the documentation both say AGPL-3.0, and the documentation is explicit that any derived project must comply with the open source agreement and credit the project.
Where the fork sits against the official client and the browser
The comparison worth making is with the official NetEase app and with simply using the web player.
Against the official app, the argument is the feature set. MV playback, lyrics display, private FM, a global background and more audio sources, with no social feed. Against the browser, the argument is the same plus the fact that a desktop client is a desktop application rather than a tab, and that the Docker path lets you run your own instance of the server rather than relying on somebody's.
Neither comparison is free of caveats, and the project says so. The app is in Beta with features not yet complete, and the update advice is to uninstall the previous version first. The API layer comes from another project. The licence restricts use to personal study and research, and the documentation warns that commercial or competitive use may carry legal risk. And the extra audio sources feature is the one a user should think hardest about, because pulling content from sources the platform does not authorise is exactly the risk the disclaimer is pointing at.
What you get in exchange is a client that is genuinely nice to look at, which the project leads with, and that is not a small thing for a music player.
The developer community is the other side of the story. There is a Telegram group for development discussion, a developer guide in the wiki, an all-contributors-style appreciation section, and a star history chart, which is the vocabulary of a project that expects to be built in the open.
Editorial conclusion
Adopt R3PLAYX if you want a NetEase Cloud Music client on your own machine rather than the official app or the browser, and you are comfortable with the AGPL terms and the account login it requires. Skip it if you need an official supported client, or if you plan to ship anything derived from it without following the attribution requirement, since the licence asks for a visible credit and a link in the README and the about page. Verify first that the version you install matches the current release, that you understand it is in Beta and the maintainer advises uninstalling the old version before installing the new one, and whether the extra audio sources it advertises are acceptable under the service terms of the platform it talks to.
Frequently asked questions
How do I install R3PLAYX?
Download the installer from the project's releases page. For NixOS, the documentation points you to the separate EndCredits/R3PLAYX-nix repository. The project is in Beta and the maintainer advises uninstalling the previous version before installing the new one.
What does R3PLAYX add compared to YesPlayMusic?
It is a fork of YesPlayMusic that keeps the player and drops the social features entirely. It adds a global background, more audio sources, support for private FM, and Docker deployment, alongside MV playback, lyrics display and NetEase account login by QR code, phone or email.
Can I run R3PLAYX with Docker?
Yes, the repository includes a Dockerfile.web, a Dockerfile.server and a docker-compose.yml that builds a frontend on host port 2222 and keeps the API server on port 35530 internal to the compose network, with the frontend proxying to it. The server keeps a SQLite database and an Apple Music token in a named volume at /app/data.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/sherlockouo-music)Was this useful?