Lidarr on AWS

This image delivers Lidarr, the popular open source music collection manager and PVR of the *arr family, fully installed and reverse-proxied with nginx. Lidarr monitors your favourite artists, organises your existing music library, and automatically grabs and imports new releases from the indexers and download clients you connect to it, all through a fast web UI and a full REST API.

The Lidarr server is a self-contained .NET application (its runtime is bundled) with an embedded SQLite datastore. It runs under systemd as the unprivileged lidarr service account, listening on the loopback interface only (127.0.0.1:8686), with nginx in front on port 80 (and 443 once you add TLS). The configuration, SQLite databases, artwork cache and backups all live on a dedicated, independently-resizable EBS data volume mounted at /var/lib/lidarr, separate from the operating system disk.

Secure by default - per-instance credentials, no shared secrets

Lidarr ships with no authentication on its web interface. This image hardens that: the only reachable interface, nginx on port 80, is protected by HTTP Basic authentication, and two secrets are generated uniquely on each instance at first boot - the web Basic-auth password and Lidarr's REST API key. Nothing is shared between customers, no credential is baked into the AMI, and the REST API refuses every unauthenticated request. The Lidarr server itself is never exposed directly; it listens on loopback only.

Connecting to your instance

Connect over SSH on port 22 using the default login user for your operating system variant and the EC2 key pair you launched with.

Replace <instance-public-ip> with your instance's public IPv4 address (or its private address if you reach it over a VPN or Direct Connect).

Retrieve your web password and sign in

The web password is generated on this specific instance at first boot and written to a root-only file. Retrieve it over SSH:

sudo cat /root/lidarr-credentials.txt

You will see the sign-in user (admin), the generated LIDARR_ADMIN_PASSWORD, and your instance URL. Then open Lidarr in your browser:

http://<instance-public-ip>/

Your browser prompts for the user and password from that file. Sign in as admin with the generated password and the Lidarr library loads.

Lidarr is served over plain HTTP on port 80 until you add TLS. Enable HTTPS (see below) before exposing the instance to the public internet, and treat the password as any credential sent over plain HTTP.

Connect your indexers and download clients

Lidarr is the management application, not a content source. Out of the box it downloads nothing: it orchestrates the indexers and download clients that you connect to it. Open Settings in the left-hand navigation to configure them:

• Settings -> Indexers - add the Usenet or BitTorrent indexers / trackers you have access to (directly, or via a Prowlarr instance).
• Settings -> Download Clients - add your SABnzbd, NZBGet, qBittorrent, Deluge or Transmission client.
• Settings -> Media Management - a Music root folder on the dedicated data volume (/var/lib/lidarr/music) is pre-created; adjust naming and file-handling to taste.

Until you connect an indexer and a download client, Lidarr's System -> Status page will show health notices telling you they are missing - that is expected on a fresh instance.

Add your artists

Under Add New, search Lidarr's built-in music metadata for an artist, choose a quality profile and your root folder, and add them to your library. Lidarr then monitors the artist and, once you have an indexer and download client configured, fetches and imports matching releases automatically.

Using the REST API

Every Lidarr feature is available through its REST API. The API key is unique to this instance and stored in /var/lib/lidarr/config.xml; it must be supplied in an X-Api-Key header. Read your key over SSH:

sudo grep -oP '(?<=<ApiKey>)[^<]+' /var/lib/lidarr/config.xml

Then, from anywhere that can reach the instance, query the API (this example runs on the instance itself):

KEY=$(grep -oP '(?<=<ApiKey>)[^<]+' /var/lib/lidarr/config.xml)
curl -fsS -H "X-Api-Key: $KEY" http://127.0.0.1:8686/api/v1/system/status \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print("appName:", d["appName"], "version:", d["version"])'

You should see appName: Lidarr and the running version. The API refuses any request without a valid key, which you can confirm:

CODE=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8686/api/v1/system/status)
test "$CODE" = "401" && echo "unauthenticated API correctly refused (HTTP 401)"

Verify your deployment

The commands below run on the instance (over SSH) and confirm the stack is healthy, the web gate enforces your per-instance password, and data persists across a restart.

First, confirm both services are active and Lidarr answers its health check:

systemctl is-active lidarr nginx
for i in $(seq 1 30); do curl -fsS http://127.0.0.1:8686/ping >/dev/null 2>&1 && break; sleep 2; done
curl -fsS http://127.0.0.1:8686/ping && echo " <- Lidarr health OK"

Confirm the nginx gate rejects an unauthenticated request but accepts your per-instance password:

NOAUTH=$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/)
test "$NOAUTH" = "401" && echo "web UI correctly refused without credentials (HTTP 401)"
PW=$(grep '^LIDARR_ADMIN_PASSWORD=' /root/lidarr-credentials.txt | cut -d= -f2-)
OK=$(curl -s -o /dev/null -w '%{http_code}' -u "admin:$PW" http://127.0.0.1/)
test "$OK" = "200" && echo "signed in through nginx with the per-instance password (HTTP 200)"

Finally, prove data survives a service restart. This creates a Lidarr tag through the API, reads it back, restarts the Lidarr service, and confirms the tag is still there:

KEY=$(grep -oP '(?<=<ApiKey>)[^<]+' /var/lib/lidarr/config.xml)
curl -fsS -H "X-Api-Key: $KEY" -H 'Content-Type: application/json' \
  -X POST http://127.0.0.1:8686/api/v1/tag -d '{"label":"cloudimg-verify"}' >/dev/null
curl -fsS -H "X-Api-Key: $KEY" http://127.0.0.1:8686/api/v1/tag | grep -q 'cloudimg-verify' \
  && echo "tag written to the SQLite database"
systemctl restart lidarr
for i in $(seq 1 30); do curl -fsS http://127.0.0.1:8686/ping >/dev/null 2>&1 && break; sleep 2; done
curl -fsS -H "X-Api-Key: $KEY" http://127.0.0.1:8686/api/v1/tag | grep -q 'cloudimg-verify' \
  && echo "tag survived a lidarr service restart - data persisted on the dedicated volume"

The dedicated data volume

All Lidarr state - config.xml, the SQLite databases (lidarr.db, logs.db), the artwork cache and backups - lives on a dedicated EBS data volume mounted at /var/lib/lidarr, separate from the OS disk and independently resizable. The System -> Status page shows the running version and the data location:

Confirm the volume is mounted and holds the database:

findmnt /var/lib/lidarr
ls -la /var/lib/lidarr/lidarr.db

To grow it later, expand the EBS volume in the AWS console, then run sudo resize2fs $(findmnt -no SOURCE /var/lib/lidarr) on the instance.

Enabling HTTPS

nginx fronts Lidarr on port 80 and is ready for TLS. The simplest route is a free Let's Encrypt certificate with a DNS name you control. On the instance, with your domain pointed at the instance's public IP and TCP 443 open in the security group:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

certbot obtains the certificate, edits the nginx site to serve HTTPS on 443, and sets up automatic renewal. For production behind an AWS Application Load Balancer, terminate TLS at the ALB with an AWS Certificate Manager certificate instead and forward to the instance on port 80 within your VPC. cloudimg support can help with either pattern.

Managing the services

Two systemd units make up the stack:

systemctl status lidarr --no-pager | head -5
systemctl status nginx --no-pager | head -5

Restart Lidarr after a configuration change with sudo systemctl restart lidarr, and reload nginx after editing its site with sudo nginx -t && sudo systemctl reload nginx. Lidarr's own logs are under /var/lib/lidarr/logs and via sudo journalctl -u lidarr.

Support

cloudimg provides 24/7 technical support for this Lidarr AMI by email at support@cloudimg.co.uk and via live chat. We assist with deployment, version upgrades, reverse-proxy and TLS configuration, connecting indexers and download clients, and troubleshooting the application stack. Critical issues receive a one-hour average response.

Lidarr is a trademark of its respective owner. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.