Hedgehog
AI Network 

How the Hedgehog Fabric Works

Standard enterprise networks rely on fragile, element-by-element CLI configuration. Hedgehog replaces this with a continuous, intent-based software architecture built entirely on Kubernetes.

• The Fabric Controller: At the heart of the Hedgehog architecture is a dedicated Control Node running Kubernetes and the Hedgehog Fabric Controller.
• Declarative Intent via CRDs: Operators interact natively with the Kubernetes API, declaring network intents—like VPCs, peerings, and Gateways—as standard Custom Resource Definitions (CRDs).
• Continuous Reconciliation: The Fabric Controller translates these intents into exact per-switch configurations. A lightweight Hedgehog Agent running on each switch continuously reconciles the declared state against the physical hardware, ensuring your network always matches your intent.
• Gateway Nodes: Dedicated, high-performance Gateway nodes sit at the edge of the fabric, providing stateful NAT, firewalling, and seamless external connectivity to the rest of your grid.

Key Design Principles

We built Hedgehog on the following core tenets to bridge the gap between bare-metal AI performance and cloud-native agility.

• Freedom to Choose: Choose your switches and your preferred NOS, and change them freely down the line. No layer is a hostage. Where the software is ours, the source is open, allowing you to verify exactly what the system is meant to do rather than just trusting that it does. This commitment to choice keeps us honest twice over: on price, because you can always leave, and on behavior, because you can always look.
• Manage Outcomes, Not Network Gear: Declare what you need, like a VPC or a service insertion, and the fabric handles the underlying routing, addressing, and per-switch state. We deliver true cloud abstraction: opinionated cloud constructs instead of protocol soup. This works because our software is rigorously tested and open-source. When something breaks, you can see what the fabric intended versus what it did.
• Best-in-Class, Not Built-in-House We don’t rebuild infrastructure that already works. Our control plane is a Kubernetes API; our observability relies on the LGTM stack. By integrating with the tools and skills your team already possesses, we focus our engineering purely on the network—instead of reinventing inferior versions of everything around it.
• Secure from the Ground Up Multi-tenancy is an assumption, not an add-on. Tenant isolation lives in the same declarative model as everything else and is enforced in the data plane, Workloads, models, and data remain separated by architectural design—never by a fragile config you just hope someone set correctly.
• Hyperscale Engineering for the Rest of Us Hyperscalers run networks like software—version-controlled, pipelined, and deeply observed—using massive teams. We built that operating model directly into our product, minus the headcount. We lead with an API because real operations run on Infrastructure-as-Code, not clicking through GUI screens at 2 AM. Built for Day Two, not the keynote.
• Two Switches or Two Thousand The exact same system runs a two-switch lab and a two-thousand-switch cluster. Scale up to massive build-outs without control-plane bottlenecks, or start small and grow into production on the same fabric. Zero re-platforming required on the way up.