01 / PURPOSE
A household system.
An engineering classroom.
I’m building a useful self-hosted environment while developing practical skills for my AI Software Engineering degree. The goal goes beyond installing applications: connect the services, automate repeatable work, investigate failures, and verify the results.
Repurposed hardware creates real constraints. Virtualization, resource limits, and careful storage handling help the lab support everyday services alongside experiments.
- Compute
- Repurposed Dell computer · Intel Core i7-2600 · 16 GB RAM
- Virtualization
- Proxmox VE · Linux containers · Home Assistant virtual machine
- Application hosting
- Debian Linux and Docker
- Separate storage
- Western Digital My Cloud NAS · shared media and backups
- Disc input
- Internal SATA DVD drive
02 / SYSTEM DESIGN
The lab at a glance.
A logical overview of the environment. Service placement is simplified rather than presented as an exact network topology.
COMPUTE / VIRTUALIZATIONDell · Proxmox VECore i7-2600 · 16 GB RAM · VMs + Linux containers
Home Assistant VMSmart-home integrations
Debian / DockerApplication hosting
Lab servicesMedia · DNS · monitoring · Hermes
SEPARATE PHYSICAL STORAGEWD My Cloud NASShared media + scheduled Proxmox backupsJellyfin media access is read-only.
Telegram ↔ Hermes / Vega ↔ external AI providerThe agent runs on the lab server. The language model runs with an external provider.
03 / SELF-HOSTED SERVICES
Useful services, connected.
AI-assisted operations
Hermes Agent / Vega
An assistant accessed through Telegram to inspect systems, troubleshoot problems, and develop automation. Hermes runs on the lab server and connects to an external AI provider; the language model is not hosted locally.
Home automation
Home Assistant
Smart-home integrations and automation experiments, running in a dedicated virtual machine.
Media services
Jellyfin
A self-hosted media library and playback service, with read-only access to NAS media.
Media services
Dispatcharr
Live TV stream and programme-guide management feeding Jellyfin.
Media automation
Automatic Ripping Machine
A DVD-processing workflow using MakeMKV and HandBrake, with output validation and verified transfers.
Networking
Pi-hole
DNS filtering and local hostname resolution.
Observability
Uptime Kuma
Service-availability monitoring alongside scheduled health checks.
04 / AUTOMATION
From disc to a verified library.
Python and shell scripts support service checks, media transfers, and application API calls. The DVD workflow makes correctness visible at each handoff.
- 01
Detect & identify
Detect the inserted disc and identify its contents.
- 02
Rip & encode
Process the disc with MakeMKV and HandBrake, within configured resource limits.
- 03
Validate output
Check the completed video before treating the job as successful.
- 04
Transfer & verify
Copy files to the NAS and verify them with SHA-256 checksums.
- 05
Clean up safely
Remove the local completed copy only after the transfer has been verified.
- 06
Refresh the library
Trigger a Jellyfin library scan after a verified transfer.
Quiet when healthy. Clear when something changes.
Scheduled health checks send down/recovered notifications instead of constant status messages. Lightweight routine checks run without calling an AI model.
05 / FEATURED ENGINEERING PROBLEM
The job said “success.”
The movie was missing.
A DVD-processing job reported success, but the movie never appeared in Jellyfin. Working with my AI assistant, I followed the trail through application logs, database records, and the filesystem.
Title filtering↓MakeMKV renumbered the saved file↓ARM expected the original filename↓Move failure was ignored; staging files were cleaned up
Repair the completion logic.
- Use the actual saved filenames rather than assuming the original title numbering.
- Propagate move errors and stop cleanup when a move fails.
- Validate media output before declaring completion.
- Reject zero-title and partial-copy results as successful jobs.
VALIDATION
Tests, then actual media processing.
The repair passed eight regression tests and a real short HandBrake encoding test inside the ARM environment. Subsequent DVD jobs completed through to NAS storage and Jellyfin.
06 / OPERATING SAFEGUARDS
Put boundaries around the work.
Access
Key-based SSH for server administration; credentials kept out of source code and public documentation.
Service separation
Separate virtual machines and containers for different services.
Resource limits
CPU, memory, and process limits keep DVD processing from overwhelming the server.
Storage permissions
Jellyfin reads NAS media through read-only access.
Backups
Scheduled Proxmox backups are stored on a separate physical NAS.
Human approval
Sensitive AI-assisted actions require approval before execution.
Current limitsThese are practical safeguards. They are not a claim that the lab is fully hardened or that the backups have been disaster-recovery tested.
07 / REFLECTION
Learning from what failed.
Success needs evidence
A success report is not enough. The expected output must exist, be valid, and reach its destination.
Cleanup is part of correctness
A failed move must stop cleanup, or an error can become lost data. Verification belongs before deletion.
Use AI with boundaries
AI can help investigate and build, while lightweight routine checks and human approval keep operations deliberate.
Skills demonstrated
Linux administrationVirtualizationDockerNetworkingAPI integrationPythonShell scriptingSystematic debuggingRegression testingData-integrity checksResponsible AI-assisted tooling
A foundation for further work
The lab remains an ongoing environment for building automation, investigating failures, and checking that the result matches the intended outcome. Backup restoration still needs hands-on validation.