Architecture #

The Deevnet platform is a collection of physical and virtual infrastructure — routing, switching, wireless, DNS, DHCP, NAT, WAN uplink, compute, and virtualization — provisioned entirely through Infrastructure as Code and Configuration as Code. Every device, service, and network segment is defined in source control and applied via automation, making the platform fully reproducible and rebuildable from scratch.

Design Philosophy #

Deevnet’s infrastructure architecture is inspired by patterns used in large-scale cloud platforms — infrastructure boundaries, automation-first provisioning, and tenant isolation — applied not to global regions but to independent infrastructure sites, each built, operated and reprovisioned entirely from code.

The principles, site model and layers on these pages are written for any Deevnet site. This documentation describes one of them, the Mobile Factory, a portable site; the Decision Records are its decisions.

System Overview #

Yellow boxes are virtual, each on its own hypervisor. Everything else inside the substrate is physical. Edge devices sit inside the site but outside the substrate.

Substrate and Tenant #

A site is one self-contained deployment: its own address space, DNS zone and hardware. Within it, the architecture draws one main line — between the infrastructure and what runs on it.

• Substrate — the site’s infrastructure: network, compute, storage, and the management and control planes. Built and rebuilt from code by the operator.
• Tenant — an isolated slice of the site for one application: its own network, DNS zone and workloads, built for it by the substrate when it asks.
• Edge devices — physical things an application owns through its tenant, which the substrate attaches to an access network. Not substrate, not a tenant workload, and never inside a tenant’s network.
• Builder — the portable server that creates a site’s substrate from scratch, then hands authority to it.

Going deeper #

• Network Segmentation — the segments, their trust levels and the policy between them
• Naming and Addressing — the site address plan, and how hosts and tenants get addresses and names
• Trust and Identity — the offline root, each site’s CA, and why server identity and device identity are issued separately
• Decision Records — why each choice was made
• Resiliency & Limits — what the hardware can’t do, and why the site is built to be rebuilt rather than to stay up