LuxorItPro

Sheet 01/16Personal infrastructureIndependent project

Self-hosted virtualization platform

Proxmox, Docker and LXC arranged into an environment that can be rebuilt from notes.

Fig. 01 How a service is rebuilt from the notes
How a service is rebuilt from the notes How a service is rebuilt from the notes. Proxmox host (Where the guests live). Then Guest per service (VM or LXC, one each); Deployment note (What runs, where data lives). Then Docker workload (Upgrades stay contained). Then Reverse proxy (Hostnames and TLS in one place). Arrows show the write path between components; a dashed arrow marks data derived from another component. Proxmox host WHERE THE GUESTS LIVE Guest per service VM OR LXC, ONE EACH Deployment note WHAT RUNS, WHERE DATA LIVES Docker workload UPGRADES STAY CONTAINED Reverse proxy HOSTNAMES AND TLS IN ONE PLACE

Drawn from the Approach section of this write-up. No client names, no live data.

Problem

Services had accumulated on separate machines with ad-hoc configuration and no record of how anything was deployed. Any change carried the risk of not being reversible, because the only description of the setup was somebody's memory of setting it up.

Our role

Independent project — designed and built for our own environment. Nothing here was delivered to a client, and no client environment is described.

Approach

The environment was rebuilt on Proxmox, with one virtual machine or LXC container per service rather than several services sharing a host. Application workloads run under Docker inside those guests, which keeps upgrades and rollbacks contained to one service at a time.

A reverse proxy sits in front of the internal services so hostnames and TLS are managed in one place instead of per application. Every service also has a short deployment note: what it runs, where its data lives, how it is started, and what has to happen before it can be rebuilt. The notes are the point — a rebuild should not depend on remembering which setting mattered.

Outcome

A written service map, workloads isolated from each other, and upgrades that can be attempted without taking everything offline. The documentation is maintained as part of the environment rather than after it.

Notes

No screenshots yet: the useful ones show hostnames and account details, which need redacting first. Capacity and uptime figures are not claimed because they are not measured.

All case studies Start a project