Sonarr on Ubuntu 24.04 on Azure User Guide
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
sonarrsystem 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
/pinghealth 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-selftestthat 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
azureuseraccount -
A Network Security Group allowing inbound TCP
8989from the networks that should reach the service, and22(SSH) from your management network only -
A recommended size of Standard_B2s or larger
Step 1: Deploy from the Azure Portal
-
Locate the Sonarr on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.
-
Choose your subscription, resource group and region.
-
Select a VM size (Standard_B2s or larger) and provide your SSH public key for the
azureuseraccount. -
On the Networking tab, allow inbound
8989from your users, and restrict22to your management network. -
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.

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.

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.

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.

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.

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

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.

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.

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 keep22restricted 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.