Hetzner Cloud provides virtual machine hosting services where reliable network connectivity is essential for customers to reach their applications from anywhere. The company's approach has consistently favored placing network functionality on the host systems rather than in the physical network infrastructure, believing this offers greater flexibility and clearer separation of concerns between teams. This philosophy shaped the evolution from early vServer offerings using native Linux bridges and static routes (2011) through a Ceph-based hyperconverged setup with BGP routing (2015) to the direct IPv4 routing adopted when Hetzner Cloud launched in 2018.
This image illustrates the initial network design described in the article, where Hetzner Cloud placed network functionality on host systems using native Linux bridges and static routes for its early vServer offerings.
At the core of Hetzner Cloud's current network stack is Open vSwitch (OVS), an open-source multilayer virtual switch whose data path resides in the Linux kernel. Rather than adopting standard orchestration solutions like Open Virtual Network (OVN), Hetzner developed a custom Python-based controller named Flusskrebs that configures the specific OpenFlow rules each virtual machine requires. These flows implement public network access, private VXLAN-encapsulated networks (using unique VNIs per network), and user-configured firewall rules including default egress SMTP blocking. Each host connects via dual 10 Gb/s uplink interfaces (currently bonded via LACP/LAG but migrating to independent BGP-routed paths) that route through the Linux system before reaching the central OVS bridge where virtual machines attach their network interfaces.
This image depicts the core components of Hetzner Cloud's modern network stack as explained in the article, including OVS, Flusskrebs, and VXLAN-based private networks.
Despite supporting over a million cloud servers, the current OVS-based architecture faces scalability, resiliency, and flexibility challenges that motivate Hetzner's SDN team to build a new, fully self-designed network stack. A concrete example of these constraints is the connection tracking limit: to prevent netfilter table overflow and ensure fair resource sharing, an internal tool called ctcount enforces a maximum of 80,000 active concurrent connections per server. When this limit is reached, no new connections can be established until existing ones are closed. The ongoing development aims to create a solution tailored to Hetzner's operational requirements while improving scalability and enabling features like IPv6 support for private networks.