Deluge on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Deluge on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Deluge is a popular, lightweight, cross platform open source BitTorrent client. It uses a client and server design: the deluged daemon handles all downloading and seeding, while the deluge-web browser Web UI lets you add torrents and magnet links, organise downloads, and set bandwidth and connection limits from anywhere.

The image installs the pinned stable Deluge 2.2.0 from PyPI into a dedicated virtual environment (recorded in /opt/cloudimg/deluge-VERSION) and runs deluged and deluge-web under systemd as the unprivileged deluge system user, both bound to loopback only (the Web UI on 127.0.0.1:8112, the daemon RPC on 127.0.0.1:58846). nginx is the sole network facing surface: it terminates TLS on port 443, enforces HTTP basic authentication on every request and reverse proxies to the Web UI. Port 80 redirects to HTTPS.

Secure by default. A standard Deluge Web UI ships with a well known default password (deluge), which would leave an unprotected deployment open to anyone who can reach it. This image does not rely on that. The daemon and Web UI are bound to loopback and fronted by nginx basic authentication, and the Web UI password, the daemon connection secret and the basic authentication credential are all rotated to unique random values on each virtual machine's first boot. Only one way hashes are written to the server (bcrypt in the nginx password file, salted SHA-1 in the Web UI config); the plain password is placed in a root only file for the administrator to read. There are no shared or default credentials, and nothing usable is baked into the image.

What is included:

• Deluge 2.2.0 (the current stable release, ahead of the older snapshot in the distribution archive) installed into a dedicated venv and run under systemd as the unprivileged deluge system user

• deluged (RPC on 127.0.0.1:58846) and deluge-web (127.0.0.1:8112) bound to loopback only; neither is network exposed directly

• nginx terminating TLS on :443, enforcing HTTP basic authentication and reverse proxying to the Web UI, with HSTS and sensible security headers

• Port :80 returns a 301 redirect to HTTPS for every path except an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• The default deluge web password rotated away and a unique admin credential generated per VM on first boot; only one way hashes are stored, the plain password lands in a root only file

• A self signed TLS certificate regenerated per VM on first boot (its Subject Alternative Names include the VM public IP, hostname and 127.0.0.1); replace it with your own CA signed certificate for production

• The Web UI pre configured to auto connect to the local daemon, so a working client is ready the moment you sign in

• A built in self test at /usr/local/bin/deluge-selftest that proves the authenticated round trip end to end over TLS, including that the default password is rejected and the per VM password is accepted

• 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 443 (HTTPS) and 80 (redirect) 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 Deluge 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 443 and 80 from your users, and restrict 22 to your management network.

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

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 deluge \
  --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 deluge --port 443 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name delugeNSG \
  --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 https://<public-ip>/.

Step 3: Retrieve your per instance credential

Access is protected by HTTP basic authentication and the Deluge Web UI login. Each VM generates its own admin username and password on first boot, written to a root only file. Read it over SSH:

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

The file contains the DELUGE_USER, DELUGE_PASS and DELUGE_URL for this specific VM. The same password is used for both the outer nginx basic authentication prompt and the Deluge Web UI login, so you only need to remember one secret. Keep it private. The server only ever stores one way hashes of the password, never the plain text.

Step 4: Sign in to the Web UI

Browse to https://<vm-ip>/. Because the certificate is self signed per VM, your browser will show a certificate warning the first time; accept it to proceed (or install the per VM certificate, or place a CA signed certificate in front, as covered in Step 9). Your browser then prompts for the basic authentication username and password from Step 3, and the Deluge Web UI login page asks for the same password.

Step 5: The Deluge Web UI

After signing in, the Deluge Web UI opens on the main window. The image pre configures the Web UI to connect automatically to the local daemon, so you are ready to add torrents immediately. The toolbar along the top has buttons to add, pause, resume and remove torrents, the torrent list fills the centre, and a status bar along the bottom shows connection, download and upload rates.

Step 6: Add a torrent or magnet link

Click Add on the toolbar to open the Add Torrent dialog. You can paste a magnet link with Add from URL, upload a .torrent file, and choose the download location and options before adding. Deluge downloads the files into the daemon's download directory (/var/lib/deluge/Downloads by default).

Step 7: Set preferences and download location

Click Preferences to open the settings dialog. From here you can change the default download location, set global and per torrent bandwidth limits, configure connection and port settings, and enable plugins such as scheduling, labels and RSS. Changes apply to the running daemon.

Step 8: Verify the deployment

SSH to the VM as azureuser and confirm the services are running and Deluge is bound to loopback only:

systemctl is-active deluged deluge-web nginx
sudo ss -tlnp | grep -E ':(8112|58846)'

All services report active, the Web UI listens on 127.0.0.1:8112 and the daemon RPC on 127.0.0.1:58846 only. nginx is the only component exposed on :80 and :443.

Run the built in self test. It reads this VM's credential and proves the full path over TLS: the health probe answers, an unauthenticated request is refused, the old default password deluge is rejected by the Web UI, the per VM password is accepted, and the local daemon is registered:

sudo /usr/local/bin/deluge-selftest

Step 9: TLS, redirect and the authentication gate

nginx terminates TLS on port 443 and redirects plain HTTP on port 80 to HTTPS. Confirm the redirect, the unauthenticated health probe, and that the Web UI requires the per VM credential:

curl -s -o /dev/null -w 'port 80 -> HTTP %{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'healthz -> HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'no creds -> HTTP %{http_code}\n' https://127.0.0.1/

Port 80 returns 301 and the health endpoint returns 200. An unauthenticated request to the Web UI is refused with 401, while a request carrying this VM's credential succeeds with 200. The self signed certificate is regenerated per VM on first boot, with the VM IP and hostname in its Subject Alternative Names.

Step 10: Replace the certificate for production

The per VM certificate is self signed, so browsers warn on first use. For a public deployment, put a real certificate in front. The simplest path is to point a DNS name at the VM and obtain a free certificate with Certbot:

# Point https://<your-domain> at this VM first, then:
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Alternatively, terminate TLS at an Azure Application Gateway or a load balancer in front of the VM and forward to port 443.

Step 11: Baked version and per instance credential

The baked Deluge, libtorrent and Python versions are recorded on the VM, alongside this instance's credential summary. The password line is redacted below; read the full value from the root only file in Step 3:

cat /opt/cloudimg/deluge-VERSION
sudo cat /root/deluge-credentials.txt

Security notes

• No default login. The well known default Deluge web password deluge is rotated away on first boot. Access is protected by nginx HTTP basic authentication and the Deluge Web UI login, both using a unique credential generated on each VM's first boot. Only one way hashes are stored; the plain password lives in the root only /root/deluge-credentials.txt.

• Loopback only application. deluge-web binds 127.0.0.1:8112 and deluged binds 127.0.0.1:58846; both are only reachable through the nginx TLS reverse proxy on :443. Keep it that way and let nginx (or a load balancer) be the sole network facing surface.

• Restrict access. Allow 443 only from the networks that need it, keep 22 restricted to your management network, and replace the self signed certificate with a CA signed one for production.

• Rotate the credential by regenerating the nginx htpasswd entry (sudo htpasswd -B /etc/nginx/deluge.htpasswd admin) and reloading nginx, and by changing the Web UI password from the Preferences dialog.

• Lawful use. Use Deluge only to download and share content you are legally permitted to. You are responsible for complying with copyright law and your provider's acceptable use policy.

Support

This image is backed by 24/7 cloudimg support with a guaranteed 24 hour response SLA. Contact support@cloudimg.co.uk for assistance. Deluge 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.