Hedgehog 26.05 is available now. We didn't write up 26.04 when it shipped in September, so this post covers both releases. Together they do two things for GPU cloud operators and enterprise AI teams.
First, you can run a much bigger AI factory with the same small team. One controller now manages up to 500 switches across every network in the cluster, and each gateway node moves about 4x the traffic it did before.
Second, you can give tenants the security practices they already rely on in their own data centers: segmentation, defense in depth and enforcement that doesn't depend on the host it protects. The gateway now applies connection-aware rules on every peering and enforces the most critical rules in NIC hardware at line rate.
Run roughly 8,000 GPUs and all their networks from one controller. A single Hedgehog controller is now validated with up to 500 switches, 60,000 Connections and 50,000 VPCAttachments. In a quad-plane NVIDIA GB300 NVL72 design, that is roughly 8,000 GPUs and their front-end network. Larger clusters add controllers, and each controller runs independently, so you grow to thousands of switches without re-architecting.
Stop running a separate deployment for every network. AI clusters keep splitting into specialized networks: front end, storage, management and multi-plane GPU backends. One Hedgehog deployment can now manage multiple fabrics, and a spine-leaf fabric can have multiple domains, so you get one API, one inventory and one upgrade for all of them. Multi-plane backends put dedicated spines on each plane with shared leaves, which adds GPU bandwidth without a third tier of switches and lets different accelerator types sit on their own planes. Existing deployments move to a default fabric and domain automatically on upgrade. Multi-fabric docs
Move datasets, checkpoints and inference traffic with fewer gateway nodes. DPDK is now the primary and recommended gateway dataplane driver. One gateway node moves 157+ Gbps (13.6+ Mpps) across many flows at a 1500-byte MTU, about 4x the previous gateway, and a single TCP flow runs at 16 to 18 Gbps. Inside the data center at a 9000-byte MTU, the same node reaches 300+ Gbps across many flows and 69 to 70 Gbps on a single flow. The same traffic takes fewer servers, less rack space and less power. Figures are TCP goodput measured with iperf3 on one bare-metal gateway (AMD EPYC 9555P, 32 workers, NVIDIA ConnectX-7 2x200G), with or without masquerade NAT. Gateway docs
Enforce tenant policy at a point no tenant host can change. Every packet that leaves a tenant VPC for another tenant, another site or an external model or tool crosses a Hedgehog gateway peering, which makes the gateway the place to control what tenants and AI agents can reach. In 26.05 that control gets sharper. Stateful rules now work on any peering regardless of NAT mode, so you can allow only replies to connections that started inside the VPC. Gateway ACLs can match TCP flags, so you can block new inbound connections on a port without putting a separate firewall in the path. This builds on the firewall for VPC peering we introduced in 26.03.
Keep critical rules enforced at full speed, even under abuse or attack. The gateway now offloads ACL rules that don't need a flow-table lookup to the NIC itself, where they run at the full 400 Gbps of an NVIDIA ConnectX-7. Traffic that doesn't belong is dropped in hardware before it reaches the gateway's CPU, so legitimate traffic keeps flowing. Any rule the NIC can't take falls back to software, so policy is always enforced. Combined with VPC segmentation in switch hardware, a tenant boundary is enforced at two independent layers, and neither one runs on the server it protects.
Stop one heavy tenant from starving a shared gateway. 26.05 includes the first release of rate limiting for gateway peerings, by bits or packets per second with bursts allowed. It is experimental in this release, and development continues in future releases. If you want to try it, including in NIC hardware, talk to us.
Scale stateless gateway traffic across every gateway in the group. Since 26.04, stateless peerings (those with no stateful NAT and no stateful ACLs) are handled by all gateways in a group at the same time using ECMP. You add throughput by adding gateways, and traffic is no longer pinned to one node. It is on by default and can be turned off per peering. Gateway failover docs
Give tenants direct peer-to-peer VPN connections. Masquerade NAT now uses Endpoint-Independent Mapping per RFC 4787 and RFC 5382. Tailscale, NetBird, ZeroTier and WebRTC behind the gateway connect directly at full network speed, with no relay servers to run or pay for and no special configuration.
Add networks, planes and cabling with less IP planning. Fabric and mesh links now use BGP unnumbered by default (experimental in 26.04), so spine-leaf links no longer need IP addresses allocated. That is one less spreadsheet to maintain and one less place to make a mistake when you expand.
Find the bad cable or optic without sending someone to look. 26.04 expanded LLDP and transceiver telemetry in Prometheus and the API. LLDP neighbors now show the neighbor MAC, a readable port name, advertised TTL and last update time, and transceivers report part and serial numbers. You can audit cabling and track optics inventory from your existing dashboards. LLDP docs
Share diagnostics without sharing secrets. Support dumps are now compressed, include more cluster state and redact credentials, and they extract into a file tree you can browse. Support dump docs
Tune failure detection per external connection. BFD is now configurable per External attachment, falling back to fabric defaults, so you can match each upstream provider's timers.
A few things to know before you upgrade:
Read the full 26.05 release notes for the complete list and software versions. Please reach out with questions or if you want a hand planning your upgrade.