02 / Problem

Problem

File services, an offline library and other applications share one server. An unrestricted upload tree or an absent storage mount could consume space needed by unrelated workloads. Management access also needs a different boundary from public application access.

03 / Objectives

Objectives

Preserve the working services and existing disk layout. Bound application storage, keep administration on a private overlay, and make startup checks explicit enough to reject an unexpected storage state.

04 / ARCHITECTURE

Follow the components.

FRAME / 02 · CONCEPTUAL TOPOLOGY

Public surface. Private control.

EDITORIAL VIEW
NO PRIVATE TELEMETRY

INSPECT / INTERNET

Visitors reach published applications. This conceptual map makes no live requests to the lab.

05 / Implementation

Implementation

Docker Compose defines application stacks; systemd orders services around their dependencies. Nextcloud’s startup preflight checks the mounted filesystem, project quota and inherited directory flag. Uptime Kuma and Dozzle support health checks and log inspection. Caddy and Cloudflare provide application routing, while NetBird carries private administration.

06 / SECURITY

Security boundaries

Public applications and private administration have separate routes.
Databases and management interfaces are not published as public applications.
Public diagrams describe roles, without addresses, credentials or access policies.

07 / Testing

Testing

The current inspection checked the storage mount, filesystem quota features, directory inheritance, container health and backup timer results. Public HTTPS checks passed for the portfolio, file service and password service. Private SSH responded over the overlay; a full host reboot was not part of this inspection.

08 / Challenges

Challenges

Storage ceilings are not reservations. The capacity model includes existing datasets, application data, local recovery history and an emergency reserve. Inspection also caught a Minecraft backup guard tied to an obsolete disk device name; its repair remains an operational follow-up.

09 / Lessons

Lessons

A healthy application cannot prove that its backups work. Mount identity, backup results and physical capacity each need their own checks. Local recovery snapshots are useful, but an independent physical backup remains future work.

Project README

TomSec | Cybersecurity Homelab Projects

Classroom edition 1.1 - 17 September 2026

A sanitised, GitHub-ready learning pack centred on a hardened homelab, self-hosted services and a custom privacy proxy. It documents the security purpose of each component, provides separate lab examples and shows how to test access controls, failure behaviour and recovery.

Start with the handbook or the project overview.

These are teaching configurations, not an export of the author's servers. Use a fresh VM, your own accounts and disposable data. Real endpoints, private keys, proxy profiles and production configuration are not included.

Projects and security objectives

Project	Security objective	Guide
Linux and Docker homelab	Understand privilege, persistence and attack surface	01
Self-hosted NetBird	Separate device enrolment, network access and app login	02
Private HTTPS with Caddy	Encrypt access and verify the correct server	03
Vaultwarden	Close registration, disable server admin and practise MFA/recovery	04
Nextcloud with PostgreSQL and Redis	Isolate data services and verify trust, quotas and permissions	05
Immich	Control photo-library access and understand its recovery set	06
Security monitoring and DNS filtering	Detect outages, review logs privately and test DNS policy	07
Host and container hardening	Key-based SSH, private administration and exposure reduction	08
Custom Xray/REALITY proxy	Separate Mullvad internet egress from authorised NetBird destinations	09
Ingress and access-control verification	Distinguish public app access from private management	10
Backup and restore	Recover a usable service, not just produce an archive	11
Safe sharing	Publish examples and evidence without operational secrets	12

Scope and provenance distinguish reported original work from new classroom hardening measures. The proxy chapter includes server/client configuration templates, selective WireGuard egress, a narrow egress guard, and a connection-failure test matrix. It is not a copy of a live proxy profile.

Begin with the private homelab

Follow chapters 01-03 in order on a fresh Debian lab. The core stack binds HTTPS only to server loopback; reach it using the documented SSH local forward. No paid VPS is needed for this first local exercise. Self-hosted NetBird and the advanced proxy exercise require additional machines/accounts and may incur costs.

From the extracted repository root on the lab server:

python3 scripts/init_env.py
cd labs/core
sudo docker compose config -q
sudo docker compose config --lock-image-digests -o compose.images.yaml
sudo ./lab.sh up -d caddy vaultwarden uptime-kuma

The browser names, CA verification and SSH tunnel in chapter 03 are required. An HTTPS error before those steps is expected. Do not change a binding to 0.0.0.0 merely to make an error disappear.

Security checks without deployment

With Python 3.11 or newer, from the root:

python3 -m unittest discover -s tests -v
python3 scripts/check_proxy.py labs/proxy/server.json.example

These check examples and helper behaviour, not the live security of a server. Run scripts/check_bindings.py against normalised Compose JSON as described in the handbook, not against the YAML file itself. See VALIDATION.md for the exact authoring checks and untested deployment steps.

Repository layout

README.md                  Start here
pdf/                       Revised handbook and overview
docs/                      Editable Markdown chapters
diagrams/                  Mermaid source diagrams
labs/core/                 Private self-hosted application stack
labs/proxy/                Xray, WireGuard, TLS-target and guard templates
labs/hardening/            SSH baseline and narrow management guard
labs/immich/               Matching-release installation notes
scripts/                   Secret generation, checks and encrypted core backup
tests/                     Deterministic safety/configuration tests
SOURCES.md                 Primary technical references and provenance
VALIDATION.md              Checks actually performed
VERSION-RECORD.md          Record YOUR installed versions and results

Privacy, licensing and publication

No production domains, server addresses, account handles, passwords, tokens, private keys, original screenshots or personal media are supplied. Reference URLs belong to upstream projects; illustrative addresses are not the author's. No unauthorised-access exercises, copyrighted media bundles or licensing bypasses are included. Proxy use must comply with the network owner's permission.

Use your own measured results and follow course attribution/assistance rules. New teaching material is MIT-licensed; upstream applications keep their own licenses. No remote repository or live server was changed for this edition.

Rebuild the PDFs

The finished PDFs are included. The optional builder uses Python 3.13, WeasyPrint 68.0 and markdown-it-py 4.2.0, with WeasyPrint's native dependencies and DejaVu system fonts. No font files are bundled.

python3 tools/render_pdfs.py

Review the new PDFs and repeat publication checks after editing.