Benjamin · KiyReload · UK

Built, broken, understood.
Written down.

This is my technical workshop: the software I write, the small network of machines I run at home, and the notes I keep so I don’t learn the same lesson twice. Everything below is connected, so start anywhere.

How to read the map. It runs from the physical hardware, through the platform and services built on it, to the projects those made possible, what I wrote about them, and what each one taught me. Selecting something traces what it comes from and what it led to. Line styles show whether a link is hosting, a traffic path, a technology used, or a story; they are not all network cables.

It shows documented architecture, not live status. Nothing on this site reports on a running system.

The network map

LinesTraffic pathRuns on / part ofBuilt with / used byTold in / taught

Everything on the map, as a list (37)

Hardware

  • HP Spectre x360Linux Mint laptop

    A portable Linux laptop used for college work and remote access.

    • Intel Core i7-8565U, 8 GB RAM, 1 TB SSD
    • Runs Linux Mint
    • Reached with SSH over Tailscale
  • Proxmox serveri5-7500 · 32 GB

    The main compute host. It runs the virtual machines and LXC containers, including the Debian media VM.

    • Intel Core i5-7500, 32 GB DDR4, 1 GbE
    • Storage: 2 × 4 TB HDD, 1 TB HDD, 256 GB M.2, 512 GB SSD
    • Only the Debian media VM is documented by name
  • Raspberry Pi 44 GB · always on

    A small, separate machine for always-on network services, so DNS keeps working when the Proxmox host is being maintained.

    • 4 GB LPDDR4, ARM Cortex-A72
    • microSD plus a 500 GB SSD
    • Hosts Pi-hole, Unbound, monitoring and dashboards

Platform & access

  • Tailscaleprivate remote access

    The private route into the lab and between my own devices, so nothing needs to be opened on the router.

    • Documented use: remote SSH into the laptop
    • Which other hosts join is not published
    • An earlier inventory ran it in an LXC; the current host is not stated
  • Cloudflare Tunnelpublic path

    Carries public traffic to the lab through an outbound connection, which avoids opening a port on the router.

    • Public website path: Cloudflare Tunnel → Nginx → static files
    • Also fronts Jellyfin, behind its login page
    • An earlier inventory ran it in an LXC; the current host is not stated
  • Debian media VMowns the ZFS pools

    A Debian virtual machine on Proxmox that owns the ZFS storage and runs the media services directly beside it.

    • Replaced a TrueNAS VM that served storage over NFS
    • The old TrueNAS VM is kept powered off as a rollback
  • Docker + Portainercontainer workloads

    Containers are how most small services run. Portainer is the management view.

    • Jellyfin runs as its own Docker service
    • An earlier inventory placed Docker and Portainer in a Debian LXC
    • Which services are containerised is not itemised publicly

    Connected to

  • Pi-hole + UnboundDNS for the network

    Pi-hole answers and filters DNS queries; Unbound is the recursive resolver behind it. Both moved off Proxmox onto the Pi.

    • Pi-hole used to run in a Proxmox LXC
    • Unbound resolves recursively

Services & stack

Projects

Writing

Lessons

  • Validate resultsevidence, not looks

    A convincing optimisation result still needs evidence. Explainable scoring and validation exist so a plausible answer is never mistaken for a correct one.

  • Data boundariescatalogue vs. user

    An early database update could overwrite user data. Separating catalogue tables from user tables made the boundary safe, and uncertain OCR input needs the same explicit treatment.

  • Architecture by userewrites can pay off

    Architecture becomes clear through use, so a rewrite that captures earlier lessons can be worth it.

  • Knowing when to stopa product decision

    When maintenance cost outweighs remaining value, ending a project can be the sound product decision. Finished work stays documented.

  • Baseline firstprove nothing changed

    Before redesigning something you only have the output of, snapshot it, hash it and rebuild it until it matches. Then change things.

  • Reversible stepsrollback first

    Stage the move, verify before changing paths, and keep the old system powered off but intact until the new one has proved itself.

  • Storage ownershipfewer boundaries

    A dedicated NAS is not wrong. Here, letting the VM that uses the storage also own it removed a whole class of permission problems.

  • Placement mattersas much as how

    Where a service runs can matter as much as how it runs. Independent hardware shrinks what a maintenance window can affect; it is not redundancy and not a backup.

Recently

What changed

  1. Redesigned this site as a connected map of hardware, services, projects, writing and lessons.

  2. Wrote up how to recover a static site when only the published HTML remains.

  3. Active development of UMA Companion stopped. The project is kept as a case study.

  4. Plex storage ownership moved from TrueNAS to Debian. Plex data was preserved and a Jellyfin trial began with read-only media mounts.

Full timeline →

Where to go next

Follow a request

The network page steps through how a visitor reaches this site, how a DNS lookup is answered at home, and how I get back in privately, one hop at a time, with the private details left out on purpose.

Honest by design. Where the published documentation doesn’t say something (a pool layout, a backup tool, which machine runs a service) this site doesn’t guess. Those gaps are marked, not filled.