Running a Tor Relay on a Hetzner VPS

Updated: 1 month ago

In the world of privacy infrastructure, simplicity is often the ultimate sophistication. Too many relay operators over-engineer their setups, introducing unnecessary complexity that becomes a vector for failure or security breaches. This post details the architecture of PrivacyPal, a dedicated Tor relay running on a minimalist VPS hosted by Hetzner.

The philosophy here is straightforward: the relay's sole purpose is to forward traffic. It does nothing else. By stripping away non-essential services, hardening the access layer, and optimizing the kernel for network throughput, we create a relay that is resilient, secure, and efficient.

The Hardware and Environment

The infrastructure is hosted by Hetzner, a provider known for its robust European data centers. The specific instance is a vServer running on ARM64 (aarch64) architecture, powered by Neoverse-N1 CPUs. While x86 is common, ARM offers excellent power efficiency and performance-per-watt, which is ideal for a background service like a Tor relay.

The operating system is Debian GNU/Linux (Trixie), the rolling development branch of Debian. This ensures the system receives the latest kernel and package updates immediately, keeping the Tor software and security patches current running on a QEMU virtualized environment.

Resource allocation is modest but sufficient for a standard relay:

  • CPU: 2 Cores (Neoverse-N1)
  • Memory: ~3.7 GiB total (currently utilizing ~29%)
  • Storage: 37.24 GiB ext4 partition (plenty of headroom for logs and Tor data)

Security and Performance Architecture

The PrivacyPal relay employs a layered approach to security and a proactive strategy for performance tuning.

Certificate-Based SSH and Fail2Ban

Password authentication is non-existent. SSH access is restricted exclusively to certificate-based authentication, eliminating the risk of credential stuffing. Fail2Ban complements this by monitoring logs and banning IPs that exhibit suspicious behavior, creating a dynamic barrier against automated scanners.

Dual Firewall Architecture

Network filtering is enforced at two distinct layers to ensure defense-in-depth:

Hetzner Cloud Firewall (External)

Operating at the hypervisor level, this is the primary barrier. Traffic is filtered before it ever reaches the server's network interface, preventing resource exhaustion from unwanted packets. By default, only ports required for the Tor relay and SSH are permitted; all other traffic is silently dropped at the infrastructure level.

firewalld (Internal)

Running locally on the Debian host, firewalld provides fine-grained control and logging. It complements the external filter by managing dynamic rules, such as those generated by Fail2Ban to ban malicious IPs. Crucially, it acts as a safety net: if a new service starts inadvertently or a port is misconfigured, firewalld ensures it remains inaccessible unless explicitly allowed.

Network Optimization with tuned

To maximize the relay's contribution to the network, raw hardware capability isn't enough; the OS must be tuned for low-latency networking. PrivacyPal utilizes tuned, a daemon that monitors system activity and adjusts system settings dynamically.

Specifically, the system is configured with the network-latency profile. This profile optimizes the TCP stack for high-throughput, low-latency scenarios by:

  • Adjusting interrupt coalescing settings to reduce CPU overhead per packet.
  • Tuning TCP buffer sizes to handle bursty Tor traffic more efficiently.
  • Disabling unnecessary power-saving features that might introduce micro-stutters in network processing.

By running tuned in the background, the VPS adapts to the constant stream of encrypted Tor cells, ensuring that the Neoverse-N1 cores are dedicated to forwarding packets rather than managing generic system loads. This optimization is crucial for maintaining a stable exit or middle relay position, where consistent low-latency is often valued over raw peak bandwidth.

Process Isolation with debian-tor

Tor itself does not run as root. It operates under the dedicated debian-tor system user. This is a fundamental security practice that limits the blast radius of any potential compromise. If the Tor process is exploited, the attacker is confined to the permissions of the debian-tor user, not the entire system.

The root account is reserved for system administration only. The Tor daemon runs with minimal privileges, accessing only the directories it needs (/var/lib/tor, /var/log/tor) and binding only to the necessary ports.

Operational Philosophy

This Tor relay runs on a sparse configuration by design. Custom branding, aggressive bandwidth shaping, and auxiliary monitoring daemons are all excluded to reduce potential failure modes.

Longevity drives the architecture. Extended uptime without reboots or service interruptions directly benefits the Tor network's stability. The approach includes:

  • Deferring non-critical package upgrades during runtime
  • Minimizing concurrent processes
  • Relying on VPS-level bandwidth controls rather than application-layer shaping

The result is a relay capable of continuous operation for months to years without manual intervention.

See the relay performance: PrivacyPal metrics

Conclusion

The PrivacyPal relay demonstrates that effective privacy infrastructure benefits from layered simplicity and active optimization. By combining Hetzner's external firewall with firewalld, tuned for low network latency, certificate-only SSH, Fail2Ban, and proper process isolation with the debian-tor user, we achieve a system that is both secure and highly performant.

For those looking to contribute to the Tor network, the lesson is clear: strip it down, tune it up, layer it up, and let it run.