Applications Azure

Jackett on Ubuntu 24.04 on Azure User Guide

| Product: Jackett on Ubuntu 24.04 LTS on Azure

Overview

Jackett is a free, open source indexer proxy that acts as a bridge between your media automation apps and the many torrent and usenet trackers they search. It translates a single incoming query into the site specific requests each tracker expects, then normalises every result back into one consistent Torznab and Newznab feed, so tools like Sonarr, Radarr, Lidarr and any other Torznab or Newznab capable client only ever have to speak one protocol instead of maintaining bespoke support for each site. A clean web interface lets you add, configure and test trackers and manage the shared API key, while the feed endpoints let your other applications pull results automatically.

This cloudimg image installs the official Jackett 0.24.2233 self contained linux-x64 build (recorded in /opt/Jackett/VERSION) and runs it under systemd as the unprivileged jackett system user. Jackett listens on the loopback address 127.0.0.1:9117 only, and an nginx reverse proxy fronts it on port 80, which is the only public entry point. A unique administrator password is generated on the first boot of every VM, hashed into Jackett's own configuration, and written to a root only file, so no shared credential ships in the image. Backed by 24/7 cloudimg support.

Secure by default. A stock Jackett starts with no administrator password at all, which would leave an unprotected deployment open to anyone who can reach it, including full control of every configured tracker and the API key. This image does not ship in that state. Jackett is bound to loopback behind nginx, and that public entry point is only brought up after a unique administrator password is generated on each virtual machine's first boot. The password is stored the way Jackett itself stores it, as a salted SHA-512 hash, so the plain value never remains in the configuration; 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 and there is never a window in which an unauthenticated instance is exposed to the network.

What is included:

  • Jackett 0.24.2233 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 jackett system user with a hardened service sandbox (NoNewPrivileges, PrivateTmp, ProtectSystem=full, ProtectHome)
  • Jackett bound to the loopback address 127.0.0.1:9117, with nginx on port 80 as the only public listener
  • A unique administrator password generated on first boot and recorded in a root only file, hashed into the configuration as salted SHA-512
  • An unauthenticated /healthz endpoint for Azure Load Balancer health probes
  • 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/jackett-selftest that proves the credential path end to end
  • Ubuntu 24.04 LTS base with the latest security patches applied at build time, unattended security upgrades left enabled
  • Azure Linux Agent for seamless cloud integration and SSH key injection
  • 24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point. NSG inbound rules: allow 22/tcp from your management network for SSH and 80/tcp for the Web UI. Jackett reaches your trackers over outbound HTTPS, so no other inbound port is required. The Web UI is served over plain HTTP on port 80; for production, terminate TLS in front of it with your own domain (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Jackett by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name jackett \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name jackett --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active jackett.service nginx.service

Both report active. Jackett serves its Web UI and feed API on the loopback address 127.0.0.1:9117, and nginx fronts it on port 80. Because Jackett is bound to loopback, it is never reachable directly from the network; the only public path is nginx.

jackett.service and nginx.service reporting active, with Jackett listening on 127.0.0.1:9117 and nginx on port 80

Step 5 - Retrieve your admin login

The Jackett administrator password is generated uniquely on the first boot of your VM and written to a root only file:

sudo cat /root/jackett-credentials.txt

This file contains JACKETT_URL, JACKETT_ADMIN_PASSWORD and JACKETT_API_KEY. The admin password signs you in to the Web UI; the API key authenticates the Torznab and Newznab feed calls your other apps make. Store them somewhere safe.

The Jackett version and the per VM credentials file with the generated admin password and API key redacted

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -s http://localhost/healthz

It returns ok. This endpoint never touches Jackett and never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 7 - Verify authentication from the command line

The Web UI requires the administrator password for every request, so an unauthenticated call to the dashboard is redirected to the login page. Confirm this, then sign in with the per VM password read from the root only file and open the dashboard:

# Secure by default: an unauthenticated dashboard request is redirected to the login page
curl -s -o /dev/null -w 'unauthenticated dashboard -> HTTP %{http_code}\n' http://127.0.0.1/UI/Dashboard

# Sign in with the per-VM admin password (read from the root-only file) and open the dashboard
PASS=$(sudo grep '^JACKETT_ADMIN_PASSWORD=' /root/jackett-credentials.txt | cut -d= -f2-)
curl -s -c /tmp/jc -o /dev/null -X POST --data-urlencode "password=$PASS" http://127.0.0.1/UI/Dashboard
curl -s -o /dev/null -w 'authenticated dashboard -> HTTP %{http_code}\n' -b /tmp/jc http://127.0.0.1/UI/Dashboard
rm -f /tmp/jc

The unauthenticated request returns 302 (a redirect to the login page). The authenticated request returns 200. A shipped self test at /usr/local/bin/jackett-selftest proves the same round-trip and is what the build verifies before capture.

An unauthenticated dashboard request redirected with HTTP 302, then the per VM admin password opening the dashboard with HTTP 200, and the jackett-selftest reporting OK

Step 8 - Confirm the security posture

The administrator password is stored only as a salted SHA-512 hash, Jackett is bound to loopback, and automatic self updates are disabled so the running instance never drifts from the published image:

sudo jq -r '"AdminPassword hash length: " + (.AdminPassword | length | tostring)' /var/lib/jackett/Jackett/ServerConfig.json
sudo jq -r '"LocalBindAddress: " + .LocalBindAddress, "AllowExternal: " + (.AllowExternal | tostring)' /var/lib/jackett/Jackett/ServerConfig.json
systemctl show jackett -p ExecStart --value | grep -o -- '--NoUpdates'

The hash length is 128 (a SHA-512 digest), the bind address is 127.0.0.1 with AllowExternal false, and --NoUpdates confirms the self updater is off.

Jackett security posture: the AdminPassword stored as a 128 character SHA-512 hash, LocalBindAddress 127.0.0.1 with AllowExternal false, and the service started with NoUpdates

Step 9 - Sign in to the Web UI

Browse to http://<vm-public-ip>/. Jackett shows a sign in page; enter the administrator password from Step 5.

The Jackett Web UI sign in page in the browser, asking for the admin password

Once signed in, the main dashboard shows your Configured Indexers (empty on a fresh instance), the toolbar for adding indexers and running searches, and the shared API Key at the top. A panel below explains how to paste the Torznab feed into Sonarr, Radarr and other clients.

The Jackett Web UI dashboard after sign in, with the API key, the empty configured indexers table and the Add indexer, Manual Search and Test All toolbar

Step 10 - Add an indexer

Click Add indexer to open the tracker catalogue. Jackett ships with definitions for hundreds of public and private trackers, searchable and filterable by category, type and language. Find your tracker, click the wrench to configure it (entering any site login it needs), then add it. It now appears in your Configured Indexers list.

The Jackett Add Indexer dialog listing the built in trackers with their categories, public or private type and language

Step 11 - Wire the Torznab feed into Sonarr or Radarr

Each configured indexer exposes a Torznab feed. In Sonarr or Radarr, go to Settings -> Indexers -> Add -> Torznab -> Custom, then in Jackett click the indexer's Copy Torznab Feed button and paste the URL into the app. Use your API key for the feed authentication:

sudo grep '^JACKETT_API_KEY=' /root/jackett-credentials.txt

The feed URL has the form http://<vm-public-ip>/api/v2.0/indexers/<tracker-id>/results/torznab/ and the app supplies the API key alongside it. Once wired up, Sonarr and Radarr search every configured tracker through Jackett automatically.

Step 12 - Run a manual search

The Manual Search view lets you query your configured indexers directly from Jackett, which is the quickest way to confirm a newly added tracker is returning results before you rely on it from Sonarr or Radarr. Enter a search term, optionally narrow by category, and review the normalised results.

The Jackett Manual Search view for querying configured indexers directly from the Web UI

Maintenance

  • Admin login: the per VM credentials live in /root/jackett-credentials.txt. To change the password, sign in to the Web UI and use the Set Password control, then apply the change.
  • Trackers: add, test and remove trackers from the dashboard; each exposes its own Torznab, Potato and RSS feeds for your clients.
  • Configuration and state: all runtime state lives under /var/lib/jackett; back up that directory to protect your indexer configuration.
  • Service: the unit is jackett.service, fronted by nginx.service; after any manual change run sudo systemctl restart jackett.
  • TLS: the Web UI is served over plain HTTP on port 80; front it with TLS (for example certbot with your own domain) before production use.
  • Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.