How Durantic works.
The open-source control plane underneath every Durantic fleet. Four pillars, plus the reeve on top.
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 open-source firmware foundation used by several hyperscalers on their production 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 in any public cloud work identically on bare metal — no provider-specific first-boot logic required.
Bootstrap and reprovisioning
Bootstrap any running Linux over SSH 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. After that the agent drives reprovisioning itself: it pulls the new image and boots the installer with kexec, with grub-reboot as the safe fallback. About 60 seconds of installer work, plus a 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
New racks can soak before they take production work: NCCL all-reduce at line rate, DCGM diagnostics, ECC sweeps, NIC link-flap and optic checks, and a sustained thermal soak under representative load. Failing hardware is quarantined with a report you can hand to your vendor for RMA; passing hardware joins the fleet.
| 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 |
Signed, versioned configuration releases
Configuration ships as bundles: OCI artifacts built and signed in CI. The control plane composes each machine’s bundles into a versioned release, rolls it out in health-gated waves, and every machine converges locally with masterless Salt. No central master. One-step rollback.
Configuration on a fleet usually means a central master that becomes a single point of failure, or playbooks pushed over SSH that drift the moment someone edits a box by hand. Nobody can say exactly what is running on node 412, or how to get back to yesterday.
Official bundles, and your own
Durantic ships official config bundles for installing, hardening and running Kubernetes on your machines, beside its official images and roles. Your own bundles are ordinary OCI artifacts: push them to any registry and register them by reference, like an image.
Content-addressed and signed
Official bundles are always signed, and yours can be with your account’s key. The control plane verifies the signature, schema and layout when a bundle is registered, and machines are told exact digests, never tags: each one checks every bundle against its digest before it applies anything.
Converged locally, no master
Each agent applies its bundles with masterless Salt on the machine itself. There is no central master to scale or lose, and a machine cut off from the control plane keeps its last good state.
Health-gated waves
Every release rolls out by itself, in waves. Bundles declare how cautiously they roll and the strictest rule wins. Each wave has to report healthy before the next one starts, and a failing wave halts the rollout.
One-step rollback
Every release is an immutable, versioned snapshot. Rolling back is pointing the fleet at the previous one, in one step.
bundle CI
└─ push → OCI artifact (Salt states + descriptor) + signature
└─ register → control plane verifies signature, schema and layout
└─ compose → each machine’s bundle set, snapshotted as one versioned release
└─ roll out → wave 1 → health gate → wave 2 → … → wave n
└─ on each machine: verify digests → converge locally → reportRoll changes through the fleet without taking it down
Health-gated rolling reprovisioning, in-place configuration releases and one-step rollback.
In the cloud, replacing a machine image is a button click. On bare metal, an OS upgrade means draining workloads, rebuilding the machine and rejoining it, by hand, one box at a time. So teams skip upgrades and accumulate drift, or take the hit and rebuild everything at once.
Health-gated rolling reprovisioning
Roll a new OCI image across a pool a batch at a time. Each machine drains, reprovisions and has to pass its health checks before the next one starts. A failure halts the rollout.
In-place configuration releases
Most changes don’t need a rebuild. Ship them as a configuration release and every machine converges in place, with no reprovision and no lost capacity.
Full reprovisioning when needed
For kernel and OS changes, the agent reprovisions the machine in-band with a new OCI image: kexec into the installer, with grub-reboot as the safe fallback. About 60 seconds of installer work, plus a reboot.
One-step rollback
Go back to the previous image or release in one step, through the same health-gated path.
Works with Kubernetes tooling you already use, including Cluster API.
| Operation | Method | Downtime |
|---|---|---|
| Configuration change | Configuration release, converged in place | None |
| 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 | Reprovision from the control plane | ~60s installer + reboot |
| Scale up | Add machines to a pool | ~60s installer + reboot per node |
| Scale down | Remove machines from a pool | Graceful drain |
The reeve
An AI operator that sees the whole fleet: rollouts, rebuilds, health. Your engineers talk to it in the control plane. It diagnoses issues and proposes fixes, and anything privileged, like terminal access or a rebuild, needs a human to co-sign with 2FA.
Observes and advises
Reads the fleet, explains what it sees, proposes the fix.
Acts with your 2FA co-sign
Runs the typed action once an engineer approves it with two-factor sign-off.
Handles delegated work
Takes the classes of work you delegate, with every action audited.
The reeve works through the same typed, health-gated actions your engineers use, so everything it does is audited and reversible in the same way. Every fix it makes, with the customer's consent, improves the library of actions it uses on the next fleet.
Bring your own model: we run inference in Durantic Cloud, you can use your own API key, and air-gapped deployments can plug in their own LLM.