arch-delugevpn, a container that runs Deluge behind a VPN

What the image contains and the problem it solves

This is a Docker build script for an Arch Linux base with Deluge, Privoxy and OpenVPN, and the newer versions also add WireGuard and microsocks.

The components are each doing a specific job. Deluge is a full-featured BitTorrent client for Linux, macOS, Unix and Windows, using libtorrent in its backend, with GTK, web and console interfaces. It is built on the client server model, so a daemon process handles all the BitTorrent activity while the interfaces connect to it remotely, which is why the daemon model suits a container.

OpenVPN and WireGuard provide the tunnel. Privoxy provides an HTTP proxy to allow unfiltered access to index sites, and the README gives the address format to point an application at. microsocks is a SOCKS proxy, which handles the case where an application speaks SOCKS rather than HTTP.

The part that makes this project worth the attention is the leak protection. The README says the image includes OpenVPN and WireGuard to ensure a secure and private connection, including the use of iptables to prevent IP leakage when the tunnel is down.

That is the actual problem. A torrent client configured to use a VPN will happily send traffic outside the tunnel if the tunnel drops and the routing is not handled, and a stray DNS request or a connection to a peer over the raw interface is enough to associate your real address with the traffic. A kill switch is not a feature of the VPN client, it is something the container has to implement, and this one does it with firewall rules.

The trade is that the container needs elevated privileges to manage those rules, which is why the run command passes --cap-add=NET_ADMIN. That capability gives the container permission to change the network configuration, which is exactly what is needed and also exactly what is worth understanding before you run it.

The environment variable surface

The container is configured entirely through environment variables, and the list in the README is the real documentation for the project. There are around thirty of them, and they group into a few areas.

The VPN settings are the core. VPN_ENABLED turns the tunnel on, VPN_USER and VPN_PASS are the credentials, VPN_PROV selects the provider with the choices being pia, airvpn, protonvpn or custom, and VPN_CLIENT chooses the protocol between openvpn and wireguard. VPN_OPTIONS passes additional command line options to OpenVPN, and VPN_INPUT_PORTS and VPN_OUTPUT_PORTS let you tell the client which ports to use.

Then there is the set of switches that decide what the container does besides the torrent client. ENABLE_STARTUP_SCRIPTS controls the startup scripts, ENABLE_PRIVOXY turns the HTTP proxy on, ENABLE_SOCKS turns the SOCKS proxy on with SOCKS_USER and SOCKS_PASS, and STRICT_PORT_FORWARD changes how port forwarding behaves. USERSPACE_WIREGUARD is the flag for running WireGuard in userspace rather than in the kernel, which matters on a host where the WireGuard module is not loaded and you cannot load modules inside a container.

The leak protection has its own variable. LAN_NETWORK takes a LAN IPv4 network in CIDR notation, and that is the address range the kill switch has to permit so local traffic keeps working while everything else is blocked when the tunnel is down.

Then there is the Deluge configuration, with DELUGE_DAEMON_LOG_LEVEL and DELUGE_WEB_LOG_LEVEL for the two log levels, and DELUGE_ENABLE_WEBUI_PASSWORD to turn the web interface password on. That last one is worth noting, because the README also states the default password for the web interface is deluge, so leaving it disabled means anyone who can reach the port gets in.

The rest is operational. NAME_SERVERS sets the resolvers, UMASK sets the file creation mask, PUID and PGID set the user and group the process runs as so the mounted volumes are owned correctly, DEBUG turns on verbose output, and HEALTHCHECK_COMMAND, HEALTHCHECK_ACTION and HEALTHCHECK_HOSTNAME configure the built-in health check. The presence of a configurable health check is a good sign, because it is what lets an orchestrator restart a container whose tunnel has died.

Running it and the port mapping

The usage section gives the full run command as a text block, with every port and volume spelled out, and then a shorter concrete example for PIA.

The ports are the ones to understand. 8112 is the Deluge web interface, 8118 is the Privoxy HTTP proxy and 9118 is the microsocks SOCKS proxy. Then 58846 and 58946 appear, the latter twice, once for TCP and once for UDP.

The duplicate 58946 mapping in the README's command is a typo rather than a design, and it is the kind of thing worth noticing if you are copying the command from the README.

The volumes are the other half. A path for data files is mounted at /data and a path for config files at /config, and /etc/localtime is mounted read-only so the container's clock matches the host's. The first two are the ones that matter, because a container without them loses every torrent and setting when it is recreated.

The health check deserves a mention because it is the mechanism that ties back to the kill switch. If the health check command detects that the tunnel is down and the action is to restart the container, then the combination of the two gives a self-healing property: the container does not sit there with the torrent client running outside the VPN while the connection is down.

The README also gives the access details for each service, with the Deluge web interface at the host address on port 8112 and the default password of deluge, Privoxy at 8118, and microsocks at 9118 with the credentials admin and socks.

The releases show how actively this is maintained. The version 2.2.0 has several point releases in quick succession, and the tags are labelled with how they were made: 2.2.0-8-01 is marked as an API or URL triggered release on 2026-10-18, while 2.2.0-7-09 and 2.2.0-7-08 are marked as manual releases. The last push was the same day as the most recent release.

The concrete PIA example in the README is the shortest complete invocation:

docker run -d \
    --cap-add=NET_ADMIN \
    -p 8112:8112 \
    -p 8118:8118 \
    -p 9118:9118 \
    -e VPN_ENABLED=yes \
    -e VPN_PROV=pia \
    -e VPN_CLIENT=openvpn \
    -e ENABLE_PRIVOXY=yes \
    -e STRICT_PORT_FORWARD=yes \
    -e ENABLE_SOCKS=yes \
    -v /apps/docker/deluge/data:/data \
    -v /apps/docker/deluge/config:/config \
    binhex/arch-delugevpn

Read it as a checklist rather than a single command. The first line grants the container permission to manage firewall rules, and the next three publish the web interface and the two proxies. The environment block selects the provider, the protocol and the leak protection behaviour. The two volume mounts are what make the install persistent, and without them every torrent and every setting disappears when the container is recreated.

How it compares with the alternatives

The first alternative is a torrent client image that manages its own VPN tunnel, with the routing and the kill switch living inside the client rather than wrapping the whole container.

In this image, the tunnel is a separate concern from the application, and the firewall rules are written to cover the whole container. That is a more thorough arrangement than routing the torrent client's traffic through a proxy, because it also covers DNS and any connection the application opens. It is also more configuration, because the container has to bring up the tunnel, wait for it, keep it alive and enforce the rules, and every one of those steps is a place where a mistake means traffic escapes.

The second alternative is a SOCKS or HTTP proxy with a torrent client configured to use it, and that is what the Privoxy and microsocks components enable. The advantage is that it works with any torrent client and does not require elevated capabilities. The disadvantage is that it only protects traffic that is configured to go through the proxy, so a client that ignores the proxy setting sends its traffic in the clear, and DNS can still leak.

The third alternative is a dedicated VPN client with a built-in kill switch, run on the host, with the torrent client in a container that routes through the host's tunnel. This is the cleanest arrangement from a security point of view, because the host owns the network and the container inherits it, but it requires a host that is not itself a container, and it moves the configuration to the host rather than the image.

The honest limitations of this project are the age of the stack and the size of the configuration surface. Deluge is no longer the leading torrent client, the image tracks the latest stable releases from the Arch Linux repos, which means it follows upstream fixes rather than pinning versions. Around thirty environment variables, each of which has to be right for the kill switch to behave, is a lot of surface for something where a single mistake is a privacy failure rather than a crash.

What the project does well is the specific thing it exists for. If your requirement is that a torrent client cannot leak its address when the tunnel drops, and you want that guarantee to come from firewall rules rather than from the client's configuration, this does it in a way you can read.

Editorial conclusion

Adopt arch-delugevpn if you want a torrent client whose traffic cannot escape when the VPN drops, and you are comfortable with a large environment variable surface and a container that needs NET_ADMIN. Skip it if you want a general purpose VPN client or a modern torrent client with a clean web interface, since Deluge is old and this image is a fixed Arch snapshot. Verify first by running the container with the health check enabled, confirming the kill switch behaviour by stopping the tunnel, and checking that the exposed ports are the ones you actually need.

Frequently asked questions

Official sources

1. binhex/arch-delugevpn on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases