case study / infrastructure
activeVPS Infrastructure Blueprint
A Git-tracked reconstruction specification for an always-on private host, its service boundaries, storage, and recovery workflow.
- Arch Linux
- systemd
- Caddy
- Docker
- Forgejo
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.
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.
Lesson
Reproducibility is not just installation automation. A useful blueprint also records trust boundaries, failure meanings, acceptance checks, and what must never become public.