myMPD: a small C web client for MPD, built for a Raspberry Pi

A MPD front end sized for a device with 512 megabytes of RAM

myMPD is described as a standalone and lightweight web based MPD client, tuned for minimal resource usage and requiring only very few dependencies, which the README concludes makes it ideal for Raspberry Pis and similar devices.

The design constraint is the whole product. The backend is written in C and has no dependencies to external databases or webservers. The configuration is stored in plain text files, and all the data is pulled on demand from MPD. The README states the principle directly: the MPD database is the only source of truth for myMPD.

That last sentence is the most important line in the document for anyone evaluating it, because it defines what myMPD is not. It is not a second music server, it is not a cache of your library, and it does not keep a parallel index. Everything it shows, from the queue to the album art to the tags you can browse, is fetched from MPD when you ask for it. That is what makes it cheap to run on a small box, and it is also what makes it a poor fit for anything that needs its own data.

The lineage explains a lot of the design. myMPD was originally a fork of ympd, and the README notes it has since evolved into a much more comprehensive MPD client. The project is by one maintainer, Juergen Mang, with a copyright line running from 2018 to 2026, and the topic tags on the repository are jukebox, lua, mpd-client, scripting, smart-playlists and timer, which is an accurate summary of where the extra functionality went.

The stated aim, in the README's own words, is that myMPD is in active development, and the release history supports that claim in a mechanical way: the recent tags are v26.1.1 from 2026-10-14, v26.1.0 from 2026-10-11 and v26.0.0 from 2026-08-28, and the last push to the repository was on 2026-10-19. The version numbering is calendar based, which is a good sign for a project that wants to be predictable about when a release happened.

What the client can do with MPD itself

The feature list is long, but it separates cleanly into two groups: what MPD already does, and what myMPD adds on top.

The first group is a complete MPD client. Concurrent MPD partition support, control of MPD functions and options, MPD option presets, queue and playlist management, browsing the MPD database by tags or by filesystem, advanced search, jukebox mode, and MPD mount and neighbours support. Jukebox mode deserves a note because it is the MPD feature that changes the meaning of a queue, where a play command moves a song into the live output rather than into a list waiting for the current one to finish.

The second group is myMPD's own layer, and the items are the reason you would not just use a minimal MPD web client. Smart playlists and saved searches, which are stored by myMPD rather than by MPD. Timers and triggers, which is a scheduling layer MPD does not have. Sticker support for playback statistics, voting and user defined stickers, which is where the playback history and the ratings live. Album art, both embedded and one image per folder. Lyrics, in both unsynchronized and synchronized form. Local PDF booklets and info.txt files per album folder. Local playback of an MPD HTTP stream, so the device can play a stream that MPD itself is serving.

There is also a web radio side: Favorites for the user's own stations and a separate WebradioDB project, and scripts that can import stations from RadioBrowser. ListenBrainz and MusicBrainz integration are listed as well, which in practice comes through the script repository rather than the core.

A few smaller items point at the intended use. The publishing of MPD and myMPD directories over HTTP lets you serve files that already exist on the box. The home screen has shortcuts and widgets. The interface is localisable, with a documentation page for translating it. There is a dark and a light theme, the frontend is a progressive web app, and the Media Session API is supported, which is what lets the operating system show track information and hardware media keys on a phone.

A progressive web app in plain JavaScript, and what that buys

The frontend is mobile friendly, written as a PWA in plain JavaScript, and offers the same functionality on all devices. That last clause is a design commitment rather than a marketing one: there is no separate mobile interface and no separate desktop interface, and the repository layout shows why.

The web assets live in an htdocs directory, and the build is a modern JavaScript toolchain rather than a hand-assembled directory of static files. There is an eslint.config.mjs at the root, a jsdoc.json for documentation, a .stylelintrc.json for the stylesheets, a .markdownlint.json for the documentation, a .htmlhintrc for the HTML, and a linter directory in the tree. So the front end is linted and documented with the same seriousness as the C code, which is visible in the .clang-tidy and .clangd files and the Doxyfile for the backend.

The PWA choice has a concrete consequence for a self-hosted service on a Raspberry Pi. Because the frontend is an installable progressive web app, a phone can add it to the home screen and use it as an app, which is a better experience than a bookmark to a page that has to redraw the chrome every time. Combined with the Media Session API support, the operating system integrates with the player in the way a native app would.

The Lua interpreter is the other significant piece of the client side story. myMPD functions can be scripted, and the .luacheckrc file in the root shows that the Lua code is linted as well. There is a whole scripting section in the documentation, and the repository has a separate project for scripts, which is the subject of the next section.

For a project whose README says it is in active development and invites contributions that do not require programming skills, the presence of a full linting and documentation toolchain across three languages is a reasonable signal about how the work is done.

The script repository is where the ecosystem lives

The mympd-scripts repository is described as providing many scripts to enhance and add features to myMPD, and the listed examples describe the gap between what MPD can do and what a user of a small home server usually wants.

Scrobbling is the first category, with Last.fm, Maloja and ListenBrainz as targets. Maloja is a self-hosted scrobble server, and ListenBrainz is also integrated in the core client for the listening statistics side.

Metadata fetching is the second. Album art and tag art can be pulled from fanart.tv and from OpenOpus, and lyrics from LRCLIB. That last one matters: synchronised lyrics in the MPD world usually mean a separate tool that downloads an .lrc file and stores it, and the README lists synchronised and unsynchronised lyrics as client features, so the script is the missing piece that makes them work.

The third category is content acquisition. Web radios can be imported from RadioBrowser, and there is a yt-dlp integration, which is the route by which a track that is not in your library ends up in it.

The fourth is the home screen widgets, and the list closes with a mention of many more.

This arrangement has an important consequence for anyone adopting myMPD. The core is a client, and the value a user actually feels often comes from the scripts layer, which lives in a different repository with its own release cycle. That is a reasonable design, because the scripts are the part that changes often and the part that can break without taking the client down, but it also means you are adopting two projects rather than one, and the core's feature list is a ceiling on what you get without that second repository.

The two integrations that reach outside the script model are worth singling out. The myGPIOd integration points at a separate project for hardware control, which for a Raspberry Pi case is how you would tie a physical button or a relay to playback, and the Media Session API support ties playback to the phone's lock screen and to any Bluetooth or network speaker you have.

Installation, configuration and where the documentation actually is

There is no quick start in the README, and that is not an omission. The README links to the myMPD documentation and lists three sections of it: installation, configuration and running. The project publishes documentation at jcorporation.github.io/myMPD/, and the instruction for support is explicit: read the documentation before asking for help, report bugs through issues, and use discussions for everything else.

The consequence for this article is that the install steps live in a separate site, so rather than inventing commands, it is worth describing what the project tells you about the shape of the setup.

The configuration is plain text files, which is the same property that makes the data model simple. A file you can read, edit and back up with cp is a different thing from a database, and for a device that you may reinstall the OS onto every year, that difference is not academic. The repository root also carries a SECURITY.md and a SPONSORS.md, alongside a CHANGELOG.md that is the upgrade record, and a LICENSE.md.

The build system is CMake. There is a CMakeLists.txt at the root, a cmake directory with the module definitions, a build.sh at the top level, a contrib directory for distribution packaging, a dist directory, a cli_tools directory, a test directory and a linter directory. So the project builds as a native binary with a test suite and a linting setup, rather than as a script collection.

The distribution model is the one question the README does not answer. There is no mention of a package repository, a Docker image or a container, and the installation documentation is the only place that will tell you. If you are deploying this on a Raspberry Pi OS image that is not Debian derived, or inside a container with an unusual base, expect to do the work yourself, because a project this focused on minimal dependencies has usually not invested in a broad packaging matrix.

One requirement is stated in the README and is easy to miss: to use all myMPD functions you should use the latest stable MPD version. Several of the features listed, stickers, partitions, mounts and neighbours, depend on MPD features that did not exist in older versions, so a client newer than the server is a configuration that works partially.

GPL-3.0, one maintainer and a project that grows by forks

The licence is GPL-3.0, with the text in the LICENSE.md file at the root of the repository. For a self-hosted service you run yourself, that is the usual choice for software of this kind and it carries no obligation for a private deployment.

The maintenance picture is specific and healthy on its face. The last push to the repository was on 2026-10-19, three days before the current date, and the recent releases are v26.1.1 on 2026-10-14, v26.1.0 on 2026-10-11 and v26.0.0 on 2026-08-28. Three releases in seven weeks on a calendar version line is a steady pace.

The concentration of ownership is the thing to weigh. The copyright is held by Juergen Mang from 2018 to 2026, the support channels are issues and discussions on the repository, and the contribution invitation in the README asks for help to improve the project with the note that no programming skills are required, alongside a donation link and a request to star the repository. The document also carries a page about helping to improve myMPD as an issue in the tracker.

For a project this focused, one maintainer is a strength and a risk at the same time. The scope is narrow enough that a single person can hold all of it, and the fork history shows the same pattern: myMPD itself started as a fork of ympd, and the mympd-scripts repository, the myGPIOd project and the WebradioDB project are separate repositories under the same organisation. The organisation is effectively a set of small tools around one MPD client.

The technology choice deserves the last word. Writing the server in C with no external dependencies and keeping state in text files is a deliberate bet that a home server running a Raspberry Pi should not need a runtime, a database or a reverse proxy to serve a music player. myMPD wins that bet by refusing to store anything, and the price is that everything it shows has to be fetched from MPD, which is fine on a LAN and fine over the internet too, but it means there is no offline view of your library and no place for myMPD-specific data other than those text files.

Editorial conclusion

Adopt myMPD if you run MPD on a small device such as a Raspberry Pi and want a phone friendly control surface without adding a database, a web server or a heavy runtime to the box, especially if you want timers, triggers and scriptable behaviour rather than a plain player. Do not adopt it if you need multi user accounts, a modern web stack you can extend with your own framework, or a client that keeps its own state, because myMPD deliberately keeps no state of its own. Verify first that you are on a recent enough MPD to get the full function set, since the README says all myMPD functions need the latest stable MPD version, that the Lua interpreter and the web radio database are features you actually want given they are the two parts with their own upstream projects, and that the plain text configuration files in your config directory are backed up, because that is where the state myMPD does keep lives.

Frequently asked questions

Official sources

1. jcorporation/myMPD on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases