Running a Tor Relay on a Minimalist Hetzner VPS

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 (forky/sid), 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.

1. Dual Firewall Layer

Network filtering is implemented at two distinct levels, providing redundancy and defense in depth:

Hetzner Firewall (External) — The first line of defense sits outside the VPS entirely. Hetzner provides a configurable firewall at the hypervisor level that filters traffic before it even reaches the server's network interface. This is critical: unwanted traffic is dropped before consuming any server resources. Only the ports required for the Tor relay and SSH are allowed through; everything else is silently discarded at the infrastructure level.

firewalld on the Server (Internal) — As a second layer, firewalld runs on the VPS itself. While the Hetzner firewall handles the coarse-grained filtering, firewalld provides fine-grained control and logging on the host. It ensures that only the expected services are reachable and acts as a safety net—if a new service is accidentally started or a port is inadvertently opened, firewalld blocks it regardless.

2. 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.

3. 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.

4. 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.

Operational Philosophy

The configuration of the Tor relay itself is intentionally sparse. There is no custom branding, no complex bandwidth shaping beyond what the VPS provider allows, and no auxiliary monitoring daemons that could crash the system.

The goal is longevity. The longer the relay runs without a reboot or service interruption, the more stable it is for the Tor network. By avoiding unnecessary package upgrades during runtime (unless critical security patches are required) and minimizing the number of running processes, the system achieves a high degree of stability.

With the current architecture the relay is positioned to run for months or years without intervention.

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.

Note: This setup is specific to the Hetzner vServer environment. Users attempting to replicate this should ensure they understand the implications of SSH certificate management, the importance of running Tor under a dedicated, unprivileged user account, and the value of using tuned profiles to optimize network performance for specific workloads.