Listenarr: audiobook collection management like Sonarr, but for audio

What the server actually does for you

Listenarr is described as a fast, feature-rich, cross-platform audiobook management server, built as a complete solution for audiobook downloading. The comparison in the project description is direct: it automates audiobook collection management the way Sonarr or Radarr do, but for audiobooks, searching, downloading and organising a library using metadata from Audible and other sources.

The feature list breaks down into seven delivered capabilities. It serves audiobooks from multiple sources, torrents and NZBs, in MP3, M4A, M4B, FLAC, AAC, OGG and OPUS. It has a responsive web interface that works on a phone, tablet or desktop. It enriches metadata automatically from Audible and Amazon. It searches across multiple torrent and NZB indexers simultaneously through external API integration. It drives download clients, with qBittorrent, Transmission, SABnzbd and NZBGet listed. It shows download progress and status in real time. And it organises files with configurable naming patterns.

One item on the list is explicitly not done: full localisation support is marked as coming soon. For a project with a Discord bot and community channels, that is a visible rough edge rather than a hidden one.

Running it in Docker with the right registry and tag

Docker is the recommended path for production, and the README is specific about which registry and which tag to use. GHCR is the preferred registry, with a Docker Hub mirror still published for backwards compatibility.

docker run -d \
  --name listenarr \
  -p 4545:4545 \
  ## OPTIONAL: Set container runtime user/group and file creation mask
  -e PUID=1000 \
  -e PGID=1000 \
  -e UMASK=022 \
  ## OPTIONAL: Used by Discord Bot
  -e LISTENARR_PUBLIC_URL=https://your-domain.com \
  -v listenarr_data:/app/config \
  -v /path/to/audiobooks:/audiobooks #optional \
  -v /path/to/downloadclient-downloads:/downloads #optional \
  ghcr.io/listenarrs/listenarr:canary

The web interface is then on port 4545. The volume named listenarr_data is mounted at /app/config, and the two host paths for the audiobooks and the download client downloads are both optional.

The tag scheme is worth understanding before you pin anything. The latest and stable tags are struck through and marked as available soon. The canary tag is the latest canary build, a pre-release, with canary-X.Y.Z for a specific one. The beta tag is the latest beta build, also pre-release, with beta-X.Y.Z. A bare X.Y.Z is a specific release version.

The environment variables have a compatibility layer worth knowing. PUID and PGID set the user and group the container runs as, and GID is accepted as an alias for PGID. UMASK controls permissions on newly created files and folders, with the legacy UMASK_SET accepted as an alias. If PGID is omitted it defaults to the PUID value, and if neither umask variable is supplied the default is 022.

Docker Compose and the other install routes

Docker Compose is described as the recommended setup, and the compose file is short because the container image already bundles the backend and the front end.

version: '3.8'
services:
  listenarr:
    image: ghcr.io/listenarrs/listenarr:canary
    ports:
      - "4545:4545"
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=022
      - LISTENARR_PUBLIC_URL=https://your-domain.com ## OPTIONAL: Used by Discord Bot
    volumes:
      - listenarr_data:/app/config
      - /path/to/audiobooks:/audiobooks #optional
      - /path/to/downloadclient-downloads:/downloads #optional
    restart: unless-stopped

volumes:
  listenarr_data:

The compose file adds two things the plain docker run example does not show. There is a LISTENARR_LOG_LEVEL setting, which overrides the config file at runtime and accepts Verbose, Debug, Information, Warning, Error or Fatal, and there is a restart policy of unless-stopped, which matters for a service that is meant to stay up.

Pre-built executables are the other option, downloaded from GitHub Releases and extracted for your platform.

cd ./listenarr-linux-x64
chmod +x Listenarr.Api
./Listenarr.Api

The Windows archive holds a Listenarr.Api.exe and the macOS archive has osx-x64 and osx-arm64 variants for Apple Silicon. The prerequisites list begins with Node.js 24.x or later and the package file pins the engines field to node ^24.15.0, so the runtime requirement is not optional.

A layered .NET backend with a Vue front end

The repository structure shows a layered .NET solution with a separate front end, which explains why Node.js is a prerequisite even for the pre-built binaries.

The backend is split into listenarr.api/, listenarr.application/, listenarr.domain/ and listenarr.infrastructure/, alongside a listenarr.slnx solution file, Directory.Build.props and Directory.Packages.props for centralised build and package versions, and a global.json pinning the SDK. There is a BACKEND_ARCHITECTURE.md document, a LINTING.md, and a listenarr.api/ project file named Listenarr.Api.csproj, which matches the executable name in the release archives.

The front end lives in fe/ and is described in the Dockerfile comment as Vue.js, and the package scripts confirm it, with build:web running npm run build inside fe and dev:web running the dev server there.

The container image builds both into one thing. The Dockerfile starts from the .NET 10 ASP.NET runtime, exposes 4545 and sets ASPNETCORE_URLS to http://*:4545 with DOCKER_ENV set to true. It compiles the API with a Release configuration and publishes it, and it installs Node 24 from NodeSource during the build because MSBuild targets that run the front end build need npm and vite to execute during dotnet publish. There is also a small Go build stage whose stated purpose is to compile gosu from a modern Go toolchain so the container can drop privileges without inheriting the standard library vulnerabilities of the Debian packaged version.

Beta software, AI assisted code and a side project

The warning box in the README is unusually blunt and it is the first thing to read before deploying this.

Listenarr is being actively developed and should be considered beta software. There may be security exploits despite best efforts. Expose this software to the internet at your own risk. The platform may be subject to changes as it is being built out. You may experience data loss and need to restart. The team strives to avoid any data loss, but the instruction is to maintain backups of important data.

That is a project telling you exactly what its risk profile is, which is more useful than silence.

The disclaimer section adds the origin story. The app is coded with AI assistance. The author started it because his wife, an avid audiobook listener, was reading through multiple series quickly and he wanted an automated way for her to request, download and listen to new audiobooks. He is a front-end developer who does not know C#, and took the project as an opportunity to learn. He also states that this is a fun side project that solved a need for him, that it is not his main priority, and that he will choose his work, family and mental health before the project.

Read that with the maintenance data. The default branch is canary, the recent releases are all canary builds dated 2026-10-18 and 2026-10-19, and the last push was on 2026-10-20. So the branch you get by default is a moving pre-release target, and the project is explicitly a side project rather than a product with a support commitment.

The licence picture needs care too. The badge in the README reads AGPL-3.0, while the licence field on the repository records a custom type that GitHub cannot classify, and a LICENSE file and a NOTICE file are present in the tree. Read the LICENSE file before you build a business on it.

Where Listenarr fits against the alternatives

The comparison the project itself makes is with Sonarr and Radarr, and the honest framing is that Listenarr covers the same job for a different media type rather than doing anything those tools do not do for audiobooks.

If you already run Sonarr or Radarr, you know the shape of the workflow: you add something to a watch list, the server searches the indexers, matches releases against metadata, hands the download to a client, and then renames and moves the file into the library. Listenarr implements that loop for audiobooks, and the metadata source named in the description is Audible and Amazon, which is the audiobook equivalent of the film and music catalogues those tools use.

What Listenarr does not do is replace the library server side. The topics attached to the repository include audiobookshelf, and the reason is that these are complementary: Listenarr acquires and organises the files, and a server such as Audiobookshelf is what you then listen to them through. The same split exists in the film world, where a downloader and a media server are separate pieces.

Two practical differences are worth noting. The indexer side covers NZBs as well as torrents, and with SABnzbd and NZBGet among the supported download clients, which is a real difference for people whose indexers are usenet oriented. The supported format list includes M4B and FLAC alongside the more common MP3 and M4A, so lossless and chapter-bearing files are in scope.

The trade is maturity. Sonarr and Radarr are mature, widely deployed projects with years of release history. Listenarr is a beta side project on a canary branch, and its own documentation tells you to back up your data.

Editorial conclusion

Adopt Listenarr if you consume audiobooks in series and want the same request and download automation that Sonarr and Radarr give film and music libraries, since the indexer search, download client integration and Audible metadata are all in place. Do not expose it to the internet without reading the warning first, because the project calls it beta software that may contain security exploits, and do not treat the canary default branch as a release. Verify first that you understand the licence position, since the badge reads AGPL-3.0 while the licence field on the repository records a custom type, that your download client and indexer credentials are configured, and that you keep backups, because the maintainers state you may experience data loss and need to restart.

Frequently asked questions

Official sources

1. Issues
2. Listenarrs/Listenarr on GitHub
3. Project website
4. README
5. Releases