What it is

The server hosts storage, media, productivity tools, monitoring, and automation for everyday use. It runs headlessly on repurposed hardware and stays online around the clock.

Each service runs in its own Docker container, alongside custom scripts and internal tools. I manage their configuration and updates from the same Linux host.

Services and Uptime

A Compose project may contain multiple containers. Private connection and configuration details are omitted.

Why I built it

I wanted real infrastructure experience, not just code that deploys somewhere I never touch. Running my own server means thinking about reliability, security, backups, and debugging in ways side projects alone do not cover.

It also replaced a growing list of monthly subscriptions with tools I own and understand. When something breaks late at night, I fix it—and that cycle of building, breaking, and recovering is where most of the learning happens.

Security and access

The core rule is simple: nothing sits open on the public internet. Anything I reach from outside home passes through encrypted tunnels and has to authenticate first, including hardware-backed multi-factor authentication before a session starts.

Private devices connect over a mesh VPN as if they share the same local network. Workloads live on segmented Docker networks, containers run with minimal privileges, and DNS-level filtering cuts down junk and risk across the environment.

Keeping it running

Getting a server working once is easy. Keeping it reliable for months is the real work. I use uptime monitoring and alerting to catch problems early, and I track disk health because consumer hardware rarely warns you before it fails.

When a new need comes up, I write the script or service, containerize it, and ship it alongside the rest of the stack. Routine updates, backup checks, log digging, and the occasional late-night container restart are all part of operating something you depend on every day.

Lessons learned

The biggest takeaway is the difference between making something work once and keeping it working indefinitely. Coursework ends when the assignment ships; a homelab has to survive hardware failures, upstream updates, and the kind of slow drift that breaks things in ways no test suite catches.

I learned to think about failure modes before they happen—backups that are actually tested, monitoring that alerts before users notice, and network segmentation that limits blast radius when something goes wrong. Reliability is not a feature you bolt on; it is a habit you build into every decision.