Nuclear: a Tauri music player where plugins, not the app, find the music
Streaming music player that finds free music for you
At a glance
- What is it?
- Nuclear is an AGPL-3.0 desktop player for Windows, macOS and Linux whose streaming, metadata and playlist behaviour is delegated to installable plugins. It is a reasonable choice if you want a local client you can extend; it is the wrong choice if you want a guaranteed catalogue or a headless server.
- Who is it for?
- Adopt Nuclear if you want a local, extensible desktop client and you are willing to install or write the plugins that actually resolve tracks. Do not adopt it if you need a documented guarantee about where audio comes from, if you want a headless server, or if AGPL-3.0 obligations conflict with how you intend to redistribute a modified build.
- 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 1 day 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 September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nuclear solves is catalogue plumbing, not playback
Playback is a solved problem on the desktop. What is not solved is telling a player where a given track lives. Nuclear's README states the app lets you "search for music and stream it from any source", and the feature list puts a plugin system with a built-in plugin store near the top. That ordering is the point of the project. The player shell handles search, artist and album pages, queueing with shuffle and repeat, drag-and-drop reordering, favourites, playlists with import and export, themes and keyboard shortcuts. Everything that touches the outside world is meant to arrive through a plugin. Plugins, per the README, "can provide streaming sources, metadata, playlists, dashboard content, and more". So the audience is not someone who wants a Spotify replacement out of the box. It is someone who wants a local client whose behaviour they can change without forking the whole application, and who accepts that the useful parts are supplied by whoever wrote the plugin they installed.
Architecture: a pnpm monorepo, Tauri on the outside, React on the inside
The README describes Nuclear as "a pnpm monorepo managed with Turborepo", with the main app built on Tauri, which pairs a Rust core with a React front end. The repository topics list TypeScript, Rust, React and Tauri together, which matches that description. The practical consequence is a two-language build: the Rust side produces the desktop binary and the platform integration, while the TypeScript side carries the interface and, judging by the plugin SDK published as @nuclearplayer/plugin-sdk on npm, the plugin surface as well. That split matters when you debug. A failing search is unlikely to be a Rust problem; a failing window, auto-update or file dialog probably is. The screenshots in the README include a dedicated log viewer, which suggests the project expects users to inspect runtime output rather than guess. There is also a preferences screen and a "what's new" screen, so the app surfaces its own release notes inside the UI. None of this tells you how a given plugin resolves a track. That logic lives in the plugin, and the README does not describe it.
The MCP server turns the player into a tool an agent can call
The most distinctive feature in the README is the MCP server. It is off until you enable it in Settings, under Integrations, and it listens on http://127.0.0.1:8800/mcp. The README gives registration commands for several clients. For Claude Code: claude mcp add nuclear --transport http http://127.0.0.1:8800/mcp. For Codex CLI: codex mcp add nuclear --url http://127.0.0.1:8800/mcp. For OpenCode, Claude Desktop, Cursor and Windsurf, you add a JSON entry with the same URL, either under an "mcp" key with type "remote" or under "mcpServers". The README says the MCP "is designed to be discoverable" and mentions an optional skill archive, nuclear-mcp.zip, kept under packages/docs/.gitbook/assets. Two things are worth noting. First, the endpoint is bound to loopback, so this is a local integration, not a hosted service. Second, the README does not enumerate the tools the server exposes; it relies on discovery. If you need a guaranteed tool list before wiring an agent to it, you will have to run it and inspect the handshake yourself.
Getting it running from source takes four commands and a Rust toolchain
The README's development path is short. Prerequisites are Node.js 22 or newer, pnpm 9 or newer, a stable Rust toolchain, and the platform-specific Tauri dependencies, which the README defers to the Tauri v2 prerequisites page. Then: git clone https://github.com/nukeop/nuclear.git, cd nuclear, pnpm install, pnpm dev. The useful commands are pnpm dev for the player in development mode, pnpm dev:remote which, per the README, "binds Vite to 0.0.0.0 so you can open the remote control UI from other devices on your LAN", pnpm build, pnpm test, pnpm lint, pnpm type-check and pnpm storybook. If you only want to use the player, the README points at the Releases page instead, with .exe and .msi for Windows, .dmg for Apple Silicon and Intel, and .AppImage, .deb, .rpm and .flatpak for Linux. Note the LAN binding on dev:remote. It is a development convenience, and it exposes the UI to your local network, so it is not something to leave running on an untrusted network. The README does not say whether that mode requires authentication.
Where Nuclear breaks down: plugin dependency and no stated source guarantees
The README says the app streams "from any source", but it also says every functionality "has been redesigned to be driven by plugins". Those two statements together define the failure mode. A fresh install with no source plugin has nothing to resolve a search into audio. The README does not state which plugins ship by default, whether the plugin store is curated, or what happens when an installed plugin stops working. It also does not describe how licensing is handled for the audio a plugin returns. That is not a documentation gap you can work around with configuration; it is the central trade-off of the design. The player is a shell, and the shell is only as useful as the plugins you trust. There is a second limitation in the same area: the README lists playlists that can be imported "from varous services" (the typo is in the source), but it does not name them, so you cannot tell in advance whether your existing library will transfer. A third: the MCP server is local-only on 127.0.0.1:8800, so any agent workflow that assumes a remote endpoint will need a tunnel you build yourself.
How it differs from a browser-based player such as the YouTube Music web client
The obvious comparison is a web player like the YouTube Music client, and the difference is not the catalogue, it is where the logic runs. A web player executes in a browser sandbox, which constrains what it can do with your filesystem, your local network and your audio stack, and it is updated by its operator on their schedule. Nuclear runs as a native binary with a Rust core, so it can touch the filesystem and open local sockets, which is exactly what the MCP server on port 8800 requires. It also means the extension mechanism is code you install rather than a userscript, which is more capable and more dangerous. The second difference is versioning. Nuclear publishes release-tagged builds (player@1.48.3, player@1.48.2 and player@1.48.1 all landed on 2026-09-04, per the repository metadata) and the app has auto-updates, so you control when the binary changes. A hosted web client does not give you that choice. The third difference is the licence. AGPL-3.0 applies to Nuclear; a hosted service's terms apply to the web client. If you modify Nuclear and let other people interact with it over a network, the AGPL's source-disclosure condition is the thing to read, and I am not giving legal advice on how it applies to your deployment.
Maintenance cost and the AGPL-3.0 boundary
The release cadence visible in the repository metadata is high: three patch releases on a single day in September 2026. For a user, auto-updates make that mostly invisible. For anyone building on the plugin SDK, it is the main maintenance cost, because a patch bump can change the surface your plugin compiles against. The README does not publish a plugin API stability policy, so pinning a version of @nuclearplayer/plugin-sdk is the only lever the material describes. On licensing: the project is AGPL-3.0, and the README points at a LICENSE file for the full text. The AGPL's network clause is the part that distinguishes it from GPL-3.0, and it is the part that matters if you fork Nuclear and expose it to other users. Writing a plugin that imports the SDK is a different question from modifying the player itself, and the README does not address it. Treat that as a question for your own counsel, not as something the repository answers.
Editorial conclusion
Adopt Nuclear if you want a local, extensible desktop client and you are willing to install or write the plugins that actually resolve tracks. Do not adopt it if you need a documented guarantee about where audio comes from, if you want a headless server, or if AGPL-3.0 obligations conflict with how you intend to redistribute a modified build. Before committing, open Settings, install one source plugin from the plugin store, search for a track that is not widely licensed, and confirm the log viewer shows a resolvable stream. Then read the plugin SDK on npm to check whether the extension points you need exist.
Community notes