Prowlarr on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Prowlarr on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Prowlarr is an open source indexer manager and proxy for Usenet and BitTorrent users. It centralises the definitions of your indexers and trackers in one place, tests and manages them, runs searches across all of them at once from a single screen, and pushes those indexers out to the apps that consume them, so you configure an indexer once in Prowlarr rather than repeating the work in Radarr, Sonarr, Lidarr and Readarr.

The image installs the official Prowlarr 2.4.0.5397 self contained linux-core-x64 build (recorded in /opt/Prowlarr/VERSION) and runs it under systemd as the unprivileged prowlarr system user, listening on port 9696. All application state lives under /var/lib/prowlarr.

Secure by default. A stock Prowlarr 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 stored only as 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:

• Prowlarr 2.4.0.5397 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 prowlarr 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/prowlarr

• 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/prowlarr-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 9696 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 Prowlarr 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 9696 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>:9696/.

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 prowlarr \
  --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 prowlarr --port 9696 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name prowlarrNSG \
  --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>:9696/.

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/prowlarr-credentials.txt'

The file contains PROWLARR_URL, PROWLARR_ADMIN_USER, PROWLARR_ADMIN_PASSWORD and PROWLARR_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 Prowlarr

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

Step 5: Your indexers dashboard

After signing in you land on the Indexers view, the heart of Prowlarr. A freshly deployed VM starts with no indexers, so Prowlarr prompts you to add your first one. The left hand navigation gives you Indexers, Stats, Search, History, Settings and System, and the toolbar offers Add Indexer, Sync App Indexers and Test All Indexers.

Step 6: Add an indexer

Choose Add Indexer and Prowlarr opens its catalogue of supported indexers and trackers. Filter by protocol, language, privacy or category, or type into the search box to narrow the list, then select the indexer you want and enter its details. Prowlarr also supports any indexer that uses the Newznab or Torznab standard through its Generic Newznab and Generic Torznab entries.

Step 7: Sync your indexers to your apps

The reason Prowlarr exists is to manage indexers in one place and push them out to the apps that use them. Under Settings, Apps you connect your Radarr, Sonarr, Lidarr and Readarr instances, and Prowlarr keeps their indexers in sync automatically. A default Standard sync profile controls which capabilities, such as RSS, automatic search and interactive search, are enabled for synced indexers.

Step 8: Verify the deployment

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

systemctl is-active prowlarr
sudo ss -tlnp | grep 9696
cat /opt/Prowlarr/VERSION

The service reports active, Prowlarr is listening on 9696, 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/prowlarr-selftest
curl -s http://127.0.0.1:9696/ping

Step 9: Confirm authentication is enforced

Prowlarr'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:9696/api/v1/system/status
KEY=$(sudo grep '^PROWLARR_API_KEY=' /root/prowlarr-credentials.txt | cut -d= -f2-)
curl -s -H "X-Api-Key: $KEY" http://127.0.0.1:9696/api/v1/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 Prowlarr's configuration. The secret values are masked in the screenshot below; read the real ones as shown in Step 3:

sudo ls -l /root/prowlarr-credentials.txt
sudo grep -E 'Authentication|UpdateAutomatically' /var/lib/prowlarr/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 Prowlarr's database.

Step 11: Where your data lives

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

sudo ls -l /var/lib/prowlarr/

config.xml holds the settings and API key, and prowlarr.db holds your indexers, applications, sync profiles and history. Back up /var/lib/prowlarr 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/prowlarr-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. Prowlarr serves plain HTTP on 9696. 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 apps 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. Prowlarr 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.