NeriPlayer is a GPL-3.0 Android audio player. Its only server-side component is an optional Listen Together backend that runs on Cloudflare Workers. This source and documentation review of release ac7bdea4.09031001 (2026-09-03) finds it reasonable for developer and self-hosting experiments that pin versions and keep backups, but not for business-critical use. The maintainers describe recent releases as large, lightly tested refactors, and a prior release states that downgrading across its database migration crashes the app.

what this review covers, and what it cannot promise

This is a source and documentation review. It reads the NeriPlayer repository, its README, the release notes for the reviewed snapshot and the four releases before it, and a sample of open issues. It did not install, build, deploy, or benchmark NeriPlayer, and it did not run the Listen Together worker on Cloudflare. Every capability below comes from the maintainers or appears in the release notes and issue tracker; per-device runtime stability remains unverified.

the buyer problem: self-hosting the companion backend of a fast-moving android app

If you are a founder or operations lead, be honest about whether this problem is yours. NeriPlayer is a consumer music player, and the only piece you might run on a server is its optional Listen Together backend. The realistic reader is a developer or operator who wants a private, self-hosted listen-together room for a small group, or who is evaluating the app and its GPL-3.0 Kotlin and Compose codebase as a base for their own build. The decision is narrow: run it yourself with maintenance discipline, or leave it alone. Many small businesses have no reason to be in this decision at all.

what neriplayer actually is, and where the server part lives

NeriPlayer is a native Android app with a minimum supported version of Android 9 (API 28), built with Jetpack Compose and Media3. According to the repository, it combines multi-source streaming across NetEase Cloud Music, Bilibili, and YouTube Music with local playback, local imports, lyrics, and optional sync of playlists, favorites, recent plays, and playback statistics to GitHub or WebDAV. The README states that it does not host a public cloud library, that online playback depends on the user’s own third-party platform accounts, and that platform rules still apply.

The server-side surface is the Listen Together feature. The repository lists an embedded submodule, np-submodule/NeriPlayer-LTW, and points to a public deployment template at TheSmallHanCat/NeriPlayer-LTW. The maintainers describe that backend as running on Cloudflare Workers with Durable Objects and streaming room state over WebSocket, with a custom server address you can configure in the app. Everything else, including metadata sync, secrets, and downloads, runs on the device or against endpoints you already control.

use cases where self-hosting is justified

A self-hosted setup is worth the effort under specific conditions, not as a default. Reasonable cases include:

• A developer or small group that wants a private listen-together room and is comfortable owning a Cloudflare Workers deployment and its usage quota.
• A team evaluating a GPL-3.0 Kotlin, Compose, and Media3 codebase as a reference or starting point for its own Android media app.
• A self-hoster who already runs GitHub or WebDAV endpoints and wants device-local playlists and statistics backed up to infrastructure they control.
• Someone who mainly needs offline and local playback, where the online sources and the self-hosted room are optional extras.

Outside those cases, the self-hosted label carries more weight than the product does. NeriPlayer does not offer a public cloud library, and the README is explicit that online playback depends on your own third-party accounts and stays subject to those platforms’ rules.

maintenance signals you cannot ignore

The maintainers’ own release notes are the strongest signal here, and they should shape your upgrade policy more than the star count does.

• The README labels the project as active development. The reviewed build is one of several releases shipped within roughly a month, with tagged releases across August and September 2026.
• The ac7bdea4.09031001 notes describe the previous five versions as very large changes that were mostly invisible refactors, say they are still not fully tested, and ask users to report problems.
• Two earlier releases, acf46add.08151202 and fbbcd39e.08142226, record a breaking change: the database moved from version 14 to 15, and downgrading will cause the application to crash.
• The reviewed notes state that data persistence has migrated to a database and carry a backup warning: the sync data model changed, 100% backward compatibility is not guaranteed, and users should back up before updating.
• The same notes still describe USB exclusive playback and Listen Together as experimental features that remain in testing.

None of this is unusual for a fast-moving open-source consumer app. It is, however, exactly the profile that makes unplanned upgrades risky, which is why version pinning and a tested backup and restore path are prerequisites rather than nice-to-haves.

deployment and upgrade concerns

If you decide to run this, treat it as two systems with different owners. The Android app is something you install and update per device; the Listen Together worker is infrastructure you deploy and pay for.

• Version pinning. Version names follow a git short hash plus a timestamp, for example ac7bdea4.09031001, so a specific build is easy to identify. Pin a known good APK and a known good worker revision instead of always taking the newest artifact.
• Backups before upgrades. The release notes explicitly ask users to back up before updating and warn that both the database and the sync model have changed. Test a restore, not just a backup.
• Downgrade risk. A prior release states that reverting across the database migration crashes the app. Plan rollback as a forward fix or a clean reinstall with restored data, not as a simple APK downgrade.
• Server ownership. The Listen Together backend runs on Cloudflare Workers with Durable Objects and pushes room state over WebSocket. You own the Cloudflare account, the quota, and the custom server address configured in the app.
• Different upgrade pace. The app ships far more often than many teams want to redeploy a worker. Decide which side you update, on what schedule, and who owns compatibility between them.
• Build variants. The default release builds only arm64-v8a; other ABIs need an explicit build flag. If your device fleet mixes architectures, confirm the artifact you need exists for the version you pin.

limitations and open issues

An open issue tracker is not a verdict on quality by itself, but it shows where you should expect to spend time. The repository showed 120 open issues at review time. Examples that matter to operations:

• Issue #257 reports YouTube Music failing to play even when login, covers, metadata, and recommendations work.
• Issue #247 reports USB exclusive playback failing with a specific USB DAC.
• Issue #67 reports a brief loud volume burst when resuming after the app is exited and background is cleared.
• Issue #376 reports notification media-player lyrics not updating on an Android 17 device.

Documented boundaries to plan around:

• GitHub and WebDAV sync store metadata on remote endpoints you control, and the README states this is not end-to-end encrypted; a full configuration export can contain authorization data and should not be shared.
• Downloads use an in-app client with default concurrency of 6 and a maximum of 8, plus resume support, rather than the system download manager, and there is no cross-device download sync.
• QQ Music is used only for playback-page metadata and lyric completion; there is no QQ login or playback.
• The README frames the project for learning and research, requires you to comply with third-party platform rules, and states that neither the project nor its maintainers accept sponsorship, donation, or commercial funding. That last point matters if you were expecting to buy support or influence a roadmap.

alternatives and evaluation questions

Before committing, answer these against your own constraints:

• Do you actually need the server component, or is local playback enough? If local playback is enough, you avoid the worker entirely.
• Who owns the Cloudflare account, the quota, and the incident when a room stops syncing?
• Can you pin a version, test an upgrade on a staging device, and restore from backup if it fails?
• Which Android versions and specific models matter to you, and do the open device-specific issues overlap with them?
• Is unencrypted remote metadata acceptable for your data? If not, you need a different sync design.
• If you need a supported commercial system with a vendor behind it, a maintained commercial player or media platform is the honest alternative, because NeriPlayer is not sold with a support contract.

who should consider neriplayer, and who should not

Consider NeriPlayer if you are a developer or self-hoster who wants a private listen-together room, local-first playback, and metadata sync to infrastructure you control, and you are willing to pin versions, back up before every upgrade, and take on the maintenance yourself.

Do not adopt it as a business-critical system if you need vendor-backed support, predictable release compatibility, end-to-end encryption, or guaranteed long-term maintenance. Do not adopt it for content distribution that ignores platform rules; the README explicitly says it is not a tool for bypassing protections or redistributing media.

verdict

NeriPlayer is a credible, actively developed GPL-3.0 Android player with a genuinely small server footprint, and its self-hosting story is limited to the Listen Together backend. NeriPlayer self-hosting is therefore a maintenance decision as much as a deployment one. The upgrade path is the deciding factor: the maintainers describe recent releases as large, lightly tested refactors, warn that downgrading across a database migration crashes the app, and ask users to back up before updating.

That is manageable for a hobbyist or a developer who understands the trade-off, and it is not a foundation for a business system that needs predictable, supported change. Reasonable verdict: usable for experimentation and small private self-hosting with strict version pinning, backups, and a tested rollback routine; avoid it as a production business dependency unless you own the maintenance.

sources

• cwuom/NeriPlayer repository for the README, platform status, and documented limits.
• Release NeriPlayer-ac7bdea4.09031001 for the reviewed snapshot, backup warning, and known issues.
• NeriPlayer releases for earlier notes, including the database 14 to 15 downgrade warning.
• TheSmallHanCat/NeriPlayer-LTW for the Listen Together worker used on Cloudflare Workers.
• Issue #247 on USB exclusive playback failure.
• Issue #257 on YouTube Music playback failure.

If you are deciding whether to run this backend yourself, or you have inherited a similar Kotlin and Compose codebase and need a maintenance plan, I can help you scope the deployment, pin and stage upgrades, and set up backup and rollback checks as part of custom software development and system maintenance. To do that I would first need access to the repository and build environment, the Cloudflare or equivalent account details, your current sync data and configuration, and a description of the devices and user groups you need to support. I would start with a read-only review of the deployment and upgrade path before proposing any change; you can outline your situation here.