Aurral self-hosted music discovery and library guide

Aurral's self-hosted music library and discovery scope

Aurral addresses a specific gap between basic music servers and multi-service automation stacks. It presents discovery, search, library management, album requests, monitoring, playlists, and playback connections through its own web interface. The intended users are people who already operate or are willing to operate Docker services and want their music collection to remain under their control.

The project can maintain a library without Lidarr, which is a meaningful architectural choice for smaller or simpler deployments. Lidarr is optional rather than part of the minimum server definition. Users can search for artists and albums, preview tracks, and add selections to Aurral or to Lidarr using configured defaults. They can also monitor artists and review wanted albums through queue, history, and Wanted views.

This is much broader than a media server catalog. Aurral describes rotating discovery flows, scheduled playlist generation, fixed tracklists, artist news, trends, tags, recent releases, upcoming releases, and nearby shows. Playlist imports include Spotify, YouTube Music, Last.fm, and ListenBrainz. That breadth makes Aurral useful when discovery and library requests are connected, but it also means an adoption decision should examine whether all of those capabilities are relevant to the intended setup.

Inside Aurral's Node.js workspace and service data flow

The repository layout identifies separate `backend` and `frontend` workspaces inside a private JavaScript package named `aurral`. The root scripts build the frontend and start `backend/server.js` with `backend/.env`. Development can run the backend with file watching while the frontend runs through its own workspace command. This indicates a web application with a server-side API and a separate browser interface rather than a collection of unrelated command-line utilities.

The container build gives additional detail about runtime dependencies. The frontend is compiled during a builder stage, while production backend dependencies are installed separately with optional packages included. The Dockerfile also builds around `static-ffmpeg`, and it includes `cloudflared` in its build inputs. The documented feature set provides the functional path: discovery metadata and listening data identify content, users create flows or import playlists, Aurral builds library or request activity, and download clients such as yt-dlp, slskd, Usenet, and deemix handle acquisition. Users can cancel, retry, upgrade, or manually choose a download from activity views.

For metadata, the README credits BrainzMash with hosted artist and album metadata, MusicBrainz with canonical release metadata and identifiers, and Honker with SQLite queues and background workers. Based on those documented roles, discovery and search can supply identifiers, while the queue and worker layer supports durable processing. The README does not expose the API schema or the complete worker sequence, so it would be wrong to infer undocumented endpoints or claim precise retry semantics.

Docker Compose installation and first Aurral launch

The README's quick start uses a published container image and keeps configuration and media on host-mounted paths. Create a `docker-compose.yml` with the following service definition. The `MEDIA_ROOT` variable selects the host media directory, while `/data` remains the path seen inside the Aurral container.

services:
  aurral:
    image: ghcr.io/lklynet/aurral:latest
    restart: unless-stopped
    ports:
      - "3001:3001"
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ${MEDIA_ROOT:-/srv/media}:/data
      - ./config:/config

Set `MEDIA_ROOT` to the host media folder before starting the stack. If Lidarr is used, the README says to select the host folder already mounted by Lidarr. Keep `/data` as the container path and use the same mount for download clients and the playback server. Aurral's Downloads Folder can then be set to a container path such as `/data/downloads/aurral`.

Start the service with the documented Compose command:

docker compose up -d

The service should be reachable at the documented local address:

http://localhost:3001

Open that address and create the admin account. Lidarr can be connected later if it will manage the library, or it can be skipped so that Aurral keeps music in its Downloads Folder.

Aurral image tags, shared storage, and upgrade choices

The quick-start configuration uses `ghcr.io/lklynet/aurral:latest`. The README also documents `ghcr.io/lklynet/aurral:nightly` for the latest merged changes, while warning that nightly builds can be less stable than releases. For operators who need a defined release point, the documented releases include v2.10.0, v2.9.1, and v2.9.0. The README does not provide a complete upgrade or rollback procedure, so changing image tags should not be treated as a documented migration workflow.

Storage is the first integration decision. If Lidarr is present, the README says to use the host folder already mounted by Lidarr. Download clients and the playback server should use the same mount, and Aurral's Downloads Folder must be expressed as a container path such as `/data/downloads/aurral`. This avoids the common mismatch where Aurral sees one host directory but a downloader or playback service sees another.

The default repository `docker-compose.yml` only maps `./config` to `/config`, while the README quick start also defines `${MEDIA_ROOT:-/srv/media}:/data` and the `PUID` and `PGID` environment entries. Operators should not combine these without checking the deployment guide, because the two files do not present identical mounts. The documented storage guide and `docker-compose.example.yml` are the relevant sources for a fuller Lidarr, slskd, and Navidrome arrangement.

Lidarr, download clients, and playback service boundaries

Aurral can sit above Lidarr or operate as the library manager by itself. With Lidarr connected, users can hand library management to that service. Without it, Aurral keeps music in its Downloads Folder and still exposes library, monitoring, request, and activity functions. This makes the same application useful in two rather different arrangements.

The wider stack is component-based. yt-dlp, slskd, Usenet, SABnzbd, NZBGet, and deemix appear as download mechanisms. Navidrome, Plex, Jellyfin, Subsonic clients, Feishin, Music Assistant, Plexamp, and webhooks occupy playback, publishing, or notification roles. Prowlarr, Ticketmaster, Gotify, Last.fm, ListenBrainz, Koito, and OIDC add separate discovery, notification, or identity behavior. The README lists these as integrations but does not claim that every deployment needs them.

That distinction matters. Aurral does not replace every listed service. For example, the repository example is described as a stack with Lidarr, slskd, and Navidrome, which means several services retain separate responsibilities. Playback can occur in the browser, but connecting another server or client introduces path, account, and protocol compatibility questions. The project supports this wider arrangement, although the README does not provide a universal compatibility matrix.

Aurral limitations, permissions, and operational trade-offs

The first limitation is deployment complexity. Even the minimum documented setup requires Docker Compose, a deliberate media mount, and configuration persistence. Enabling requests, automation, or playback across several services adds more configuration, credentials, and shared-folder contracts. A user who only wants a simple library catalog may find Aurral's feature set excessive.

Multi-user support includes profiles, discovery layouts, permissions, account status, local passwords, LAN auto-login, reverse-proxy SSO, native OIDC, Google, and Plex sign-in. This offers several authentication paths, but the README does not explain the security configuration of each method. It also does not document a backup procedure for user accounts, configuration, queues, or library state. Administrators should not infer backup coverage merely because the container image and config directory exist.

Another boundary concerns behavior outside Aurral. Activity views support cancel, retry, upgrade, and manual download choices, but download outcomes depend on configured clients and sources. Upstream service failures, inaccessible files, or inconsistent mount paths can surface as operational problems even when Aurral itself remains available. The README supports health checks through `/api/health` in a development command, but it does not present a complete production monitoring and disaster recovery guide.

Aurral is also the wrong tool when Lidarr or an existing media server already covers the user's complete workflow and there is no need for coordinated discovery flows, playlist automation, or multi-user request handling. Adding another service would introduce configuration without removing a stated requirement.

MIT licensing and Aurral maintenance signals

Aurral is distributed under the MIT license. That identifier permits reuse and modification under the license's conditions, but this review does not provide legal advice. Operators still need to review the repository `LICENSE` file and account for separately deployed services, media, metadata, and integrations when assessing their own obligations.

The repository is not archived, and the last push was on 2026-10-16. Recent release records also include v2.10.0 on 2026-09-23, v2.9.1 on 2026-09-17, and v2.9.0 on 2026-09-14. These are concrete signs of recent repository and release activity, though they do not by themselves establish suitability for a particular production workload.

The stack raises operational cost beyond JavaScript dependencies. Node `26.11.x` is specified by `package.json`, and the Docker build includes native build tooling, optional packages, `sharp`, and a Honker smoke check. This indicates that containerized deployment is the documented first-use path, while source operation requires matching the declared Node version and workspace setup.

Editorial conclusion

Aurral suits self-hosters who want discovery, monitoring, requests, and playback coordination in one service and are prepared to design shared storage carefully. It is a poor fit for users seeking a small metadata browser, a simple download proxy, or a plug-and-play music server with no external integrations. Before adoption, verify that `/data`, the Downloads Folder, Lidarr, download clients, and playback servers use compatible container and host paths, then confirm which identity providers and external services the required workflow depends on. For an initial deployment using the documented configuration, the concrete judgement is that Aurral is immediately operable as the library service on port 3001, while every optional integration remains a separate compatibility decision.

Frequently asked questions

Official sources

1. License: MIT
2. lklynet/aurral on GitHub
3. Project website
4. README
5. Releases