Lidify: a music discovery service that reads your Lidarr library and suggests what to add

The Spotify path was closed and Last.fm is now the only route

The most important fact about Lidify is stated in a note near the top of the README. As of November 2024, changes to the Spotify API prevent its use in this application, with a pointer to an issue for the details, and the application now exclusively supports Last.fm. The integration story that follows is a short set of steps. You log in to your Last.fm account, create an API account on the Last.fm account creation page, and then copy the API key and secret it gives you into the Docker Compose configuration. That is a real constraint on how the tool is deployed, and it also means the mode environment variable, which selects the discovery mode, now has only one meaningful value in practice even though the documentation still describes both Spotify and LastFM. The repository itself is small and the shape is visible in the top-level entries. There is a src/ directory holding the application, a Dockerfile, requirements.txt, gunicorn_config.py, an init script named thewicklowwolf-init.sh, and a LICENSE file. The project is MIT licensed, and the last push was on 2026-10-12, with recent releases v0.2.11 from 2026-08-21, v0.2.10 and v0.2.9.

It is a Flask app behind gunicorn with websockets and gevent

The requirements file is where the architecture becomes concrete, and the combination is specific rather than generic. gunicorn 25.1.0 is the WSGI server and gunicorn_config.py at the repository root configures it. gevent 24.11.1 and gevent-websocket 0.10.1 supply the async layer and the websocket support, and flask 3.1.2 with flask_socketio 5.6.0 is the web layer with Socket.IO, which is how the browser talks to the server. requests 2.33.1 handles outbound HTTP to the Last.fm and Lidarr APIs, and pylast 7.0.2 is the Last.fm client, while spotipy 2.25.2 remains in the requirements even though the Spotify path is closed. musicbrainzngs 0.7.1 is the MusicBrainz client, and that is the piece that resolves artist metadata. Matching is done with thefuzz 0.22.1, which is the fuzzy string matching library, and Unidecode 1.4.0 transliterates strings so that accented and non-Latin names can be compared. The Dockerfile shows the runtime is python:3.12-alpine, with su-exec installed so the container can drop privileges, the requirements installed with pip, port 5000 exposed, and the entrypoint set to the init script.

The compose file is the whole installation

There is no pip install path documented, because the project is distributed as a container image from Docker Hub. The compose file in the README is the entire setup:

services:
  lidify:
    image: thewicklowwolf/lidify:latest
    container_name: lidify
    volumes:
      - /path/to/config:/lidify/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 5000:5000
    restart: unless-stopped
    environment:
      - last_fm_api_key=<insert>
      - last_fm_api_secret=<insert>
      - mode=LastFM

The image tag is latest, the container name is lidify, and the port mapping is 5000 to 5000, which matches the port the Dockerfile exposes. Two volumes are mounted. The config directory is where the application keeps its own configuration, and the local time file is mounted read-only so that timestamps in the interface match your timezone rather than the container's, which is a detail that saves confusion when you are looking at when a scan last ran. The environment block carries the two Last.fm credentials and the mode. The restart policy is unless-stopped, so the container comes back after a reboot unless you stopped it deliberately. The README links the Docker Hub page for thewicklowwolf/lidify, and the repository carries a Docker Pulls badge, so the image is published to a public registry rather than built from source as the normal route.

Twenty environment variables, and the ones that change behaviour

The configuration section is long, and most of it is standard for this class of self-hosted service. PUID and PGID set the user and group the app runs as, defaulting to 1000. lidarr_address is the URL for Lidarr, defaulting to http://192.168.1.2:8686, and lidarr_api_key is the key, with both also configurable from the application itself. root_folder_path is the music root, defaulting to /data/media/music/. The Lidarr-specific settings are quality_profile_id and metadata_profile_id, both defaulting to 1, and lidarr_api_timeout for the API call timeout, defaulting to 120 seconds. Three of the settings are switches rather than values, and they are the ones worth understanding before you first run it. search_for_missing_albums decides whether adding an artist immediately triggers an album search, and defaults to False. dry_run_adding_to_lidarr runs the whole flow without actually adding artists to Lidarr, also defaulting to False. And fallback_to_top_result decides whether to use the top result when no match is found, defaulting to False. The last two are the safety valves, and a first-time user should probably turn dry_run_adding_to_lidarr on before letting the tool write to their library.

auto_start runs the whole discovery cycle on a delay

The last three environment variables are about scheduling, and they describe a behaviour that is easy to miss. auto_start decides whether the application runs automatically at startup, defaulting to False. auto_start_delay is the delay duration for auto start in seconds when it is enabled, defaulting to 60. The combination means the tool can either wait for you to press something, or take a periodic pass through your library on its own after the container has been up for a minute. That is the difference between a recommendation list you pull and a background process that quietly proposes changes to your library. Alongside those, app_name, app_rev and app_url control the application's own presentation, with defaults of Lidify, 0.01 and a random URL. There is a light and a dark screenshot in the README, so the interface has both themes. The overall picture is a service that reads from Lidarr, resolves artist identity through MusicBrainz, asks Last.fm for similar artists, scores and matches names with fuzzy string comparison, and then either presents the result or pushes it back into Lidarr. The dry-run switch is what lets you see that pipeline without it changing anything.

Where this stops and Lidarr takes over

There is a clear boundary in what Lidify does, and it is worth being explicit about it because the name invites more confusion than the description resolves. Lidify produces recommendations. It does not download, and it does not manage the music library. The library side belongs to Lidarr, which is why the tool needs a Lidarr address, an API key, a root folder path, a quality profile and a metadata profile, and why the search_for_missing_albums switch hands the actual fetching back to Lidarr once an artist is added. The second limitation is the one already noted: the Spotify integration is closed, so the recommendations come from Last.fm's similarity data rather than from Spotify's own related-artist graph, and the musicbrainzngs dependency is what bridges Last.fm artist names to Lidarr artist records. The third is that the tool is opinionated about not searching automatically by default, and not adding anything to Lidarr unless you ask. For a self-hoster that is exactly right, because the failure mode of a discovery tool that silently adds artists is a library full of noise. The practical alternative to Lidify is simply querying Last.fm's similar-artist endpoint yourself and writing the matches into Lidarr by hand, which is what the tool automates along with the name matching that makes that workable across differently spelled artist names.

Editorial conclusion

Lidify suits a self-hoster who runs Lidarr and wants a second opinion on what to add to the library, who is comfortable with a container that needs a Last.fm API key and a Lidarr API key, and who wants the dry-run mode to preview additions before committing them. It is the wrong choice if you want Spotify-backed recommendations, because the project dropped that integration, and it is the wrong choice if you want the tool to fetch and download music itself, because Lidarr remains the component that does that. Verify first that your Last.fm account can create an API account, that the Lidarr address and API key you set are reachable from the container, and that the fallback_to_top_result and dry_run_adding_to_lidarr defaults match the behaviour you want.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TheWicklowWolf/Lidify on GitHub