Establish authoritative infrastructure data, segmented network state, and foundation services through one governed path with deterministic rebuilds.
Reference implementation: NetBox IPAM and Proxmox SDN across a clean on-premises environment.
Validates
- NetBox is used as the authoritative IPAM source for prefixes and VM inventory sync.
- Management, data, and workload bridges are provisioned through the Proxmox SDN path.
- Foundation VMs can be rebuilt and re-synchronised without manual IP assignment drift.
Apply one governed contract to segmented networking, optional host routing, address services, and API-only multi-node delivery.
Reference implementation: Proxmox SDN with VLAN-backed networking, NAT, and DHCP.
Validates
- A three-node API-only lifecycle completed with the shared zone present on all members and one disposable guest on each node.
- The guests reached the external gateway and each other across the VNet while SSH to the node subnet remained blocked.
- The same topology contract supports host-routed bootstrap and edge-routed production posture.
Exercise verified backup, cloud failover, and controlled return through isolated recovery lanes with checksum-validated application data.
Reference implementation: PostgreSQL HA with Patroni and pgBackRest across on-premises and GCP.
Validates
- Three-node on-prem PostgreSQL HA is provisioned and operated through the platform blueprint path.
- The GCP recovery lane restores from pgBackRest and preserves seeded application row counts and checksums.
- The isolated on-prem return lane restores the same dataset back from GCP-backed storage without touching the live dev database lane.
Establish a resilient public edge, extend on-premises routes through redundant tunnels, and exchange prefixes with a cloud hub under one governed WAN control plane.
Reference implementation: A VyOS edge pair on Hetzner with GCP hub routing and BGP.
Validates
- The Hetzner VyOS edge image path is proven on both Hetzner and Proxmox.
- The GCP hub learns on-prem routes across both WAN legs through Cloud Router BGP peers.
- On-prem prefixes are extended through the Hetzner edge pair without depending on a static public IP at the on-prem site.
Bring up a highly available on-premises control plane and worker pool, publish a clean operator handoff, and layer workloads without changing the delivery contract.
Reference implementation: RKE2 with a GitOps-ready kubeconfig and workload path.
Validates
- The on-prem RKE2 blueprint provisions a healthy highly available control plane and worker pool with kubeconfig output.
- The same execution contract used for networking and DR is reused for platform services and workload preparation.
- The platform path is ready for GitOps overlays without reworking the underlying environment model.
Establish a managed cloud standby from an on-premises HA source, promote it under control, and return through an isolated lane without touching the live service path.
Reference implementation: PostgreSQL with Cloud SQL across on-premises and GCP.
Validates
- Cloud SQL standby establishment is exercised from the on-prem PostgreSQL HA source through the managed replication path.
- Managed promote is validated through an isolated DNS name instead of compromising the live service record.
- Managed failback returns the isolated service path to on-prem cleanly, giving a real comparison against the self-managed DR lane.
Burst an authenticated web tier into cloud capacity with governed secret delivery and a controlled public cutover while upstream authority services remain in place.
Reference implementation: GKE with GitOps and cloud-native secret delivery.
Validates
- A governed GKE burst cluster is provisioned on the shared hub network and bootstrapped with Argo CD and GCP Secret Manager.
- The portal web tier serves from GKE while identity and entitlement services remain authoritative upstream dependencies by design.
- Public cutover is validated after cluster health, app health, runtime-bundle provenance, and application-route checks all succeed.
Move application secrets from a central authority into workload namespaces through a governed delivery path with distinct on-premises and cloud identity postures.
Reference implementation: GCP Secret Manager, External Secrets Operator, Kubernetes, and Workload Identity.
Validates
- GCP Secret Manager remains the authoritative source while ESO delivers materialised Kubernetes secrets into application namespaces.
- The on-prem RKE2 path uses a controlled bootstrap credential, while the GKE path uses Workload Identity instead of a static key.
- The recorded exercise verifies service-account provisioning, ClusterSecretStore readiness, ExternalSecret sync, and cleanup.
Move new or existing network labs onto high-resource execution capacity that can be released after continuity state is preserved and verified, then reconstruct on fresh hosts when needed.
Reference implementation: EVE-NG, GNS3, and Containerlab across on-premises and Google Cloud compute.
Validates
- EVE-NG and GNS3 lifecycle paths are exercised on Google Cloud and Proxmox with private access, health, preservation, and controlled teardown.
- Existing labs enter through checksum-verified, same-platform intake. The EVE-NG path restored IOL, vEOS, and Ubuntu state from Proxmox to Google Cloud.
- Containerlab completed end-to-end Google Cloud validation in which off-host recovery proof gated original-host deletion before reconstruction on fresh compute.
- Each lab platform retains topology and native recovery authority while HybridOps governs the execution-host lifecycle and evidence boundary.