CASE STUDY / 04 / SYSTEMS & INFRASTRUCTURE
Turning an old PC into useful infrastructure.
A self-hosted Linux server for a personal media archive, Tailscale-based administration and experiments in maintaining services.
RECRUITER BRIEF / WHAT THE EVIDENCE SUPPORTS
My engineering work
Configured an Ubuntu server, containerized photo archive and private Tailscale administration on a repurposed HP desktop.
Inspect first
Real read-only host command output records the i5-8500, one 4 TB-class HDD and four healthy Immich containers at capture time.
Operational boundary
A point-in-time host snapshot, not proof of uptime or backup recovery. An off-host backup and restore test remain outstanding.
Start with a problem. Build a system.
The original goal was replacing recurring cloud photo storage with a server I could maintain myself. A refurbished office PC became a place to learn Linux administration, storage choices, networking, backup practices and long-running service behavior.
Once the server was useful for one job, I could experiment with tools that support my other work. Running services is an ongoing responsibility: availability, maintenance and access control matter as much as the initial setup.
Small hardware. Many responsibilities.
The diagram explains how I use the machine. The terminal captures below document the storage and services observed on the Ubuntu host on October 14, 2026. The memory configuration and OS-visible measurement are distinguished in the hardware note below.
/mnt/storage. They do not establish the OS disk or storage media type. Tailscale is the intended private access path, but the capture only proves its service was active; it does not demonstrate client reachability. One volume is not redundant storage or a complete backup plan.Personal media archive
Immich and an iCloud import directory support the server's photo and video archive.
Private-network administration
Tailscale is part of the access design. The captured service-active result alone does not verify remote reachability, firewall rules or public-port exposure.
Containers I can inspect
Docker runs Immich with its PostgreSQL, Redis-compatible, and machine-learning services. All four reported healthy at capture time.
Inside the running server.
These are selected read-only results captured directly on my Ubuntu machine and re-typeset as plain terminal transcripts, not literal application screenshots. The archived output is preserved as captured, with network addresses, credentials, and private photos excluded.
Swipe across the terminal panels to read the remaining columns, or open either image at full size.
/mnt/storage. Memory context is documented in the configuration note below. View full image ↗
Commands recorded October 14, 2026 · Read the underlying command results ↗
From command output to a responsible infrastructure decision.
- Storage inventory
lsblkreports a 238.5G disk and a 3.6T disk;df -h /mnt/storageidentifies/dev/sdb1as the mounted volume, with 153G used at capture time. Neither command proves the OS disk, disk medium or where Immich stores its media. - Service dependencies
docker psanddocker inspectshow four running, healthy Immich-related containers: server, PostgreSQL, Redis and machine learning.systemctl is-activeshows Docker and Tailscale active in the same capture. These are distinct checks, not evidence of 24/7 availability or that a remote client successfully connected. - Engineering consequence
The mounted 4 TB-class volume has no demonstrated redundancy. The next defensible reliability claim requires a separately stored backup and a demonstrated restore; neither is established by this snapshot. The transcript is a privacy-redacted selection, not a full raw terminal session.
Read redacted command transcript ↗Review recovery limitations ↓
Useful infrastructure is maintained.
A server that works once is a demonstration. A server that remains useful over time requires monitoring and routine maintenance. The valuable learning has come from storage organization, permission issues, changing network conditions and making services accessible when I need them.
Think beyond installation
Data location, startup behavior, service dependencies and recovery need explicit decisions.
Respect failure modes
The data currently sits on one 4 TB HDD. An independent off-host backup and restore test remain important next steps.
Minimize exposure
A private mesh connection is easier to reason about than indiscriminately forwarding services to the internet.
What I'm exploring next.
The machine is also a playground for task routing and automation. In my public post I described using a tool-based agent setup for academic and engineering workflows. I am separately developing research automation that processes public information and alerts based on chosen conditions. These projects are evolving and are not presented as finished production services.
This project taught me to think about the system around the software: computing hardware, networks, reliability, access and maintenance. Original LinkedIn build post ↗
Discuss the system