VPS Infrastructure Blueprint

              ░░░░░░░░░░░░
         ░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░
       ▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▒
      ▒▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▒
      ▒▓▒▒▒▒▓▓▓▓▓▓▓▒▓▓▓▓▒▒█▒▒▒▒▒▓▒
      ▒▓▒▒▒▒▒▓▓▓▓▓██▓▒▒▓█▒█▓▒▒▒▒▓▒
      ▒▓▒▒▒▒▓█▓▓▓▓▒██▒▒▓█▒█▓▒▒▒▒▓▒
       ▒▓▓▓▒▓▓▓▓▓▓▓▒▓▓▓█▓▒████▓▓▒
         ░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒░
       ░      ░░░░░░░░░░░░      ░
      ▒▓░                      ░▓▒
      ▒▓▓▓▒░░░            ░░░▒▓▓▓▒
      ▒▓▒▒▒▓▓▓▓▓▓▒▒▒▒▒▒▓▓▓▓▓▓▒▒▒▓▒
      ░▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓░
        ░▒▒▓▓▓▓▓▓▓▒▒▒▒▓▓▓▓▓▓▓▒▒░
             ░░░▒▒▒▒▒▒▒▒░░░
      ▒▓░                      ░▓▒
      ▒▓▓▒░░                ░░▒▓▓▒
       ░▒▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▒░
          ░░▒▒▓▓▓▓▓▓▓▓▓▓▓▓▒▒░░

              ▓▓▓▓▓▓▓▓▓▓▓▓
         ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
         ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
       ▓      ▓▓▓▓▓▓▓▓▓▓▓▓      ▓
      ▓▓▓                      ▓▓▓
      ▓▓▓▓▓▓▓▓            ▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
        ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
             ▓▓▓▓▓▓▓▓▓▓▓▓▓▓
      ▓▓▓                      ▓▓▓
      ▓▓▓▓▓▓                ▓▓▓▓▓▓
       ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
          ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

The VPS began as a working host and became a reproducible system. The blueprint records what must survive beyond one installation: public and private service boundaries, storage roles, enabled units, deployment assumptions, and the tests that show a reconstructed machine behaves correctly.

Problem

A running server is not its own documentation. Configuration can drift, runtime state can hide important assumptions, and copying a disk does not explain why a service is exposed or isolated.

Design

• inventory the target before selecting disks or mounts
• preserve service behavior instead of hard-coding one machine’s identifiers
• keep source and reconstruction instructions in private Forgejo repositories
• separate general host topology from deployable media implementation
• validate mounts, listeners, services, and public routes after changes
• serve static sites from versioned releases selected by an atomic symlink
• test production-canonical output on a public, explicitly noindex preview host

Static edge boundary

The portfolio edge is declared as Caddy configuration rather than remembered server state. Production and preview use the same built artifact, while the preview host adds its own indexing prohibition. Restrictive response headers, content-specific caching, real non-success responses for sensitive probes, and a retained previous release provide a testable deployment and rollback model.

Search ownership verification is deliberately scoped to the canonical HTTPS apex. It does not broaden indexing or verification across service subdomains.

A production correction as reconstruction evidence

A recent media-ingress correction exercised the same model on a stateful service. Before changing one classifier, the active script, unit, and affected stream/sidecar pairs were captured in a root-only snapshot. The replacement was syntax-checked, covered by focused filename tests, installed with its declared owner and mode, restarted independently, and verified against both its live checksum and Jellyfin’s resulting item counts. The exact deployed revision and updated provenance were then pushed to Forgejo.

That sequence matters more than the size of the patch. A small naming fix can still alter library identity, metadata grouping, and user-visible cards. The blueprint therefore treats application files and affected state as one change boundary while keeping unrelated services, mounts, and public routes outside the operation.

Result

The host can be reasoned about as a set of declared responsibilities rather than a collection of remembered shell commands. The bridge workspace carries the recovery context, Forgejo holds project history, and the live VPS remains a deployment target rather than the only source of truth.

Potential side project: IRC-backed voice rooms

A future experiment could extend the self-hosted IRC network with a lightweight Mumble voice service. Persistent text would remain in IRC and ZNC; Mumble would provide low-latency, always-available voice rooms for friends. A narrow bridge could map one dedicated IRC channel to one Mumble room for text and optional presence without mixing private messages, audio, or administrative commands.

The useful shape is deliberately small: an invite page, one-click Mumble link, valid TLS, guest/friend/operator roles, a public lobby, and private friend channels. The bridge would use Mumble’s Ice interface only on loopback with its own secret and strict rate limiting. This is recorded as a possible side project, not a deployed service or committed roadmap item.

Lesson

Reproducibility is not just installation automation. A useful blueprint also records trust boundaries, failure meanings, acceptance checks, and what must never become public.