Authoritative On-Prem Foundation

Overview

Authoritative On-Prem Foundation establishes the authority and network state that later operations depend on. The operation contract names the required inventory and addressing capability. The blueprint binding selects the authority, while the infrastructure platform remains responsible for applied network state.

The recorded exercise uses NetBox for inventory and addressing authority and Proxmox for the network substrate. It provides the baseline for Kubernetes, PostgreSQL HA, WAN, and DR.

Technical case study

Basis: HybridOps-controlled reference environment, not a customer deployment. Claims are limited to the verification scope stated on this page.

• Context: the on-prem estate had no authoritative record for IP allocations or VM inventory. Addressing decisions lived in spreadsheets and the network was configured manually per host.
• Challenge: downstream platform services (Kubernetes, PostgreSQL HA, WAN extension) all needed reliable declared addressing and applied network state to build on, but those concerns were resolved independently through spreadsheets and host-level configuration.
• Approach: the foundation blueprint established network state and a logical inventory_ipam authority before admitting dependent platform work. The recorded environment bound that authority to NetBox and applied its network state through Proxmox.
• Outcome: downstream operations consume the declared addressing model while applied network state remains owned by the infrastructure platform. Later platform layers inherit the verified foundation instead of redefining it.

Covers inventory-authority readiness, network delivery, and the point where the foundation becomes admissible for higher platform layers.

Outcome

The result is an on-prem foundation where authority requirements are separate from provider binding and applied network state.

• Addressing, VM, and service records are established before downstream services are layered on.
• Proxmox SDN replaces manual bridge changes with repeatable platform delivery.
• Later blueprints consume the verified baseline instead of redefining network state.

Operating model

• The operation declares the inventory and addressing capability it requires.
• The blueprint binding selects the system responsible for that authority.
• The infrastructure platform owns applied SDN objects and the current network substrate.
• HybridOps verifies both boundaries before dependent work proceeds.
• Higher platform layers inherit this baseline instead of rebuilding it independently.

Architecture

In the recorded environment, NetBox remains authoritative for declared addressing, inventory, and service metadata. Proxmox remains authoritative for the applied SDN objects and live network substrate. The foundation blueprint verifies the boundary consumed by downstream operations.

Foundation sequence

1. The network foundation publishes the management, data, and workload networks.
2. The configured inventory and addressing authority is established.
3. Foundation VMs and inventory are reconciled against the same addressing model.
4. Authority-dependent operations are admitted only after the binding is verified.
5. Downstream platform layers consume the verified baseline instead of rebuilding it.

Platform state

Authoritative management, data, workload, staging, and lab prefixes in NetBox.

Foundation VM inventory registered with address and cluster state.

Shared Proxmox SDN zone active as the network baseline.

Foundation services running on the Proxmox estate.

IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.

Service governance

NetBox also records the service-level contract for the foundation itself. The service records below keep protocol, port, parent VM, and governance tags in the same authoritative inventory as IPAM and VM records.

NetBox service contract with endpoint, ownership, and governance tags.

PostgreSQL service contract marked for HA, DR protection, and cost control.

Authority and platform boundaries

• Operation requirement: dependent steps require the logical primary_ipam authority and inventory_ipam capability.
• Recorded binding: NetBox owns address, VM, and service metadata in this environment.
• Applied state: Proxmox owns the active SDN objects and current network substrate.
• Operational record: the selected authority and verified state are attributable without recording credentials.

Key components

• Bootstrap path: onprem/bootstrap-netbox@v1
• Foundation path: onprem/authoritative-foundation@v1
• Inventory service: platform/onprem/netbox
• Network baseline: core/onprem/network-sdn

Where it fits

• organizations establishing an on-prem platform baseline
• teams replacing spreadsheet-driven IPAM and manual bridge configuration
• estates preparing for HA Kubernetes, PostgreSQL, WAN extension, or DR delivery

References

Further reading

• Operation authority contract
• Authoritative foundation verification runbook
• Quickstart
• Network architecture
• Governed Proxmox SDN Network Foundation

Implementation references

• platform/onprem/netbox
• core/onprem/network-sdn

Related

Related reading

• Quickstart
• Network Architecture

What was verified

Verified against HybridOps v1.0.1: the selected inventory authority was reachable, the SDN zone was active, and authoritative inventory and service metadata were established. The recording covers the NetBox-backed reference environment; binding-independent admission is verified in HybridOps.Core.