Desktop Dev Hosts

Two Proxmox VE hosts standing in the HQ office, joined into a single cluster named THBOnPrem, on their own local VLAN. They provide on-prem virtualization capacity for desktop development work, and we refer to them collectively as the Desktop Dev Hosts.

They are the first on-prem compute this repo documents. Everything else described here runs in GCP, Azure, or Cloudflare, provisioned through Terraform and TFO. These two hosts are not Terraform-managed and have no state under infra/ — they were deployed by hand, and are administered through the Proxmox web UI and SSH.

At a Glance

• Cluster. Both hosts are members of the THBOnPrem Proxmox cluster, so they share configuration and are administered as one system: sign into either host’s web UI and you see and manage both.
• Network. 192.168.2.0/24, a dedicated VLAN local to HQ, deliberately separate from the other HQ networks.
• Reachability. From the HQ network directly, and from outside the office over the WireGuard VPN (see Access). Still no route from GCP, Azure, or Cloudflare into this subnet, and no site-to-site tunnel — cloud workloads cannot reach these hosts.
• Guest addressing. The hosts occupy .5 and .6. The rest of the /24 is unallocated, so VM and container guests draw from the same range unless a separate scheme is introduced.

Why a Separate VLAN

Dev VMs are, by nature, the machines people install unvetted things on and point at half-finished services. Putting them on their own layer-2 segment keeps that traffic off the general HQ network and gives us a single place to write policy: the boundary between 192.168.2.0/24 and everything else. Widen access at that boundary deliberately, per port and per destination, rather than by flattening the segment.

%%{init: {'theme':'dark','themeVariables':{'fontSize':'16px','lineColor':'#9ca3af'},'flowchart':{'curve':'basis','nodeSpacing':45,'rankSpacing':55}}}%%
flowchart TB
  REMOTE["Remote users
off-site"]:::ext
  WG["WireGuard VPN
Ubiquiti gear"]:::net
  HQ["Rest of HQ network"]:::ext

  subgraph HQVLAN["HQ Desktop Dev VLAN  ·  192.168.2.0/24"]
    direction LR
    H1["thb
192.168.2.5"]:::host
    H2["thb2
192.168.2.6"]:::host
    H1 ---|"THBOnPrem cluster"| H2
  end

  G["VM / container guests
same /24, unallocated"]:::guest
  CLOUD["GCP  ·  Azure  ·  Cloudflare"]:::ext

  REMOTE -->|"tunnel in"| WG
  WG --> HQVLAN
  HQ -->|"VLAN boundary
policy enforced here"| HQVLAN
  HQVLAN -.->|"hosts"| G
  CLOUD -.->|"no route"| HQVLAN

  classDef host fill:#bfdbfe,stroke:#1d4ed8,stroke-width:1px,color:#0b1e3b
  classDef guest fill:#bbf7d0,stroke:#15803d,stroke-width:1px,color:#06281a
  classDef net fill:#fde68a,stroke:#b45309,stroke-width:1px,color:#3a2400
  classDef ext fill:#e5e7eb,stroke:#4b5563,stroke-width:1px,color:#111827

Access

Both hosts serve the Proxmox management interface on its standard port, 8006, over HTTPS. Because they are clustered, either address administers the whole of THBOnPrem:

• thb — https://192.168.2.5:8006
• thb2 — https://192.168.2.6:8006

SSH is available on each host on the usual port 22. Certificates are Proxmox’s self-signed defaults until we put a real one in place, so expect a browser warning on first connection.

Getting onto the network

• At HQ. Reachable directly, subject to policy at the VLAN boundary.
• Off-site. We run a WireGuard VPN terminated on our Ubiquiti equipment that puts remote users onto the on-prem network. Connect to it and these hosts are reachable as if you were in the office — no separate tunnel or jump host required.

This is our own VPN path, not a cloud one. Neither IAP (GCP) nor Bastion (Azure) applies to these hosts; those reach cloud VMs only.

What These Are Not

Worth stating plainly, because the names invite confusion:

• Not swarm nodes. The THBOnPrem cluster is unrelated to either Docker Swarm cluster. Those are GCP VMs in hb-infra and are described in Swarm.
• Not Terraform-managed. No module, no state, no tfo plan covers them. Changes here are made by hand and are not captured in this repo’s plan output.
• Not the same thing as the GCP Dev Windows VM. For a disposable, toolchain-baked Windows box to build and debug HealthAlign PMS apps, use Dev Windows VM — it is cloud-hosted, reachable over IAP from anywhere, and reaped automatically. The Desktop Dev Hosts are durable on-prem capacity with no expiry or reaper.

Edit this page