How Durantic works.
The control plane Durantic runs underneath managed AI infrastructure. Four pillars — provisioning, networking, day-2 operations, and storage — that let one team operate heterogeneous GPU fleets at scale.
From power-on to workload-ready in under two minutes
Zero-touch hardware discovery. OCI-native images. PXE optional, not required.
PXE boot servers that need DHCP and TFTP infrastructure. IPMI that’s flaky, vendor-specific, and often behind a VPN. USB sticks shipped to remote hands. Custom kickstart scripts per provider, per OS version, per hardware generation. Scaling from 10 to 50 machines isn’t 5× the work — it’s 50 unique snowflakes that all break differently.
LinuxBoot firmware integration
On supported hardware, Durantic integrates at the firmware level via LinuxBoot — the same open-source foundation that Google, Meta, and ByteDance use on their production server fleets. A new machine powers on, contacts the control plane, inventories its hardware (GPUs, NICs, NVMe, CPU topology, PCIe layout), and appears in the management interface ready for provisioning. No pre-registration, no MAC address entry.
OCI-native OS images
OS images are standard Docker images. Build your server OS as a Dockerfile — the same workflow developers already know. Push to any container registry. Durantic pulls and installs in about 60 seconds of installer work. Full cloud-init support means the same userdata scripts you use on AWS or GCP work identically on bare metal — no provider-specific first-boot logic required.
Bootstrap and reprovisioning
SSH into any running Linux with a single curl command, attach an installer ISO via BMC virtual media, or PXE netboot in legacy environments. Every method produces an identical result. Reprovisioning works the same way — the agent receives a command, reboots, and the machine comes back as whatever you need it to be. About 60 seconds of installer work, plus a firmware reboot.
Composable machine roles
Define reusable roles — Kubernetes worker, GPU compute node, storage gateway — as Jinja2 cloud-init templates with full access to machine context: hardware specs, mesh topology, secrets, and peer information. Assign multiple roles to a machine; Durantic deep-merges them by priority into a single deterministic config. Start from official curated roles or write your own. One template works across x86_64 and ARM64, bare metal and cloud.
Hardware acceptance & burn-in
Before a machine joins production, Durantic runs a multi-day acceptance suite: NCCL all-reduce at line rate, DCGM full diagnostics, ECC error sweeps, NIC link-flap detection, optic stability, and sustained thermal soak under representative matmul load. Failures are quarantined automatically; passing hardware is admitted to the fleet with a signed acceptance report you can hand to your vendor for RMA. The same telemetry pipeline that runs in steady state runs during burn-in — first signal arrives before first workload.
| Method | Requirements | Speed | Best For |
|---|---|---|---|
| LinuxBoot | CoreBoot/LinuxBoot firmware | ~90s total | Greenfield GPU clusters, OCP hardware |
| In-band (SSH) | Any running Linux + SSH | ~60s + reboot | Existing servers, colo, multi-provider |
| Installer ISO | BMC virtual media or USB | 5–10 min | Air-gapped, compliance, first bootstrap |
| PXE Netboot | DHCP/TFTP infrastructure | ~60s + reboot | Legacy environments with existing PXE |
Control plane reachable?
├─ YES → What should I do?
│ ├─ "boot from disk" → localboot (normal operation)
│ ├─ "discovery" → download installer, kexec, inventory hardware
│ └─ "rebuild" → download installer, kexec, provision from config
└─ NO → boot from disk (graceful degradation, no CP dependency)Add a node anywhere. The mesh builds itself.
Kernel-level SDN. Geneve in-DC. WireGuard cross-site. iBGP routing. Zero manual configuration.
On bare metal, there’s no VPC. No software-defined anything. Every new location means hand-editing WireGuard configs, BGP peer lists, and firewall rules on every existing node — O(n²) configuration that breaks silently. Ansible playbooks drift, peer lists go stale, one missed route and traffic black-holes.
Automatic mesh formation
Every node that joins gets tunnels to every peer, BGP sessions established, routes exchanged. No peer lists, no Ansible, no provider-specific Terraform modules.
Dual-layer tunnelling
Intra-datacenter: Geneve tunnels for line-rate forwarding with zero encryption overhead — you’re already inside a physically secured facility. Cross-site: WireGuard tunnels with per-node Curve25519 keypairs, always on, zero config.
NAT traversal built in
Nodes behind NAT or CGNAT are reachable transparently — eBPF-driven STUN for endpoint discovery, relay paths discovered automatically through BGP next-hop semantics. No port forwarding, no relay servers.
DURP path quality measurement
DURP (Durantic UDP Reachability Protocol) continuously measures every path: reachability, latency, link quality. Per-path weights feed into the kernel routing table so traffic shifts away from degraded links automatically. RFC 8899 PMTU discovery built in.
VIP load balancing
Health-checked failover with kernel multipath routing, weighted by DURP path quality. eBPF IP-in-IP encapsulation for TCP offloading. Health checks: HTTP, TCP, gRPC, exec. BGP withdrawal on failure — designed for sub-second failover.
| Scale | BGP Topology | Sessions | Notes |
|---|---|---|---|
| ≤ 250 nodes | Full mesh | n(n-1)/2 | Default, maximum resilience |
| 250–2,000 nodes | Route reflector | n × RRs | Gateways as RRs, data plane unchanged |
| 2,000–20,000+ | Multi-mesh + gateways | Linear | Architecture designed for this scale |
Upgrade Kubernetes in place. Reprovision the OS when needed.
Cluster API native infrastructure provider. Declarative bare metal lifecycle.
In the cloud, upgrades are a button click. On bare metal, upgrading Kubernetes means reprovisioning the entire machine — drain the workloads, rebuild the OS, reinstall everything, rejoin the cluster. For an 8×H100 node, that’s hours of downtime. So you skip upgrades and accumulate drift, or take the hit and rebuild.
Native CAPI integration
Durantic integrates with Cluster API as a native infrastructure provider. Standard Kubernetes tooling — kubectl, GitOps controllers, Cluster API operators — manages bare metal fleets through familiar CRD-based workflows.
In-place Kubernetes upgrades
Kubelet, kubeadm, control plane components upgrade live on the running machine. No rebuild, no lost serving capacity. This uses CAPI’s new in-place upgrade path.
Full reprovisioning when needed
For deeper changes — kernel upgrades, OS-level updates — the agent reprovisions the machine in-band with a new OCI image. About 60 seconds of installer work, plus a firmware reboot.
Auto-healing with MachineHealthCheck
MachineHealthCheck resources automatically detect and replace unhealthy nodes, triggering reprovisioning without operator intervention.
| Operation | Method | Downtime |
|---|---|---|
| K8s component upgrade | In-place via CAPI | Zero (rolling) |
| OS / kernel upgrade | Full reprovision | ~60s installer + reboot per node (rolling) |
| New OCI image rollout | Full reprovision | ~60s installer + reboot per node (rolling) |
| Node failure recovery | Auto-reprovision via MHC | Automatic |
| Scale up | Add to MachineDeployment | ~60s installer + reboot per node |
| Scale down | Remove from MachineDeployment | Graceful drain |
Push once. The swarm distributes.
Optional sidecar. Content-addressed blob cache. P2P distribution across your fleet.
140GB model weights, training datasets, container images — large files need to be on every node. Today that means rsync scripts, cron jobs, or pulling from S3 on every cold start. Every update is a full re-download. Across 50 PoPs, model updates take hours and drift is inevitable.
Distributed blob cache
Durantic runs a content-addressed, OCI-compatible cache on every node, backed by local NVMe. A consistent hash ring determines which peers hold which blobs, and a gossip protocol means every node that fetches a chunk immediately becomes a source for others — the more nodes you have, the faster distribution gets.
Enables parallel provisioning at scale
The blob cache is also how Durantic distributes OS images. Instead of 100 nodes all pulling from one registry, the first node pulls and the rest fetch from their nearest peers. 100 nodes run through the same ~60 seconds of installer work as 1.
Digest-verified integrity
Every blob is verified by its content digest on arrival. No separate checksumming step. Previous versions stay cached on disk — rollback is a local pointer swap.
Optional sidecar deployment
The blob cache is an optional module — enable it when you need large-file distribution. It’s not required for networking or provisioning to work.