Projects · the standing entries

The Lab.

Everything I've got running — 23 containers across two VMs on a Proxmox host, and one device I put together myself. Some of it took way longer than it should have.

Open read the story on any entry for the diagram and the actual context.

Entries

newest first is not the order — this is how it was built

01Jellyfin

Self-Hosted Media Stack

Full *arr stack: Jellyfin for streaming, Radarr + Sonarr for automated movie/TV downloads, Prowlarr for indexer management, qBittorrent tunneled through Gluetun VPN, Bazarr for subtitles, Unpackerr for archive extraction, Decluttarr clearing out stalled grabs.

JellyfinRadarrSonarrProwlarrqBittorrentGluetunDocker

you ─▶ Radarr / Sonarr ─▶ "I want this"
            │
      ┌─────┴─────┐
   Radarr      Sonarr        ← the *arrs
      └─────┬─────┘
        Prowlarr  ◀── indexers
            │ hands off to
       qBittorrent
            │  ALL traffic via
         Gluetun VPN ──▶ internet
            │ lands on
     media NVMe ──▶ Jellyfin ──▶ TV

This is the project that started the whole homelab, honestly. I just wanted Plex without paying for Plex, and it kind of snowballed into a full automation pipeline. The flow: Radarr and Sonarr go grab what I've asked for, Prowlarr feeds them indexers, and qBittorrent does the actual download — but only ever through the Gluetun VPN, so if the tunnel drops, nothing leaks. It lands on a local NVMe in the Proxmox box and Jellyfin serves it to the TV. The part that took way too long was the VPN kill-switch and getting qBittorrent to talk to the *arrs through Gluetun's network — one wrong firewall port and the whole queue silently stalls. I've rebuilt that container combo more times than I'd like to admit. I've since pulled two pieces back out. Tdarr was doing iGPU H.265 transcoding, but it sat resident 24/7 for a job that's really a batch task — so it came out. Jellyseerr went the same way once I noticed I was requesting things directly in the *arrs anyway. Deciding what to remove turned out to be a bigger part of running this than deciding what to add.

02Vaultwarden

Zero-Trust Access & Security

Vaultwarden (self-hosted Bitwarden) with Argon2id admin token and disabled registration. Nginx Proxy Manager handling all .lan domains with wildcard self-signed cert plus Let's Encrypt certs via Cloudflare DNS-01. Cloudflare Tunnels for public exposure with no open ports. Tailscale subnet routing for remote access. Fail2ban blocking brute-force attempts on exposed services.

VaultwardenNPMCloudflare TunnelTailscaleFail2ban

  internet
     │   no ports forwarded. ever.
     ▼
Cloudflare Tunnel ─▶ NPM (TLS) ─▶ services
                        │
me, away ─▶ Tailscale ─▶ the LAN
secrets  ─▶ Vaultwarden  (Argon2id, signups off)
noise    ─▶ Fail2ban ─▶ banned

The rule I set for myself: nothing on this network has a port forwarded on the router. Ever. If something's reachable from outside, it's because a Cloudflare Tunnel reached out to do it, or I'm on Tailscale. Everything internal goes through Nginx Proxy Manager with TLS, passwords live in my own Vaultwarden (registration disabled, Argon2id on the admin token), and Fail2ban watches anything exposed and bans the obvious brute-force noise. Being a security student, this is the part I actually care about getting right. It's a lot easier to reason about "zero open ports" than to constantly second-guess what's listening.

03Mosquitto

Home Automation Bridge

Eclipse Mosquitto MQTT broker enabling smart home devices (IR blasters, sensors) to communicate with Home Assistant. Auth-required with password file. Bridges a LinknLink eRemote to Home Assistant for IR control.

MosquittoMQTTHome AssistantIoTLinknLink

 IR / RF signals
      │
LinknLink eRemote
      │  publishes
Mosquitto  (MQTT, auth required)
      │  subscribes
Home Assistant ─▶ automations fire

Smaller project, but a fun one. I've got a LinknLink eRemote that blasts IR, and I wanted Home Assistant to control the dumb IR stuff — the AC, some old gear — like it was smart. Mosquitto sits in the middle as the MQTT broker, auth required, because an open broker on your network is basically a free microphone for anyone who finds it. The device publishes, Home Assistant subscribes, automations fire. Nothing flashy, but it's the kind of glue that makes the whole "smart home" thing actually work instead of being five apps that refuse to talk to each other.

04Uptime Kuma

Monitoring & Observability

Uptime Kuma checking every service at 60-second intervals with Docker socket access for real-time container state, and a Discord webhook that yells at me when something actually breaks. The Prometheus + Grafana pair that used to sit on a dedicated monitoring VM was retired 2026-09-29 along with the SIEM below.

Uptime KumaDiscord webhook

Docker host
┌───────────────┐
│ Uptime Kuma   │──▶ Discord webhook
└───────────────┘
  pings every service every 60s

You can't fix what you can't see, so this layer exists so I'm not flying blind. Uptime Kuma pings every service every 60 seconds and yells at me the second one drops. The honest reason it exists: I got tired of finding out something was down by trying to use it and getting an error. Now I usually know before anyone else in the house does. A cAdvisor/node-exporter → Prometheus → Grafana pair used to sit on a dedicated monitoring VM alongside the SIEM below; I retired the whole VM 2026-09-29.

05Obsidian LiveSync

Self-Hosted Knowledge Sync

Obsidian LiveSync on a self-hosted CouchDB keeps notes synced across every device in real time, replacing the $5/month Obsidian Sync subscription. A LiveSync Bridge container mirrors the whole vault back out as plain Markdown on disk, so scripts — and the automation on the server — can read and write the same notes my laptop sees.

Obsidian LiveSyncCouchDBLiveSync BridgeMarkdownNotes

phone   ─┐
laptop  ─┼─▶ Obsidian LiveSync ─▶ CouchDB
desktop ─┘       real-time           │
                          LiveSync Bridge
                               │
                    plain .md files on the server
                    (read/written by the lab's scripts)

        stays on my hardware · goodbye $5/mo

I take a lot of notes — homelab stuff, CTF writeups, class — and I didn't love paying $5 a month for Obsidian Sync when I've got a perfectly good server sitting right there. So I stood up CouchDB and pointed Obsidian LiveSync at it. My vault syncs across every device in real time, the data never leaves my hardware, and the subscription's gone. The part that turned out to matter more than the money: a bridge container mirrors the vault into plain Markdown files on the server, both directions. That's what lets everything else write into it — the nightly automation, my task list, the docs for this whole lab. A note written on the server shows up on my laptop seconds later, which means the server and I are genuinely taking notes in the same place.

06Proxmox

Storage

The media library lives on the Proxmox host's second NVMe, handed to the Docker VM as a 430 GB virtual disk and mounted at /mnt/media. Downloads and the library share one filesystem, so imports are instant hardlinks. Kept out of the VM backups on purpose — the media can be re-downloaded.

ProxmoxNVMeext4fstab

Proxmox host · second NVMe (was the SIEM's)
     │  430 GB virtual disk, backup=0
     ▼
Docker VM  →  /mnt/media  (ext4)
     ├─ movies · tv · Devs Media  ─▶ Jellyfin
     └─ downloads  ─▶ hardlinked into the library
VM backups stay on the host's first NVMe

When the SIEM left, it freed a whole NVMe in the Proxmox box. The library was about 300 GB, so it fit, and the media now sits on that drive as a virtual disk on the Docker VM — one less machine running in the corner. Downloads and the library share one filesystem, so an import is an instant hardlink instead of a copy. The trade I'm making with open eyes: one drive, no RAID. Movies and shows can be downloaded again, so that disk is deliberately left out of the backups, and the VM backups themselves now live on the host's other drive until I have somewhere off-box to send them.

07Watchtower

Automation & Maintenance

Watchtower auto-updating all labeled containers nightly. Recyclarr syncing TRaSH Guides quality profiles to Radarr/Sonarr daily. Host OS auto-updates via unattended-upgrades with a Discord webhook notifying on success/failure, rebooting in the early morning if needed. Every scheduled job gets a timeout, a failure alert, and a watchdog that notices when it stops running at all.

WatchtowerRecyclarrunattended-upgradescronDiscord Webhooksystemd

Watchtower          ─▶ pulls new images nightly
Recyclarr           ─▶ syncs TRaSH quality profiles
unattended-upgrades ─▶ patches the host OS
cron guard          ─▶ watches the jobs themselves
        │  on every run
  Discord webhook ─▶  green / orange / red
after any reboot ─▶ boot check posts what came back

The goal here is to do as little manual maintenance as possible. Watchtower updates containers overnight, Recyclarr keeps my Radarr/Sonarr quality profiles in line with the TRaSH guides, and the host patches itself with unattended-upgrades and reboots in the early morning if it has to. The piece I'm weirdly proud of is the Discord webhook — every update run pings me with green, orange, or red so I know what happened without logging in. It took a couple of tries to stop it from false-alarming on every single run, but now it just quietly works. The lesson that cost me the most: a scheduled job that fails silently is worse than no job at all, because you trust it. So everything on a timer now has a timeout, an alert when it fails, and a separate watchdog that notices if it stops running entirely. After any reboot, a boot check posts to Discord confirming Docker, the media disk, the containers and DNS all actually came back.

08AdGuard Home

DNS & Network Layer

AdGuard Home as the primary DNS server with ad blocking, custom .lan rewrite rules for all services, and DHCP-configured clients. All .lan domains resolve to the Docker host and route through NPM. DOCKER-USER iptables rules for container network security.

AdGuard HomeDNSiptablesNetworking

every device ─▶ AdGuard Home (DNS)
                  │ blocks ads + trackers
                  │ resolves *.lan names
                  ▼
             NPM ─▶ the right service
container traffic ─▶ DOCKER-USER iptables rules

AdGuard Home is the DNS for the whole house. It blocks ads and trackers network-wide and resolves all my internal names to the right place through the reverse proxy. The catch with running the only DNS server on your network is that when it's unhappy, everything looks broken. I once spent an entire evening convinced AdGuard had died, when really the upstream resolver was timing out and a router reboot fixed it in thirty seconds. Lesson logged. Container network rules are locked down through the DOCKER-USER iptables chain — never UFW, because UFW and Docker fight and Docker always wins.

09Kali Linux

Pentesting & CTF

Actively working through TryHackMe rooms and CTF competitions to practice offensive security. Hardware includes a Flipper Zero for wireless/RFID/IR research, a Pwnagotchi for wifi handshake capture, and a dual ESP32 setup for wireless experimentation. Daily drivers: Kali Linux, nmap, and gobuster.

Kali LinuxnmapgobusterTryHackMeCTFFlipper ZeroPwnagotchi

TryHackMe / CTFs ─▶ reps on the offensive side
┌──────────────── the gear ────────────────┐
│  Kali  ·  nmap  ·  gobuster               │
│  Flipper Zero   → RFID / IR / sub-GHz     │
│  Pwnagotchi     → wifi handshakes         │
│  dual ESP32     → wireless tinkering      │
└───────────────────────────────────────────┘

This is the "breaking things on purpose" half of the hobby, and the part that actually lines up with what I'm studying. I work through TryHackMe rooms and CTFs to get reps with the offensive side — recon, enumeration, the usual nmap-then-gobuster dance. On the hardware side I've collected a Flipper Zero for RFID/IR/sub-GHz, a Pwnagotchi that quietly farms wifi handshakes, and a couple of ESP32s for wireless experiments. All of it on my own gear and my own networks — the whole point is understanding how the attacks actually work so I know how to defend against them.

10Wazuh

SIEM & Security Monitoring (retired 2026-09-29)

A dedicated VM ran the full Wazuh stack (manager, indexer, and dashboard) for log ingestion and threat detection, with Prometheus + Grafana tying the metrics together. Hands-on practice with the SIEM/EDR concepts I'm studying in school, retired 2026-09-29.

WazuhPrometheusGrafanaEDRRetired

both machines ─▶ logs + events
      │
      ▼
Wazuh   (manager · indexer · dashboard)
  ├─ threat detection + rules
  └─ EDR-style agent telemetry
metrics ─▶ Prometheus ─▶ Grafana

[retired 2026-09-29 — VM destroyed]

This was the project I was most invested in, because SIEM and EDR are exactly what I'm learning in school — so I stood one up instead of just reading about it. A dedicated VM ran the full Wazuh stack: manager, indexer, and dashboard, ingesting logs and flagging suspicious behavior across everything on the network. Getting hands-on with real detections, tuning out the noise, and watching what actually trips the rules taught me more than any slide deck did. I retired it 2026-09-29 — a home SIEM isn't something corporate security teams naturally value, so my energy is better spent elsewhere for now.

11Astro

This Website

Astro, server-rendered by Node in a container on the homelab and published through a Cloudflare Tunnel — no cloud host, no open ports, no monthly bill. The container count, CPU and RAM figures on the home page are pulled live from the Portainer and Proxmox APIs when you load it, and the live page keeps refreshing itself after that.

AstroDockerCloudflare TunnelNode.js

visitor ─▶ Cloudflare Tunnel ─▶ this box
                                  │
                           Astro (SSR / Node)
                                  │ pulls live
                       Portainer · Proxmox
      no cloud host  ·  no monthly bill

You're looking at it. This site is served straight off the homelab through a Cloudflare Tunnel — no cloud hosting, no monthly bill, just a container on the same box as everything else. It's built with Astro and rendered on the fly by Node, which is why the container count and the live dashboard aren't screenshots — they're pulled from the Portainer and Proxmox APIs when the page loads, and the live page keeps refreshing itself after that. Same as everywhere else here: Claude wrote the site, I decided what went on it and what wasn't good enough to keep. The words about me are mine.