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. Concepts such as infrastructure boundaries, automation-first provisioning, and tenant isolation are intentionally applied.
However, Deevnet operates at a much smaller scale than hyperscale cloud providers. Instead of modeling multiple global regions and availability zones, the architecture focuses on independent infrastructure sites that can be built, operated, and reprovisioned entirely from code.
This approach preserves the architectural principles of cloud infrastructure while remaining practical for a home and portable lab environment.
System Overview #
Yellow boxes are virtual: each runs on its own hypervisor, standalone today but able to grow into a cluster.
The platform is organized around three architectural boundaries β sites, substrates, and tenants β that separate infrastructure from workloads. Because infrastructure is fully defined in code, a substrate can be reprovisioned from scratch and workloads redeployed to it β or to a different site entirely β without being coupled to any specific hardware.
Sites #
A site is an independent infrastructure deployment with its own IP address space, DNS zone, and complete hardware stack. Each site can be built, operated, and torn down without affecting any other.
| Site | Purpose | Address Block | DNS Zone |
|---|---|---|---|
| home | Production home infrastructure (always-on, stable) | 10.10.0.0/16 | home.deevnet.net |
| mobile | Mobile/portable lab for development, testing, and demos | 10.20.0.0/16 | mobile.deevnet.net |
Builder #
The builder is a small server that can be connected to either site to create its substrate from scratch. Self-contained, portable, and air-gapped capable, it provisions the site and then hands off authority to production infrastructure. See Builder for the provisioning model, authority transitions, and design principles.
Substrate #
The substrate is the shared infrastructure foundation within a site β networking, compute, storage, and management plane. It provides the base that workloads run on and is fully reprovisioned through automation. See Substrate for infrastructure layers and authority modes.
Tenant #
A tenant is an isolated workload boundary for applications and services running on a site’s substrate. Tenants are decoupled from the underlying infrastructure β they can be provisioned, migrated, or rebuilt without changes to the substrate, and are not bound to any one site. See Tenant for tenant networking, lifecycle management, and provisioning.
Network Segmentation #
The network segmentation model that divides each substrate into isolated broadcast domains, enforcing trust boundaries and traffic separation at the network layer. See Network Segmentation for segment types, trust hierarchy, default routing policy, and authority mode transitions.
Naming and Addressing #
How each site is addressed, and how hosts and tenant workloads get their addresses and names. See Naming and Addressing for the site address plan, WAN operation modes, the chain from declared identity to address and name, and the two naming authorities.
Limits #
What the hardware underneath the architecture cannot do β no out-of-band management, nothing clustered, local storage, and a single instance of every network device. Deevnet is designed to be rebuilt quickly rather than to stay up through a failure. See Limits for each constraint, what compensates for it, and what lifting it would take.