πŸ› οΈ Implementation & Tooling

Implementation & Tooling #

Documents what each role runs and how it is configured β€” what Deevnet runs today, and what is under evaluation β€” organized by substrate architecture layer. Each page records what was chosen and why. The section opens with Hardware: the physical boxes, one page per model.

How to operate what is selected here is in the runbook; finished projects built on it are under Completed Projects.


Roles and what fills them #

The roles themselves β€” what each does, and where it sits in the network β€” are defined in Architecture. This section only says what fills them.

Architecture roleFilled byPage
Edge routerGL-iNet Slate AX, OpenWrtEdge Router
Core routerZimaBoard 832, OPNsenseCore Router
Access switchTP-Link SG2218Access Switch
Wireless accessTP-Link EAP650-OutdoorWireless Access Point
Network managementOmada SDN ControllerNetwork Controllers
BuilderAOOSTAR N1 PRO, FedoraBuilder Node
Management hypervisorDell OptiPlex 7050 Micro, Proxmox VEManagement Hypervisor
Tenant hypervisorDell OptiPlex 7060 Micro, Proxmox VETenant Hypervisors
Tenant fabricProxmox SDN, EVPN/VXLANTenant Fabric
Pi labRaspberry Pi 4Raspberry Pi
Tenant DNSPowerDNS AuthoritativeTenant DNS

The software this site wrote for itself β€” the Deevnet API, the Terraform provider tenants use, and the runtime tools around them β€” is Deevnet Software. Everything else the management and control planes run β€” OpenBao, the MQTT broker, the log store, Grafana β€” is listed in the Software Catalog.


Scope #

This section answers the question:

“Why did we choose this, and under what conditions would we change it?”

Each role page documents:

SectionContent
RoleOne line naming the architecture role it fills, with a link
HardwareA link to the model’s page under Hardware
Operating SystemOS choice and automation capability
Product features in useWhat the product does beyond the role, and the product-specific facts that cost time to discover

It does not restate the role, and it holds no procedures: those are in the runbook.


Evaluations #

What each selection was checked against, by item: its current verdict, and every evaluation behind it, plus the candidates being considered. See Evaluations. Hardware in service is evaluated on its model’s Hardware page. The process and criteria are the Evaluation policy.


Software Catalog #

Every piece of software in use, with its version, license and support model, grouped by layer, including the services bundled inside OPNsense: see Software Catalog.


Technology Stack #

TechnologyPurpose
AnsibleInfrastructure provisioning
TerraformTenant interface β€” tenants declare themselves through the deevnet/deevnet provider
PackerOS image builds
Fedora/RHELPrimary OS (dnf-based, SELinux)
Proxmox VEVirtualization platform
OPNsenseRouter platform
VyOSOn hold (see Evaluations)
TP-Link OmadaSwitch and AP management
Page last modified: September 27, 2026