Streaming & Messaging Azure

Sonarr on Ubuntu 24.04 on Azure User Guide

| Product: Sonarr on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Sonarr on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Sonarr is an open source PVR and library manager for TV series. It keeps a watchlist of the shows you follow, works out which episodes are missing or could be upgraded to a better quality, searches the indexers you configure, hands releases to your download client, and then renames and files the results into a consistently organised library.

The image installs the official Sonarr 4.0.19.2979 self contained linux-x64 build (recorded in /opt/Sonarr/VERSION) and runs it under systemd as the unprivileged sonarr system user, listening on port 8989. All application state lives under /var/lib/sonarr, with the series library at /var/lib/sonarr/tv and a download folder at /var/lib/sonarr/downloads.

Secure by default. A stock Sonarr starts with authentication switched off, which would leave an unprotected deployment open to anyone who can reach it, including full access to its API key. This image does not ship in that state. Forms authentication is enforced, and a unique administrator password and API key are generated on each virtual machine's first boot. The password is handed to Sonarr's own account creation path, so the server stores only a salted PBKDF2 hash and the plain value never remains on disk; the plain credentials are placed in a root only file for the administrator to read. Nothing usable is baked into the image, so no two deployments share a credential.

What is included:

  • Sonarr 4.0.19.2979 installed from the official self contained release, verified against the checksum published by the project before it is unpacked

  • Run under systemd as the unprivileged sonarr system user with a hardened service sandbox (NoNewPrivileges, PrivateTmp, ProtectSystem=full, ProtectHome)

  • Forms authentication enforced with a unique admin password and a unique 32 character API key generated per VM on first boot

  • All state under /var/lib/sonarr, with the series library and download folders laid out and owned correctly from the start

  • An unauthenticated /ping health endpoint for load balancer probes, so monitoring needs no credential even though the interface and API do

  • Automatic self updates turned off, so a running instance never silently drifts from the published image

  • A built in self test at /usr/local/bin/sonarr-selftest that proves the credential path end to end

  • Ubuntu 24.04 LTS base with the latest security patches applied at build time

  • Azure Linux Agent for seamless cloud integration and SSH key injection

  • 24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

  • An Azure subscription with permission to deploy virtual machines

  • An SSH key pair for administrative access to the VM as the azureuser account

  • A Network Security Group allowing inbound TCP 8989 from the networks that should reach the service, and 22 (SSH) from your management network only

  • A recommended size of Standard_B2s or larger

Step 1: Deploy from the Azure Portal

  1. Locate the Sonarr on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.

  2. Choose your subscription, resource group and region.

  3. Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.

  4. On the Networking tab, allow inbound 8989 from your users, and restrict 22 to your management network.

  5. Review and create. When the VM is running, browse to http://<your-public-ip>:8989/.

Step 2: Deploy from the Azure CLI

Deploy the image from the command line, restricting SSH to your management network. Replace the placeholder values with your own before running:

az vm create \
  --resource-group my-resource-group \
  --name sonarr \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

# Allow the web UI from your users and SSH from your management network only
az vm open-port --resource-group my-resource-group --name sonarr --port 8989 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name sonarrNSG \
  --name allow-ssh --priority 1002 --destination-port-ranges 22 \
  --source-address-prefixes <your-mgmt-cidr> --access Allow --protocol Tcp

When the VM is running, browse to http://<public-ip>:8989/.

Step 3: Retrieve your per instance credentials

Each VM generates its own admin password and API key on first boot, written to a root only file. Read it over SSH:

ssh azureuser@<vm-ip> 'sudo cat /root/sonarr-credentials.txt'

The file contains SONARR_URL, SONARR_ADMIN_USER, SONARR_ADMIN_PASSWORD and SONARR_API_KEY for this specific VM. Keep it secret. The server only ever stores a salted, heavily iterated one way hash of the password, never the plain text.

Step 4: Sign in to Sonarr

Browse to http://<vm-ip>:8989/. Because authentication is enforced, Sonarr presents its sign in page. Enter the username and password from Step 3.

The Sonarr sign in page titled SIGN IN TO CONTINUE, with the admin username filled in, a masked password field, a Remember Me checkbox and a Login button

Step 5: Your series library

After signing in you land on the Series view, the heart of Sonarr. Each series appears as a poster tile showing its monitoring state and quality profile, and the footer summarises how many series, episodes and files you have and how much disk they occupy. The left hand navigation gives you Calendar, Activity, Wanted, Settings and System.

The example below shows a library with three series added. A freshly deployed VM starts with an empty library, ready for you to add your own.

The Sonarr Series library showing three series as poster tiles, each labelled Monitored and Any, with a summary footer reporting 3 series, 3 ended, 20 episodes and 0 files, and the left navigation showing Series, Calendar, Activity, Wanted, Settings and System

Step 6: Add your first series

Choose Add New in the left hand navigation and start typing a series name. Sonarr queries its metadata service and returns matching shows with artwork, rating, network, genre, season count and a synopsis. Pick the right match, choose the root folder and quality profile, and add it.

The Sonarr Add New Series page with Planet Earth typed into the lookup box, returning Planet Earth 2006 and Planet Earth 1986 as result cards with posters, rating, language, network, genre, season count and synopsis, noting that metadata is provided by TheTVDB

Step 7: Manage a series

Selecting a series opens its detail page: artwork, synopsis, runtime, network, the folder it maps to on disk, its monitoring state and quality profile, and every season expanded into an episode table. From here you can refresh and scan the folder, search for monitored episodes, preview a rename, edit the series or change which seasons are monitored.

The Sonarr series detail page for Blue Planet II showing artwork, a synopsis, the path /var/lib/sonarr/tv/Blue Planet II, badges for size, quality profile, Monitored and Ended, and Season 1 and Specials rows with episode counts and a toolbar offering Refresh and Scan, Search Monitored, Preview Rename, Manage Episodes, History, Series Monitoring, Edit and Delete

To actually fetch episodes, add an indexer and a download client under Settings. Sonarr then monitors your series, grabs the releases that match your quality profile, and imports and renames the results into the library folder.

Step 8: Verify the deployment

SSH to the VM as azureuser and confirm the service is running and listening on port 8989:

systemctl is-active sonarr
sudo ss -tlnp | grep 8989
cat /opt/Sonarr/VERSION

The service reports active, Sonarr is listening on 8989, and the baked version matches the running build.

systemctl reporting sonarr and sonarr-firstboot as active, ss showing the Sonarr process listening on port 8989, and the VERSION file reporting 4.0.19.2979

Run the built in self test. It reads this VM's credentials and proves the whole authentication path: an unauthenticated API call is refused, a wrong API key is refused, the per VM API key returns real system status, a wrong password is rejected, and the correct password opens an authenticated session:

sudo /usr/local/bin/sonarr-selftest
curl -s http://127.0.0.1:8989/ping

The sonarr-selftest output reporting OK, and the unauthenticated ping endpoint returning a JSON document with status OK

Step 9: Confirm authentication is enforced

Sonarr's REST API requires the per VM API key. Confirm that an unauthenticated call is refused and an authenticated one succeeds:

curl -s -o /dev/null -w 'no key -> HTTP %{http_code}\n' http://127.0.0.1:8989/api/v3/system/status
KEY=$(sudo grep '^SONARR_API_KEY=' /root/sonarr-credentials.txt | cut -d= -f2-)
curl -s -H "X-Api-Key: $KEY" http://127.0.0.1:8989/api/v3/system/status | jq '{appName,version,authentication}'

The unauthenticated request returns 401. The authenticated request returns the system status and reports "authentication": "forms", confirming the gate is active.

curl showing an unauthenticated request to the system status API returning HTTP 401, and an authenticated request with the per VM API key returning appName Sonarr, version 4.0.19.2979 and authentication forms

The /ping endpoint is deliberately unauthenticated so a load balancer or monitoring probe can check health without holding a credential.

Step 10: Per instance credentials and settings at rest

The credentials file is readable only by root, and the authentication settings are recorded in Sonarr's configuration. The secret values are masked in the screenshot below; read the real ones as shown in Step 3:

sudo ls -l /root/sonarr-credentials.txt
sudo grep -E 'Authentication|UpdateAutomatically' /var/lib/sonarr/config.xml

The file is mode 600 and owned by root, AuthenticationMethod is Forms, AuthenticationRequired is Enabled, and UpdateAutomatically is False. Note that no password is stored in the configuration file at all: it exists only as a salted hash inside Sonarr's database.

ls showing sonarr-credentials.txt as mode 600 owned by root, the credentials file with the password and API key redacted, and the config file reporting AuthenticationMethod Forms, AuthenticationRequired Enabled and UpdateAutomatically False

Step 11: Where your data lives

All Sonarr state is under a single directory, which makes backup and migration straightforward:

sudo ls -l /var/lib/sonarr/

config.xml holds the settings and API key, sonarr.db holds your series, episodes and history, tv is the series library root and downloads is the folder to point your download client at. Back up /var/lib/sonarr to preserve everything.

Security notes

  • No default login. Forms authentication is enforced and a unique administrator password and API key are generated on each VM's first boot. Only a salted PBKDF2 hash is stored; the plain values live in the root only /root/sonarr-credentials.txt.

  • Protect the API key. The key grants full API access. Treat it exactly as you would the password, and rotate it from Settings, General if it is ever exposed.

  • Restrict access. Sonarr serves plain HTTP on 8989. Allow that port only from the networks that need it, and keep 22 restricted to your management network. For internet facing use, put a TLS terminating reverse proxy or an Azure Application Gateway in front so credentials are never sent in clear text.

  • Rotate the password from Settings, General, Security at any time; the new value is stored as a fresh salted hash.

  • Indexers and download clients are yours to configure. The image ships none, so a new deployment cannot reach out anywhere until you deliberately add them. Make sure your use of any indexer complies with its terms and with the law in your jurisdiction.

Support

This image is backed by 24/7 cloudimg support with a guaranteed 24 hour response SLA. Contact support@cloudimg.co.uk for assistance. Sonarr is open source software distributed under the GNU General Public License version 3 and is free; the cloudimg charge covers packaging, hardening, security patching, image maintenance and support.