Self-host qBittorrent on Netcup — a 10 € headless seedbox with WebUI

Self-host qBittorrent on a Netcup VPS to run a headless BitTorrent client with a full WebUI, fast hashing, and an OpenVPN-routed network path — without paying a managed seedbox provider four times the monthly cost. qBittorrent is a long-running C++/Qt open-source torrent client whose qbittorrent-nox build drops the GUI entirely and runs as a small systemd service. Pair it with a 10 € VPS and you get a private seedbox you actually control.

TL;DR: Running qBittorrent on Netcup in 5 minutes

qBittorrent's headless build (qbittorrent-nox) is a C++/Qt application using libtorrent for the protocol layer. It exposes a JavaScript-heavy WebUI on port 8080 by default and is administered entirely through the browser. The May 2026 5.2.0 release added category-level share limits, asynchronous piece-hash calculation, and ARM64 builds — none of which change the install story on a Debian VPS, but all of which make running it on a small box more pleasant.

• What it is: a self-hosted, headless BitTorrent client with a browser-based admin interface.
• What it competes with: managed seedbox providers, Transmission, Deluge, rTorrent + ruTorrent.
• Hosting profile: ~150 to 400 MB RAM under realistic load, low idle CPU, hashing bursts on add and recheck, network is the bottleneck.
• Default port: 8080 for the WebUI; a separate listening port (default randomised, often pinned around 6881) for incoming peer connections.
• Persistence: a config file at ~/.config/qBittorrent/qBittorrent.conf and a data directory at ~/.local/share/data/qBittorrent.
• License: GPL-2.0 / GPL-3.0, no telemetry.

sudo apt install -y qbittorrent-nox
sudo adduser --system --group --home /var/lib/qbittorrent qbtuser
sudo -u qbtuser qbittorrent-nox
# Accept the EULA, note the temporary admin password printed to the log,
# Ctrl-C, then enable the systemd unit:
sudo systemctl enable --now qbittorrent-nox@qbtuser

Primary pick: VPS 1000 G12 — 4 vCPU, 8 GB RAM, 256 GB NVMe, around 10.37 €/month. The CPU headroom makes hashing and recheck feel instant, and 256 GB of NVMe is enough for a healthy working set if you prune what you've finished seeding.

• First month free: 5799nc17800061382
• Second code: 5799nc17718015261
• Third code: 5799nc17800061381

Introduction

People reach for a hosted seedbox for the same reasons people reach for any managed service: someone else handles the OS, someone else handles the abuse complaints, you click a button and a WebUI appears. The trade-off is that monthly cost climbs sharply once you want anything beyond the entry tier — disk above a few hundred gigabytes, a private IPv4, root access, a real CPU. By the time a seedbox provider's "1 TB SSD, gigabit, dedicated CPU" plan crosses 25 €/month, you're paying twice for the convenience.

A Netcup VPS goes the other direction. The VPS 1000 G12 sits at 10.37 €/month, ships with NVMe storage, gives you root, and is symmetrically connected to a real European backbone. Self-hosting qBittorrent on it gives you the same WebUI you'd get from a managed provider, plus the freedom to install whatever else you want on the box — a media server, a download organiser, an OpenVPN client, an rclone cron job to mirror finished downloads to cold storage.

Netcup's data centres are in Nuremberg and Vienna, on owned hardware, in jurisdictions where consumer rights and operator obligations are predictable. That predictability matters more for a torrent box than for most workloads — it lets you make sober decisions about what you put on it. This article assumes you know what you're seeding and why; the operational guidance below works equally well for Linux ISO mirrors, public-domain archives, dataset distribution, or any other lawful corner of the protocol.

What you'll get by the end: qBittorrent running headless on a Netcup VPS, the WebUI behind HTTPS via Caddy, all torrent traffic forced through an OpenVPN tunnel with a kill-switch, and a clear answer to which Netcup tier matches the size of seedbox you actually want.

What is qBittorrent?

qBittorrent is an open-source BitTorrent client written in C++ on top of the Qt framework, using libtorrent-rasterbar for the protocol layer. The desktop build ships a full Qt GUI; the headless build, qbittorrent-nox, strips the GUI and exposes the same feature set through a WebUI served by a small built-in HTTP server. It is one of the longest-lived open-source torrent clients still under active development — the project is maintained by Sledgehammer999 and a contributor community, with 5.2.0 released on 3 May 2026.

It competes, depending on the angle, with managed seedbox services (Seedbox.io, Ultra.cc), with other self-hosted clients (Transmission, Deluge, rTorrent + ruTorrent), and indirectly with the *arr stack's download-client slot. Most of the ecosystem treats qBittorrent as the default download client for Sonarr, Radarr, and Prowlarr because the WebUI exposes a stable, well-documented API.

Architecture

qbittorrent-nox is a single binary. On Debian and Ubuntu it lives at /usr/bin/qbittorrent-nox; on Arch the AUR ships a static build, and the project also publishes static linux-amd64 and (since 5.2.0) linux-arm64 builds on GitHub. State is split across two directories:

• ~/.config/qBittorrent/qBittorrent.conf — the INI-style config file, hand-editable when the WebUI doesn't expose a setting you need.
• ~/.local/share/data/qBittorrent/ — the resume data, BTM (BitTorrent metadata) store, log files, and the SQLite database introduced in the 5.x series for resume metadata. The downloads/ subtree is not here by default; you point it elsewhere from the WebUI.

The daemon listens on two ports by default: 8080 for the WebUI, and a randomised peer-listening port in the high range. The peer port is the one you forward through your VPN or, if you're going direct, open in the firewall.

License

qBittorrent is released under the GNU GPL — the project ships under both v2.0 and v3.0 dual licensing. There's no proprietary "pro" tier, no telemetry beacon, no opt-in-by-default analytics. The static builds shipped on GitHub are reproducible from source.

Why people self-host it

Three reasons, in order:

1. Cost beyond entry tier. Managed seedboxes are cheap at the smallest tier and expensive the moment you want either real disk or a real CPU. A Netcup VPS is a flat line that doesn't bend upward at the inflection point.
2. Stack control. A self-hosted torrent client lives on a box you also use for the *arr suite, Jellyfin, an rclone mount, a Caddy reverse proxy, and whatever else fits the budget. Managed seedboxes tend to give you a sandbox.
3. Network policy you set. Routing torrent traffic through your own OpenVPN provider, port-forwarding to a static peer port on the VPN's exit, and kill-switching qBittorrent if the tunnel drops is a configuration that a managed provider chooses for you. Self-hosting lets you choose it.

How to use qBittorrent

Core concepts

Five nouns cover the day-to-day vocabulary:

• Torrent — a single download/upload job, identified by an info-hash, with metadata that describes one or more files and a list of trackers and DHT peers.
• Category — a label attached to a torrent that controls the save path, the auto-add behaviour, and (since 5.2.0) per-category seed-ratio and seed-time limits.
• Tag — a free-form label on a torrent. Categories are exclusive; tags are not.
• Tracker — the HTTP/UDP coordination server for a swarm. qBittorrent supports public, private, and DHT-only torrents; private trackers disable DHT and PEX automatically.
• Save path — the directory on disk where finished and incomplete files live. Categories let you split this per content type.

The WebUI mirrors the desktop client closely: a transfer list, a sidebar of state filters (downloading, seeding, completed, paused, errored), a per-torrent details pane with file selection and tracker management, and a search panel that runs against installed search plugins.

Day-to-day workflow

The WebUI is the only daily interface. You add a torrent by URL, magnet link, or .torrent file upload; you optionally pick a category and a save path; you watch the transfer list. The *arr stack hits the API directly with a similar add-then-monitor pattern.

Operationally, the events that happen on a healthy box are minimal. A weekly check on disk usage, an occasional purge of finished torrents from the transfer list (the data on disk is independent of the entry in qBittorrent), and a glance at the log when something stalls. Tracker bans, ratio overrides, and IP filter updates are all rare-but-real maintenance items.

Integrations and extensibility

The WebUI ships a documented HTTP API at /api/v2/... that the *arr ecosystem, the qBittorrent Manager mobile apps, the qbit-manage CLI, the Cross-Seed automation, and dozens of smaller tools all consume. The API is cookie-authenticated against the same WebUI credentials.

Search plugins are Python scripts loaded from a known directory; they let qBittorrent query trackers directly from the WebUI. The plugin system is unchanged across the 4.x and 5.x lines.

For external automation, the most common pattern is a category whose "Run external program on torrent finish" hook posts to an internal webhook — typically pointing at an rclone mount, a Jellyfin scan trigger, or a Sonarr import.

Backup and operational reality

The state that actually matters is small. The ~/.config/qBittorrent/qBittorrent.conf file plus the ~/.local/share/data/qBittorrent/BT_backup/ directory together rebuild the entire torrent list — info-hashes, resume positions, trackers, categories, save paths. Back those up nightly with tar and age, ship the result off-box, and you can rebuild qBittorrent on a fresh VPS in under five minutes.

The downloads/ directory is the bulk data. That's a separate concern: if you care about the files independently of qBittorrent's metadata, sync them to object storage with rclone or to another box with restic. Most people don't — torrents are reproducible by design — and treat the disk as cache.

Two failure modes worth rehearsing: filling the disk (qBittorrent will pause torrents and shout in the log; set a low-disk-space limit per save path) and an OpenVPN tunnel dropping silently (the routing-table trick covered in the Quick Start kills the torrent traffic when tun0 goes away).

Quick Start Guide

1. Provision the box

Sign up for the VPS 1000 G12 at netcup.com using coupon 5799nc17774618550 for one free month. Drop in your SSH public key on creation, choose Debian 12 minimal as the OS, then SSH in and lock the box down:

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no

systemctl reload ssh
apt update && apt full-upgrade -y
apt install -y ufw
ufw default deny incoming
ufw allow ssh
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

The peer-listening port stays closed in UFW because all torrent traffic will exit through tun0, not eth0. The reverse proxy on 80/443 is the only inbound surface.

2. Install qbittorrent-nox

Debian 12's qbittorrent-nox package lags upstream. The cleanest way to get a current build is the static linux-amd64 binary the project publishes on GitHub. It has no dependencies beyond glibc and runs on any modern Debian or Ubuntu.

useradd --system --create-home --home-dir /var/lib/qbittorrent \
  --shell /usr/sbin/nologin qbtuser
install -d -o qbtuser -g qbtuser /var/lib/qbittorrent/downloads
curl -L -o /usr/local/bin/qbittorrent-nox \
  https://example/qbittorrent-nox-linux-x86_64
# Replace the URL above with the matching asset from the project's
# 5.2.0 release. Verify the SHA-256 against the release page.
chmod +x /usr/local/bin/qbittorrent-nox

Run it once interactively as the service user to accept the legal disclaimer and pick up the auto-generated WebUI password:

sudo -u qbtuser /usr/local/bin/qbittorrent-nox

Watch the output. Modern builds print a line like The WebUI administrator password was not set. A temporary password is provided for this session: .... Note it down. Hit Ctrl-C.

3. Run it under systemd

A service template makes restarts and per-user isolation cheap. Drop this file in:

# /etc/systemd/system/[email protected]
[Unit]
Description=qBittorrent-nox service for %i
After=network-online.target
Wants=network-online.target

[Service]
Type=exec
User=%i
ExecStart=/usr/local/bin/qbittorrent-nox --webui-port=8080
Restart=on-failure
# Uncomment if binding to a specific network interface (e.g. tun0):
#AmbientCapabilities=CAP_NET_RAW

[Install]
WantedBy=multi-user.target

Then:

systemctl daemon-reload
systemctl enable --now qbittorrent-nox@qbtuser
journalctl -u qbittorrent-nox@qbtuser -f

The unit is a template (@-suffixed) so you can run multiple instances under different users if you ever want a second isolated profile. For a single-user box, one instance is enough.

4. Set the permanent WebUI password and pin the ports

Open http://<box-ip>:8080 over an SSH tunnel for now (ssh -L 8080:127.0.0.1:8080 root@your-box), log in with the temporary password, and head to Tools → Options → Web UI. Set a real password, then jump to BitTorrent and pin the peer port to something memorable in the 49152-65535 range — say 54321.

While you're there, in Connection, leave Network interface on "Any" for now. We'll change this to tun0 after OpenVPN is up, in step 6.

Stop the service before continuing so the next steps can edit the config file safely:

systemctl stop qbittorrent-nox@qbtuser

5. Reverse proxy with Caddy

Caddy fetches Let's Encrypt certs the first time it sees an HTTPS request — no certbot, no cron, no expiry surprises.

apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' \
  | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' \
  | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

# /etc/caddy/Caddyfile
qbit.example.com {
    reverse_proxy 127.0.0.1:8080
    # Long-lived torrent uploads through the WebUI need bumped limits:
    request_body {
        max_size 1GB
    }
}

systemctl reload caddy

In qBittorrent's WebUI, go back to Tools → Options → Web UI and tick Use HTTPS is off — Caddy terminates TLS, qBittorrent stays on plain HTTP behind it. Tick Bypass authentication for clients on localhost if you want the *arr stack on the same box to skip the login.

6. Route everything through OpenVPN

This is the part that turns the box from "a torrent client on a public IP" into "a torrent client whose traffic exits through your VPN provider with a hard kill-switch". The technique is from the qBittorrent wiki and works against any OpenVPN provider that gives you a static client IP and supports port forwarding.

Install the OpenVPN client and drop your provider's .ovpn config in /etc/openvpn/client/torrentvpn.conf. Start the tunnel:

apt install -y openvpn
systemctl enable --now openvpn-client@torrentvpn
ip addr show tun0

You should see tun0 come up with the VPN-assigned address — call it 10.8.0.2. Now create a dedicated routing table that only qbtuser's traffic touches:

echo '200 vpn' >> /etc/iproute2/rt_tables
ip rule add from 10.8.0.2 table vpn prio 1
ip route add default via 10.8.0.1 dev tun0 table vpn

The from 10.8.0.2 rule means: any packet whose source IP is the VPN-assigned address gets routed through tun0. If the tunnel goes down, the source IP disappears, the rule has nothing to match, and qBittorrent's connections quietly fail. That's the kill-switch.

Finally, bind qBittorrent to tun0 so it picks 10.8.0.2 as its source. Edit the config file:

# /var/lib/qbittorrent/.config/qBittorrent/qBittorrent.conf
[BitTorrent]
Session\Interface=tun0
Session\InterfaceName=tun0
Session\InterfaceAddress=10.8.0.2

Uncomment AmbientCapabilities=CAP_NET_RAW in the systemd unit (so the unprivileged service can bind to the named interface), then restart:

systemctl daemon-reload
systemctl restart qbittorrent-nox@qbtuser

Confirm the WebUI's status bar shows the VPN's external IP, not Netcup's.

7. Back the metadata up

The whole point of self-hosting is being able to redo it. A nightly cron that snapshots the qBittorrent profile and ships it to cheap object storage covers the worst case (box dies, replace it):

# /etc/cron.daily/qbittorrent-backup
#!/bin/sh
set -e
DEST=/var/backups/qbittorrent
mkdir -p $DEST
tar -czf $DEST/profile-$(date +%F).tar.gz \
  -C /var/lib/qbittorrent/.config qBittorrent \
  -C /var/lib/qbittorrent/.local/share/data qBittorrent
find $DEST -type f -mtime +14 -delete

Then rclone copy or restic backup the directory off-box on the same schedule.

Choosing the Right Netcup Server for cheap qBittorrent hosting

qBittorrent's CPU and RAM footprint is modest. Disk size and (implicitly) sustained throughput are the dimensions that should move you up the tier ladder. The right pick depends on whether you're seeding a small, hand-curated set or running closer to a private archivist's library.

VPS 500 G12 — the starter tier, with caveats

Specs: 2 vCPU, 4 GB RAM, 128 GB NVMe. Around 5.91 €/month (verify on netcup.com).

The cheapest tier hosts qBittorrent fine from a CPU and RAM perspective, but 128 GB of NVMe is the binding constraint. After the OS, swap, OpenVPN, Caddy, and a backup directory, you've got roughly 100 GB of usable download space. That's enough for a hand-curated seed list — a few dozen Linux ISOs, a working set of public-domain media — and not much more. There is no dedicated VPS 500 coupon category; the 5 € off any order coupon stacks against this tier.

Coupons:

• 36nc17718015547
• 36nc17718015541
• 36nc17718015544

VPS 1000 G12 — recommended for most qBittorrent deployments

Specs: 4 vCPU, 8 GB RAM, 256 GB NVMe. Around 10.37 €/month (verify on netcup.com).

The price-to-disk-per-euro sweet spot. Four shared vCPUs eat hashing and rechecks without flinching, 8 GB of RAM gives libtorrent plenty of cache for the piece-picker, and 256 GB of NVMe holds a healthy working set if you prune what you've finished seeding. Comfortable home for qBittorrent plus an *arr stack plus a Jellyfin instance pulling from the same disk.

Coupons:

• 5799nc17800061380
• 5799nc17804382700
• 5799nc17800061382

VPS 2000 G12 — for larger libraries

Specs: 8 vCPU, 16 GB RAM, 512 GB NVMe. Around 19.25 €/month (verify on netcup.com).

Twice the disk for less than twice the price. The sensible move once your active seed list pushes past 200 GB or you're running multiple *arr instances on the same box. The CPU and RAM jumps are bonus headroom that mostly help when adding a torrent of a few hundred thousand files (the 5.2.0 async-hash work helps here too).

Coupons:

• 5800nc17802654091
• 5800nc17718015232
• 5800nc17718015233

VPS 4000 G12 — when you're closer to "archive" than "seedbox"

Specs: 12 vCPU, 32 GB RAM, 1024 GB NVMe. Around 32.41 €/month (verify on netcup.com).

A terabyte of NVMe is enough for most personal archives without the rotational-disk awkwardness of a budget storage box. Worth it when the working set is well above half a terabyte and you'd rather throw more disk at the problem than build out an off-box archival tier.

Coupons:

• 5801nc17779092600
• 5801nc17800061390
• 5801nc17797900830

If you're trying qBittorrent self-hosting for the first time and want to feel out whether you actually want a seedbox, start on VPS 500 G12 with the 5 € coupon and accept the disk constraint as a forcing function for tidy seed-list hygiene. If you've outgrown a managed seedbox and want a real workstation for your *arr stack plus qBittorrent, VPS 1000 G12 is the answer — ten euros for two-and-a-half times the disk a budget seedbox tier gives you. If you're operating a private archive with collaborators and need disk for the long tail, jump straight to VPS 2000 G12 or VPS 4000 G12 and skip the migration in six months.

The Root Server tiers exist for CPU-bound workloads. qBittorrent is not one — the hashing bursts are real but short, and shared vCPUs handle them fine. Stick with VPS for this use case unless you're co-locating something genuinely CPU-hungry on the same box.

Conclusion

You now have a path from a fresh Debian image to qBittorrent running headlessly under systemd, accessible through HTTPS via Caddy, and with all torrent traffic forced through an OpenVPN tunnel that fails closed. The recommended path — VPS 1000 G12 with the dedicated coupon for a free first month — lands at roughly 10.37 €/month afterwards, plus whatever your VPN provider charges. That is reliably less than a managed seedbox at the same disk and CPU tier, and the box doubles as a host for the rest of your self-hosted stack.

Worth one final 5 € off any order: 36nc17718015543. Stack it against an annual prepay if you want to lock the price in for a year.

Two things to keep an eye on once it's running: disk usage (qBittorrent will pause everything when the save path's filesystem hits a free-space floor — set the floor explicitly per save path so the WebUI tells you about it before the OS does) and OpenVPN tunnel health (the routing-table trick kills outbound torrent connections silently when tun0 goes away, which is the safe behaviour but means you should monitor tun0 separately if uptime matters to you).