From RAW Photos to a Full Kubernetes Homelab

I started with a simple need: photography. My photo library was growing quickly, and I wasn’t just storing JPEGs — I wanted to keep RAWs. That’s a very different storage problem because it expands fast and never really stops. At the same time, I had access to some older server hardware along with a few parts of my own. Paying for Google Drive or Dropbox every year felt expensive and limiting, especially when I knew my storage demand would only increase.So I built a home server. That was the first milestone.

Stage 1: Storage That I Owned and Could Scale

The initial goal was practicality: keep my photos safe, keep them local, and keep the cost predictable. But the moment I moved to local infrastructure, I started thinking differently. Instead of “How much storage can I afford?” I started asking “How do I design storage that lasts?”That led me into:

• Dedicated storage for large media libraries
• Planning for growth, not just the current size
• Backups that wouldn’t depend on third-party service

Over time this became more than just a file server. It became the foundation for everything else.

Stage 2: A Real Linux Platform, Always On

Once the storage was stable, I wanted more. I wanted a native Linux environment that I could actually live in — not a VM on my laptop, but a real server that I control end-to-end. That’s when I started experimenting with services, containers, and workflows.This shift in mindset mattered: the server wasn’t just for storage anymore. It became a stable place to build and test.

Stage 3: Homelab as a Learning Platform

As I iterated, I realized the most valuable thing was the freedom to learn by doing. I wanted test environments. I wanted to host tools locally. I wanted to see how real systems behave.That pushed me toward Kubernetes and GitOps as the organizing structure for the lab:

• ArgoCD for GitOps-style deployment and drift correction

• Tilt for local development workflows

• Taskfile to standardize and automate repeatable workflows

• GitHub Actions for CI/CD validation and automation

I started thinking like an operator rather than a user: how to validate changes, how to roll back, and how to keep services healthy.

Stage 4: From Single Server to Real Services

As the platform matured, I started layering in applications that matched the original purpose (media and storage) but also expanded into new interests.Key services and how they fit the story:

• Immich for photo management

This became the primary photo platform, backed by PostgreSQL and Redis. Storage is provisioned via dedicated PVs and a large-disk StorageClass to support big media libraries.

• Immich Backup (rclone) for safety

A daily Kubernetes CronJob mirrors the library to a NAS over the Tailscale network. The key idea is safety without deletion: rclone copy adds and updates, but never deletes on the destination.

• Nextcloud for “drive-like” storage

This gives me a more flexible file layer, with storage on hostPath and PostgreSQL/Redis supporting it.

• Ollama for a local LLM

Running a local model was a natural progression once I had GPU resources available. It’s exposed behind ingress and runs on an AMD 6700 XT with ROCm support.

• Glance dashboard to keep the system visible

A homelab grows quickly. A dashboard makes it manageable.

Stage 5: Networking That Feels Like the Internet (But Is Mine)

The more services I hosted, the more the network mattered. I needed secure access but also simplicity and good performance.This is where the VPN and mesh layer came in:

• WireGuard as the original VPN

A standard, reliable baseline.

• Headscale as the Tailscale control plane

This gave me a mesh VPN architecture with direct peer-to-peer connections when possible.

• Tailscale clients inside the cluster

Persistent state, monitoring sidecars, and automatic reconnection.The performance benefit of mesh networking made a real difference. Instead of routing through a single VPN endpoint, devices could connect directly when possible. It’s a huge latency drop for local device communication.

Stage 6: Ingress, TLS, and Real Routing

Once multiple services were running, I needed a real entry layer:

• Traefik as ingress controller

Handles routing and TLS.

• Cert Manager for automated TLS

Let’s Encrypt managed certificates, keeping services secure without manual overhead.

• Cloudflare DDNS

Keeps the dynamic public IP updated so the ingress layer remains reachable.The result is a clean flow:Cloudflare DNS → Traefik TLS → IngressRoute → ServiceIt’s predictable, secure, and as close to a “real” production setup as I can get in a homelab.

Security and Operational Discipline

As the project evolved, security stopped being optional:

• Non-root containers wherever possible

• Read-only root filesystems

• RBAC and network policies

• TLS everywhere

• Isolated service boundaries

That wasn’t just for correctness — it was part of the point. I wanted to run infrastructure the right way, not just the easy way.

What This Became

What started as a storage solution for photography turned into a platform for learning, experimentation, and real systems work.I learned:

• Storage design for large datasets

• Service orchestration and resilience

• GitOps workflows for safe change delivery

• Observability, security, and networking at a real scale

And that learning loop is still alive. Every change is still part of the same process: iterate, test, improve.

Why I Keep Building It

At the core, I wanted control, reliable storage, and cost predictability. But I ended up building something more valuable: a system that teaches me how infrastructure really works. It gives me the ability to:

• Host the tools I care about

• Learn by building real systems

• Own my data and scale on my terms