Inside pb62
The hardware, network boundary, and software layers behind mayphus.org—described as an operating system, with a small amount of live evidence.
The hardware is deliberately ordinary
pb62 is a single x86-64 machine running Ubuntu 24.04. It has 16 logical processors, about 16 GB of memory, and a 512 GB NVMe disk. That is enough for the public-site services, one virtual machine, home automation, and a small k3s cluster without pretending to be a datacenter.
The live figures show pressure, not configuration. They publish percentages, load, and uptime; hardware identifiers, disks, addresses, and process details remain private.
Live hardware state
The network is a boundary, not a diagram
A visitor reaches Cloudflare first. Static assets can finish there; the Worker admits only named public API behavior. A service tunnel carries the few requests that require private compute, while the home router and the rest of the LAN remain outside the public contract.
The status below intentionally answers only whether each boundary is healthy. It does not publish addresses, host aliases, tunnel identifiers, connector counts, routes, probe methods, diagnostic messages, or exact topology.
Network boundaries
A domain does not have to attach to the tunnel
mayphus.org and my.mayphus.org terminate at the Cloudflare Worker. The tunnel has no published application routes; it stays connected because VPC Service bindings use it as private transport to selected k3s workloads.
Ordinary pages finish at the edge. Only private-home, typing, and status backend requests cross the private boundary, and no public hostname points directly at pb62.
Current request path
The public name resolves at Cloudflare, not at the home network.
Access protects my; the Worker chooses an edge or private path.
A fixed private service target; no public hostname is required.
Outbound-only private transport with zero published applications.
The selected service forwards the request to its workload.
Three software layers have three jobs
Podman holds a replaceable home-automation service. KVM provides a stronger boundary for an Ubuntu guest. Kubernetes keeps the public application workloads running and replaces failed processes. The layers are tools with different failure boundaries, not a claim that every service needs orchestration.
Only explicitly allowlisted public services appear below. New containers, guests, namespaces, images, pods, and system workloads stay invisible unless the public contract is deliberately changed in code.
Software state
Failure should stay local
The public shell can remain available while pb62 is being repaired. A stopped workload should affect its own service, not turn the entire site into a maintenance screen. Preview catches changes before the main domain moves, and each private layer can be inspected or replaced independently.
The dynamic blocks are evidence for this article, not a public operations console. Their job is to show that the described layers exist and are broadly healthy without teaching a visitor how the private network is assembled.