Services on homelab

BlueBikes API Feeds Guide

Fri, 01 May 2026 00:00:00 +0000

BlueBikes API Feeds Guide#

What Was Established#

Comprehensive breakdown of BlueBikes GBFS (General Bikeshare Feed Specification) endpoints.
JSON structure analysis for static (station_information) and real-time (station_status) feeds.
JavaScript patterns for fetching, joining, and displaying station data.

Key Decisions#

Base URL: https://gbfs.lyft.com/gbfs/1.1/bos/en/
Primary Feeds: station_information (static map/location data) and station_status (live availability) are the core feeds for real-time tracking.
Join Strategy: Match station_id fields between static and status feeds to combine location metadata with live bike/dock counts.

Current Configuration#

Core GBFS Endpoints#

Feed	Purpose
`station_information`	Static station list, names, IDs, coordinates, capacity, kiosk info
`station_status`	Real-time bike/dock counts, station active/inactive status, last reported timestamp
`system_information`	System metadata (operator, name, URLs)
`system_regions`	Regional breakdowns for color-coding/mapping
`system_hours`	Operating hours
`system_calendar`	Start/end years, holidays
`gbfs_versions`	Available GBFS versions
`free_bike_status`	Free-floating bike locations
`ebikes_at_stations`	Real-time e-bike counts per station
`system_pricing_plans`	Membership & pricing details
`system_alerts`	Current advisories

Data Structure Examples#

station_information

Gluetun VPN Service

Fri, 01 May 2026 00:00:00 +0000

Gluetun VPN Service#

What Was Established#

Gluetun is a lightweight Docker container acting as a dedicated VPN gateway for other containers.
Implements the sidecar pattern: dependent containers (e.g., qBittorrent, nzbget, prowlarr) share Gluetun’s network namespace via network_mode: "service:gluetun".
AirVPN selected as the provider over ProtonVPN/Mullvad due to superior port forwarding support required for P2P services.
Container-level VPN on the servarr VM is architecturally separate from the network-level UniFi VPN on Helms Deep (VLAN 2).

Deployment Context#

Gluetun runs on the servarr VM (192.168.1.112) as part of the Servarr Docker Compose stack at /docker/servarr/. It is configured via .env file in that directory.

Hinterflix Help Site - Cloudflare Deployment

Fri, 01 May 2026 00:00:00 +0000

Hinterflix Help Site - Cloudflare Deployment#

What Was Established#

The Hinterflix help site (help.hinterflix.com) is deployed as a static Hugo site on Cloudflare Workers. The domain is managed within the same Cloudflare account.

Key Decisions#

Hosting: Cloudflare Workers Pages (static hosting).
Domain: help.hinterflix.com (root subdomain of hinterflix.com).
DNS: CNAME record pointing to the Cloudflare Workers subdomain (*.workers.dev). Proxy status set to Proxied (orange cloud).
SSL/TLS: Automatically provisioned by Cloudflare. “Always Use HTTPS” enabled in SSL/TLS settings.

Configuration Steps#

Cloudflare DNS Setup:

Homelab Dashboard

Fri, 01 May 2026 00:00:00 +0000

Homelab Dashboard#

What Was Established#

A Node.js + Express dashboard is deployed at https://status.nbkelley.com, serving homelab monitoring data. All API calls are server-side — no internal IPs, credentials, or raw API responses reach the browser.

Deployment#

Detail	Value
Public URL	https://status.nbkelley.com
Host	proxy VM (192.168.1.222)
Port	3002
Runtime	Node.js + Express, Docker container
compose.yaml location	/home/iluvatar/compose.yaml on proxy VM
App directory	/opt/homelab-dashboard/ on proxy VM
Routing	Cloudflare Tunnel → 127.0.0.1:3002

File Structure#

/opt/homelab-dashboard/
  server.js         ← Express app, all API logic
  package.json
  package-lock.json
  dockerfile
  start.sh
  node_modules/
  public/
    index.html
    styles.css
    app.js          ← frontend render engine

compose.yaml Entry#

homelab-dashboard:
  build: /opt/homelab-dashboard
  container_name: homelab-dashboard
  restart: unless-stopped
  network_mode: host
  environment:
    - PORT=3002

network_mode: host means the app binds directly to host port 3002. The ports: mapping is ignored when using host networking.

Hugo Deployment to Cloudflare Pages - Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Patterns for resolving missing assets (favicons, CSS, styling) and build failures when deploying Hugo-generated static sites to Cloudflare Pages.

Key Decisions#

Build Configuration: Set build command to hugo, output directory to public, and explicitly match the local Hugo version in Cloudflare Pages settings.
Static Asset Placement: Ensure all static files (e.g., favicon.ico, CSS) reside in the static/ directory root or theme-specific static folders.
Rebuild Enforcement: Use hugo --cleanDestinationDir or manually remove the public/ directory to force Hugo to regenerate all assets and detect changes.
Cache Management: Clear both Cloudflare Pages deployment cache and browser cache to prevent stale asset delivery.
Verification Workflow: Validate locally via hugo server, inspect the generated public/ directory, review Cloudflare deployment logs, and confirm full Git commits.

Current Configuration#

Build Command: hugo
Output Directory: public
Static Directory: static/
Config File: config.toml / config.yaml (verify baseURL matches target domain)

Obsidian Integration for Hugo Date Format#

Hugo expects ISO 8601 dates with timezone offset: 2025-11-22T23:11:12-05:00

Jellyfin Docker Compose Reference

Fri, 01 May 2026 00:00:00 +0000

Jellyfin Docker Compose Reference#

Canonical copy of /docker/jellyfin/compose.yaml on the servarr VM (192.168.1.112).

Jellyfin and Jellyseerr run in a separate compose file from the main Servarr stack, on their own Docker network (jellyfin_default, 172.18.0.0/16).

compose.yaml#

services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
      - JELLYFIN_PublishedServerUrl=http://192.168.1.112 #optional
    volumes:
      - ./config:/config
      - /data:/data
      - ./jellyfin-web/config.json:/usr/share/jellyfin/web/config.json
    devices:
      - /dev/dri:/dev/dri #Use for Intel QuickSync
    ports:
      - 8096:8096
      - 7359:7359/udp #Service Discovery
      - 1900:1900/udp #Client Discovery
    restart: unless-stopped
    labels:
      - deunhealth.restart.on.unhealthy=true
    healthcheck:
      test: curl -f http://localhost:8096/health || exit 1
      interval: 60s
      retries: 3
      start_period: 30s
      timeout: 10s
# Remove the Jellyfin service if installed directly on system.

  jellyseerr:
    container_name: jellyseerr
    image: fallenbagel/jellyseerr:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Los_Angeles
    volumes:
      - ./jellyseerr:/app/config
    ports:
      - 5055:5055
    restart: unless-stopped

Key Details#

Network: Uses the auto-created jellyfin_default bridge network (172.18.0.0/16). Jellyseerr reaches the *arr services via the host IP (192.168.1.112) and their exposed ports.
GPU Passthrough: /dev/dri:/dev/dri enables Intel QuickSync hardware-accelerated transcoding.
PUID/PGID: Hardcoded to 1000 (unlike the servarr stack which uses .env variables).
TZ: America/Los_Angeles (note: servarr stack uses America/New_York).
Healthcheck: Already configured with deunhealth label — auto-restarts on unhealthy.
Custom web config: ./jellyfin-web/config.json is bind-mounted into the container for UI customization (e.g., the Hinterflix help link).

Directory Layout#

/docker/jellyfin/
├── compose.yaml
├── config/          # Jellyfin server config
├── jellyfin-web/
│   └── config.json  # Custom web UI config
└── jellyseerr/      # Jellyseerr app config

Jellyfin Help Link Integration

Fri, 01 May 2026 00:00:00 +0000

Jellyfin Help Link Integration#

What Was Established#

Goal: Integrate a persistent, user-facing help link directly into the Jellyfin UI for logged-in users, directing them to the Hinterflix documentation.
Methods Evaluated: Custom Login Message (pre-login only), Custom CSS (Dashboard > General), Reverse Proxy HTML injection (Nginx), Custom JavaScript, and Plugin-based solutions.
Selected Approach: Custom CSS injected via the Jellyfin Dashboard. It provides immediate visibility without requiring external dependencies or server restarts.

Key Decisions#

Placement: Prioritized persistent in-interface links over pre-login messages. Options included header navigation, floating action button, and sidebar integration.
Implementation Path: Chose Dashboard > General > Custom CSS for its simplicity and zero-dependency nature compared to reverse proxy modifications or plugin development.
Target URL: The CSS href attributes should point to the deployed Hinterflix help site (e.g., https://status.nbkelley.com or the specific docs subdomain).

Current Configuration#

Location: Jellyfin Web UI → Dashboard → General → Custom CSS
Active Selectors:
- headerTabs::after for top navigation bar integration
- body::after for a fixed floating action button (FAB)
- sidebarBox:last-child::after for sidebar menu integration
Dependencies: None. Relies entirely on Jellyfin’s built-in CSS injection capability.

Historical Notes#

Conversation dated 2025-11-22.
Jellyfin’s frontend framework (Ember.js/React hybrid) frequently updates CSS class names. Selectors like headerTabs and sidebarBox may break after major Jellyfin version upgrades, requiring CSS updates.
The sub_filter Nginx approach was considered but discarded in favor of native dashboard configuration to avoid proxy overhead and cache invalidation issues.

Open Questions#

Has the chosen CSS snippet been applied and verified against the current Jellyfin version running on the homelab?
Are there any specific UX guidelines or family-user constraints that dictate the preferred placement (header vs. floating vs. sidebar)?

Sources#

ingested/chats/128-Add User to Sudoers Group Guide.md
ingested/chats/113-Adding Help Link to Jellyfin Server.md
ingested/chats/028-Basic Header with Hamburger Menu Design.md
DeepSeek conversation: “Adding Help Link to Jellyfin Server” (2025-11-22)

Jellyfin LXC GPU Passthrough & Hardware Acceleration

Fri, 01 May 2026 00:00:00 +0000

Jellyfin LXC GPU Passthrough & Hardware Acceleration#

What Was Established#

Successfully configured Intel UHD Graphics 630 GPU passthrough to a Jellyfin LXC container on Proxmox for hardware-accelerated transcoding via Intel QuickSync (QSV).

Key Decisions#

GPU Passthrough Method: LXC container-level GPU device mapping (not full VM passthrough)
Hardware Acceleration: Intel QuickSync (QSV) selected over VAAPI for Jellyfin’s native support
Monitoring Constraints: Accepted that LXC container restrictions prevent full GPU monitoring tools (dmesg, intel_gpu_top) from functioning; validated functionality through actual transcoding tests instead

Current Configuration#

Host GPU Details#

GPU: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]
PCI Address: 00:02.0
Driver: i915 (loaded)
Related Modules: drm_buddy, ttm, drm_display_helper, cec, i2c_algo_bit, video

LXC Container GPU Devices#

/dev/dri/card0 — character special (major 226, minor 0)
/dev/dri/renderD128 — character special (major 226, minor 128)
Permissions: crw-rw---- root:video (226/0 and 226/128)

Jellyfin Configuration#

User Group Assignment: jellyfin user added to video group (usermod -a -G video jellyfin)
Dashboard → Playback Settings:
- Hardware Acceleration: Intel QuickSync (QSV)
- Enable hardware encoding: Yes
- Enable hardware decoding: Yes
- Enable tone mapping: Yes
- Allow encoding in HEVC: Yes
- Allow encoding in AV1: Yes (if supported)

Validation Commands#

# Verify GPU device accessibility
ls -la /dev/dri/

# Check if processes are using GPU during playback
lsof /dev/dri/renderD128

# Monitor Jellyfin logs for hardware acceleration
sudo journalctl -u jellyfin -f | grep -i "hardware\|qsv\|quicksync\|vaapi"

# Check active transcoding sessions in Jellyfin UI
# Dashboard → Active Devices → look for (HW) indicator

Historical Notes#

dmesg restriction: dmesg: read kernel buffer failed: Operation not permitted — expected in LXC containers without full device access
intel_gpu_top limitation: GPU monitoring tools that require kernel debugfs access will not work inside the LXC; validated via actual transcoding performance and log inspection instead
i915 driver loaded: Confirmed via lsmod | grep i915 showing 3,928,064 bytes loaded
No GPU debug info: /sys/kernel/debug/dri not available in container — accepted limitation

Open Questions#

Does AV1 hardware encoding actually work on Coffee Lake-S (Gen 9.5) — typically limited to H.264/H.265
Performance baseline: what CPU load reduction is observed with QSV vs software transcoding?
Can GPU passthrough be extended to other LXC containers (e.g., Plex, if migrated)

Plex Transcoding LXC — similar GPU passthrough patterns for Plex
Proxmox LXC Configuration — LXC container setup patterns
Servarr - Media Automation Stack — media server ecosystem

Gluetun VPN Service

MBTA Dashboard - Frontend Implementation

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Frontend Implementation#

What Was Established#

A portrait-mode (1080x1920) transit dashboard displaying real-time MBTA departures, commuter rail, weather, news, and a static transit map. Hosted on PLT-MBTADisplay (192.168.168.42), served via Nginx with a Node/Express proxy that handles all external API calls server-side. Target display is a 1080p vertical screen driven by Anthias on a Raspberry Pi 3B+.

Design Evolution#

The dashboard went through several major design iterations:

Initial: Line-based cards with MBTA colors, horizontal layout for 1080p TV
Minimalist redesign: White background, grey dividers, MBTA colors only on small abbreviated line pills (RL, OL, BL, GL-B/C/D/E), smaller station-only headers with walk time
Station-based cards: Cards grouped by station (South Station, State Street, Park Street) rather than by line, with all routes listed per station
Final portrait layout: 2-column CSS Grid, flex column containers, flat time-sorted departure list with line pills, full-width static map image at bottom

Layout (1080x1920 Portrait)#

2-column, 3-row card grid above a full-width static map image
Cards flex with content height (no preset card height)
CSS Grid with grid-template-columns: 1fr 1fr

Key Features#

CSS Ticker/Marquee#

Header text that overflows its container scrolls seamlessly in a ticker
Uses CSS animation with transform: translateX() — no JavaScript
Animation speed set slow for readability

Station-Based Grouping#

Cards grouped by physical station: South Station, State Street, Park Street
Each station card shows all lines serving that station
Departures sorted by time, each with abbreviated line pill (RL, OL, BL, GL-B, etc.)
Filtered to show departures within 10 minutes walking distance

Server-Side Proxy Architecture#

All API calls proxied through Node/Express on localhost:3000
Client fetches single /api/data endpoint — no direct browser-to-MBTA calls
API keys stored in environment variables, never exposed to browser
Server-side caching with TTL to reduce upstream API calls

News Ticker#

Pulls from multiple RSS feeds (MassLive Boston, State House News)
Displays first 3 items from each feed as <title> - <description>
Modular RSS feed configuration for easy addition of new sources

Static Map#

Originally Leaflet.js with OpenStreetMap and hardcoded markers
Replaced with static image for performance on Raspberry Pi
Generated via Snazzy Maps + PowerPoint, served as local webp file
Full-width, placed below the card grid

Performance & Optimization#

Memory Constraints (Raspberry Pi 3B+)#

Total system memory: 788MB
Dockerized Anthias viewer consumes significant resources
Strategies employed:
- Server-side proxy: Eliminates duplicate API calls from browser
- Lazy loading: Defer non-critical rendering
- DOM optimization: Remove unused elements, minimize reflows
- Image optimization: Convert to WebP, use static image over dynamic map
- Cache management: Server-side cache with periodic clearing
- Swap avoidance: Swap degrades SD card — keep memory footprint below physical RAM

Font Standardization#

Default to Arial for cross-platform consistency
Helvetica Neue as preferred fallback
Qt WebEngine (Anthias) renders fonts differently than desktop Chrome

Current Configuration#

Host: PLT-MBTADisplay (192.168.168.42)
Web root: /var/www/MBTADisplay/public
Proxy: /opt/mbta-proxy/server.js (Node/Express, port 3000)
Process manager: pm2 with systemd service (pm2-administrator)
Deployment: Git push → GitHub → manual pull on server
Access URLs: http://transit.intra.plgt.com (internal), https://mbtadash.nbkelley.com (Cloudflare)

Historical Notes#

Conversation dates: 2026-03-12 to 2026-04-12.
Collaborative workflow: Claude AI (creative/prompt engineering) → Claude Code (implementation).
Blue Bikes section was added, then fully removed when GBFS feed deprecated.
Ferry panel configuration evolved significantly — seasonal routes removed seasonally.
Several Claude Code UI hallucinations corrected by user during Bambu Studio discussion.

Sources#

ingested/chats/159-Create MBTA Train Dashboard with API.md
Claude Code conversation: “MBTADashboard - Prompt Maker” (chat 24)

MBTA Dashboard - Kiosk Mode

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Kiosk Mode#

What Was Established#

The MBTA dashboard runs as a 24/7 kiosk display on a Raspberry Pi 3B+ using Anthias (formerly Screenly OSE) in Docker. The display is portrait 1080x1920. The Pi has severe memory constraints (788MB total) requiring aggressive optimization.

Anthias Deployment#

Hardware#

Device: Raspberry Pi 3B+ (788MB RAM)
Display: 1080x1920 portrait screen
Software: Anthias (Docker-based digital signage)

Display Configuration#

Dashboard page set as primary asset
Splash page appears for 1 minute every 11 hours 59 minutes as a refresh cycle
Page refreshes via cron job to prevent memory leaks

Cron Refresh#

# Refresh the kiosk page periodically to clear memory
0 */6 * * * docker restart screenly-anthias-viewer-1

Qt WebEngine Quirks#

Anthias uses Qt WebEngine for rendering, which differs from desktop Chrome:

MBTA Dashboard - Setup

Fri, 01 May 2026 00:00:00 +0000

MBTA Dashboard - Setup#

What Was Established#

Office transit dashboard deployed on a self-hosted Debian VM (PLT-MBTADisplay, 192.168.168.42). Nginx serves static files from /var/www/MBTADisplay/public and proxies /api/ requests to a Node/Express caching proxy on port 3000. API keys are stored server-side and never exposed to the browser. Process managed via pm2 with a systemd service.

Architecture#

Browser (Anthias/Desktop)
    → Nginx (:80) → / → static files (/var/www/MBTADisplay/public)
                   → /api/ → Node/Express proxy (:3000)
                                → MBTA v3 API
                                → OpenWeatherMap API
                                → RSS feeds
                                → Caches responses

Nginx Configuration#

server {
    listen 80;
    server_name transit.intra.plgt.com 192.168.168.42;

    root /var/www/MBTADisplay/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Node/Express Proxy#

Setup#

mkdir -p /opt/mbta-proxy
cd /opt/mbta-proxy
npm init -y
npm install express node-fetch

API Key Management#

API keys stored in /opt/mbta-proxy/.env
Loaded via process.env.MBTA_API_KEY in server.js
pm2 started with --env flag to load .env file
Critical: API key must survive server.js overwrites from GitHub syncs

pm2 Process Manager#

pm2 start server.js --name mbta-proxy
pm2 save
pm2 startup systemd

systemd Service (`/etc/systemd/system/pm2-administrator.service`)#

[Unit]
Description=PM2 process manager
After=network.target

[Service]
Type=forking
User=administrator
ExecStart=/usr/local/bin/pm2 resurrect
ExecReload=/usr/local/bin/pm2 reload all
ExecStop=/usr/local/bin/pm2 kill
Restart=on-failure

[Install]
WantedBy=multi-user.target

GitHub Deployment#

Repository#

Repo: https://github.com/bich-nguyen/MBTADisplay.git
Cloned to /var/www/MBTADisplay
Static files in public/ subdirectory
Server files in /opt/mbta-proxy/ (separate from web root)

Ownership#

sudo chown -R administrator:administrator /var/www/MBTADisplay

Note: www-data ownership breaks git operations from administrator user.

Self-Hosted CMS Options & Landscape

Fri, 01 May 2026 00:00:00 +0000

Self-Hosted CMS Options & Landscape#

What Was Established#

User seeks a self-hosted CMS for an Ubuntu VM, explicitly rejecting WordPress due to business practices.
Preference for tools respected by the web development and self-hosting communities.
Exploration of CMS categories: Monolithic, Flat-file, Static Site Generators (SSG), Headless CMS, and Custom.

Key Decisions#

Rejected WordPress: Cited business practices as a dealbreaker.
Favoring Developer-Respected Alternatives: Leaned towards headless or modern flat-file CMS options.
Top Contenders Identified: Directus (Headless), Strapi (Headless), Kirby (Flat-file), Payload CMS (Headless/TS), Ghost (Blogging).

CMS Landscape & Options#

Monolithic CMS#

WordPress: Dominant (60% market), huge ecosystem, but rejected by user.
Drupal: Flexible, steep learning curve.
Joomla: Balanced ease/power, smaller community.

Flat-file CMS (No Database)#

Grav: Fast, simple, file-based.
Kirby: Beautiful UI, file-based, commercial license (~$129), highly respected by designers/devs.

Static Site Generators (SSG)#

Jekyll: GitHub Pages compatible.
Hugo: Blazing fast, Go-based.
Eleventy: Flexible, JS-based.
Next.js: React-based, hybrid.

Headless CMS (API-Driven)#

Directus: Community favorite. Node.js/Vue.js. Provides REST/GraphQL APIs, beautiful admin UI. Excellent for full frontend control.
Strapi: Most popular headless. Node.js/React. Strong plugin ecosystem.
Payload CMS: Rising star. TypeScript-first, excellent DX.
Ghost: Primarily for blogging/publishing. Markdown-native.
Contentful/Sanity: Enterprise/Developer friendly, but often cloud-hosted (though self-hostable options exist).

Custom / Build-Your-Own#

The Guardian’s “Composer”: Fully custom-built in Scala/Play Framework. Not recommended for small projects.
Server-Side: PHP includes, Python (Django/Flask), Node.js (Express).

Recommended Stack for Ubuntu#

For Maximum Control & Flexibility: Directus or Payload CMS.
For Content-Focused Sites: Kirby or Statamic.
For API-Driven Projects: Strapi.

Quick Start (Directus on Ubuntu):

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
npm create directus-project@latest my-cms
cd my-cms
npm install
npx directus start

Historical Notes#

Conversation date: 2025-11-17.
User explicitly stated a preference against WordPress due to business practices.
Focus remains on self-hosted, developer-respected tools.
Note: Directus and Strapi have evolved significantly since late 2025; verify current self-hosting requirements, licensing, and Docker compatibility for homelab deployment.

Hugo-Specific Configuration#

Project Structure#

myblog/
├── config.toml   -- Main configuration (baseURL, languageCode, title, theme)
├── content/      -- Blog posts in Markdown
├── themes/       -- Installed themes (git submodules)
├── static/       -- Static assets (images, JS, CSS)
└── public/       -- Generated static files (deployed to Nginx)

Key config.toml Settings#

baseURL — Domain URL (e.g., https://blog.nbkelley.com)
theme — Must match theme folder name in themes/
buildDrafts — true during development, false for production
paginate — Posts per page

Creating Posts#

hugo new posts/my-post.md  # Draft in content/posts/
hugo -D                     # Build including drafts
hugo                        # Production build to public/

Deployment Options#

Manual rsync: rsync -avz --delete public/ user@server:/var/www/html/blog
Git webhook: Server-side script that git pull && hugo && cp -r public /var/www/html/blog on push
Cloudflare Pages: Push Hugo source to GitHub, Cloudflare builds and deploys automatically

Comments for Static Sites#

Utterances — GitHub issues-based, no backend
Disqus — Traditional, JS-based
Hyvor Talk — Self-hostable alternative

Sources#

ingested/chats/106-Beginner Guide to Building Websites with Ubuntu.md
ingested/chats/036-Setting Up Self-Hosted Blogs with Nginx.md
DeepSeek conversation: “Self-Hosted Websites on Ubuntu Server” (historical)
DeepSeek conversation: “Setting Up Self-Hosted Blogs with Nginx” (chat 036)

Servarr - Media Automation Stack

Fri, 01 May 2026 00:00:00 +0000

Servarr - Media Automation Stack#

Overview#

Servarr is a full VM at 192.168.1.112 (hostname: servarr) running a Docker Compose media automation stack. All services depend on a NAS mount at /data for media storage. Download clients (qbittorrent, nzbget) and indexer (prowlarr) route through a Gluetun VPN container via network_mode: service:gluetun.

Note: This VM is distinct from Varda (192.168.1.131), which is a separate web server hosting ilmare.nbkelley.com.

VM Specs#

Detail	Value
Hostname	`servarr`
IP	`192.168.1.112`
OS	Ubuntu 24.04.4 LTS (Noble)
Kernel	6.8.0-107-generic
CPU	QEMU Virtual CPU, 4 vCPUs
RAM	7.8 GB
Disk	63 GB root (`/dev/sda2` ext4, 38% used)
Hypervisor	Proxmox (Minas Tirith)

Container Inventory#

Servarr Stack (`/docker/servarr/compose.yaml`)#

Network: servarrnetwork (172.39.0.0/24)

Servarr Docker Compose Reference

Fri, 01 May 2026 00:00:00 +0000

Servarr Docker Compose Reference#

Canonical copy of /docker/servarr/compose.yaml on the servarr VM (192.168.1.112).

compose.yaml#

# Compose file for the *arr stack. Configuration files are stored in the
# directory you launch the compose file on. Change to bind mounts if needed.
# All containers are ran with user and group ids of the main user and
# group to aviod permissions issues of downloaded files, please refer
# the read me file for more information.

#############################################################################
# NOTICE: We recently switched to using a .env file. PLEASE refer to the docs.
# https://github.com/TechHutTV/homelab/tree/main/media#docker-compose-and-env
#############################################################################

networks:
  servarrnetwork:
    name: servarrnetwork
    ipam:
      config:
        - subnet: 172.39.0.0/24

services:
  # airvpn recommended (referral url: https://airvpn.org/?referred_by=673908)
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun # If running on an LXC see readme for more info.
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.2
    ports:
      - ${FIREWALL_VPN_INPUT_PORTS}:${FIREWALL_VPN_INPUT_PORTS} # airvpn forwarded port, pulled from .env
      - 8080:8080 # qbittorrent web interface
      - 6881:6881 # qbittorrent torrent port
      - 6789:6789 # nzbget
      - 9696:9696 # prowlarr
    volumes:
      - ./gluetun:/gluetun
    # Make a '.env' file in the same directory.
    env_file:
      - .env
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 20s
      timeout: 10s
      retries: 5
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    restart: unless-stopped
    labels:
      - deunhealth.restart.on.unhealthy=true
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - WEBUI_PORT=8080 # must match "qbittorrent web interface" port number in gluetun's service above
      - TORRENTING_PORT=${FIREWALL_VPN_INPUT_PORTS} # airvpn forwarded port, pulled from .env
    volumes:
      - ./qbittorrent:/config
      - /data:/data
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    network_mode: service:gluetun
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 60s
      retries: 3
      start_period: 20s
      timeout: 10s

  # See the 'qBittorrent Stalls with VPN Timeout' section for more information.
  deunhealth:
    image: qmcgaw/deunhealth
    container_name: deunhealth
    network_mode: "none"
    environment:
      - LOG_LEVEL=info
      - HEALTH_SERVER_ADDRESS=127.0.0.1:9999
      - TZ=${TZ}
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  nzbget:
    image: lscr.io/linuxserver/nzbget:latest
    container_name: nzbget
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./nzbget:/config
      - /data:/data
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    restart: unless-stopped
    network_mode: service:gluetun

  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./prowlarr:/config
    restart: unless-stopped
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
    network_mode: service:gluetun

  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./sonarr:/config
      - /data:/data
    ports:
      - 8989:8989
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.3

  radarr:
    image: lscr.io/linuxserver/radarr:latest
    container_name: radarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./radarr:/config
      - /data:/data
    ports:
      - 7878:7878
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.4

  lidarr:
    container_name: lidarr
    image: lscr.io/linuxserver/lidarr:latest
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./lidarr:/config
      - /data:/data
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    ports:
      - 8686:8686
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.5

  bazarr:
    image: lscr.io/linuxserver/bazarr:latest
    container_name: bazarr
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./bazarr:/config
      - /data:/data
    ports:
      - 6767:6767
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.6

# Newer additions to this stack feel. Remove the '#' to add the service.

  ytdl-sub:
    image: ghcr.io/jmbannon/ytdl-sub-gui:latest
    container_name: ytdl-sub
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - DOCKER_MODS=linuxserver/mods:universal-cron
    volumes:
      - ./ytdl-sub:/config
      - /data/youtube:/youtube
    networks:
      servarrnetwork:
        ipv4_address: 172.39.0.8
    restart: unless-stopped

#  jellyseerr:
#    container_name: jellyseerr
#    image: fallenbagel/jellyseerr:latest
#    environment:
#      - PUID=${PUID}
#      - PGID=${PGID}
#      - TZ=${TZ}
#    volumes:
#      - ./jellyseerr:/app/config
#    ports:
#      - 5055:5055
#    networks:
#      servarrnetwork:
#        ipv4_address: 172.39.0.9
#    restart: unless-stopped

Network Architecture#

172.39.0.0/24 (servarrnetwork)
├── 172.39.0.2  gluetun (VPN gateway)
│   ├── qbittorrent  (network_mode: service:gluetun)
│   ├── nzbget       (network_mode: service:gluetun)
│   └── prowlarr     (network_mode: service:gluetun)
├── 172.39.0.3  sonarr
├── 172.39.0.4  radarr
├── 172.39.0.5  lidarr
├── 172.39.0.6  bazarr
└── 172.39.0.8  ytdl-sub

Key Patterns#

VPN routing: qbittorrent, nzbget, and prowlarr use network_mode: service:gluetun to route all traffic through the VPN. They are NOT directly on servarrnetwork.
Static IPs: Media managers (sonarr, radarr, lidarr, bazarr) use static IPs on servarrnetwork for predictable inter-container communication.
.env file: Secrets (PUID, PGID, TZ, FIREWALL_VPN_INPUT_PORTS, VPN credentials) are stored in .env in the same directory.
deunhealth: Monitors container health via Docker socket and restarts unhealthy containers with the deunhealth.restart.on.unhealthy=true label.
Config persistence: Each service’s config is stored in a subdirectory of /docker/servarr/ (e.g., ./sonarr, ./radarr).
Media storage: All containers bind-mount /data (SMB share from NAS at 192.168.1.137) for media access.
jellyseerr: Commented out here — deployed in /docker/jellyfin/compose.yaml instead.

Servarr Stack - Gluetun VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Servarr Stack - Gluetun VPN Troubleshooting#

Historical note: This session was conducted on a machine at 192.168.1.30 (hostname possibly “Varda” at the time, directory ~/home/nbkelley/docker/servarr). The current production Servarr stack lives on the servarr VM at 192.168.1.112, directory /docker/servarr/. See Servarr - Media Automation Stack for current configuration. The troubleshooting patterns documented here remain applicable.

What Was Established#

This session documents the deployment and troubleshooting of the Servarr media automation stack (Sonarr, Prowlarr, qBittorrent) behind a Gluetun VPN container. The stack relies on network_mode: service:gluetun to route all container traffic through AirVPN.

Uptime Kuma - Configuration & Integrations

Fri, 01 May 2026 00:00:00 +0000

Uptime Kuma - Configuration & Integrations#

What Was Established#

Aruba Instant On Switch Monitoring: Confirmed that Aruba Instant On switches (specifically 1930 and 1960 series) support SNMP monitoring when configured via their local web interface, despite being primarily cloud-managed.
Microsoft Teams Webhook Integration: Established the correct method for routing Uptime Kuma alerts to Microsoft Teams using Power Automate Workflows, noting the deprecation of legacy webhook.office.com connectors.

Key Decisions#

SNMP over Ping: While basic ping monitoring is viable for switch reachability, SNMP is preferred for detailed port status and traffic metrics on supported Aruba models.
Power Automate for Teams Alerts: Migrated away from deprecated Office 365 Connectors (webhook.office.com) to Power Automate Workflows to ensure long-term compatibility with Uptime Kuma webhooks.

Current Configuration#

Aruba Instant On Switches (1930/1960 Series)#

Network Setup: Assign a static IP address to the switch via the Aruba Instant On cloud portal or local interface.
SNMP Enablement:
- Access the switch’s local web interface.
- Navigate to SNMP settings (typically under “Switching” or “Management”).
- Enable the SNMP agent.
- Configure SNMPv2c (read-only community string) or SNMPv3 (username/password with optional encryption). Restrict access by IP for security.
- Reboot the switch if required for settings to apply.
Uptime Kuma Monitor:
- Add a new monitor of type SNMP.
- Input the switch’s static IP, selected SNMP version, and credentials.
- Customize OIDs if monitoring specific interface traffic or port status beyond system uptime.

Microsoft Teams Webhook Notifications#

Notification Type: Webhook (Generic Webhook).
Post URL: Power Automate Workflow endpoint URL (e.g., https://prod-05.westus.logic.azure.com/...).
Content Type: application/json.
Testing: Use the “Test” button in Uptime Kuma notification settings to verify connectivity. A 400 error typically indicates a malformed payload or deprecated connector URL.

Historical Notes#

Legacy Connector Deprecation: Microsoft retired the old “Office 365 Connectors” on October 1, 2024. Any Uptime Kuma setups using webhook.office.com URLs will fail and require migration to Power Automate.
SNMP Availability: Early guidance incorrectly stated Aruba Instant On switches lack SNMP support. It was later confirmed that local management interfaces on 1930/1960 models fully support SNMPv2c/v3.

Open Questions#

Are there specific OIDs recommended for Aruba Instant On 1930/1960 switches to monitor port-level errors or traffic thresholds?
Has the Uptime Kuma version been verified against known bugs with Power Automate JSON payloads?

UniFi Express VPN & Network Management

PostgreSQL

Sun, 26 Apr 2026 00:00:00 +0000

PostgreSQL#

What Was Established#

PostgreSQL 16 runs as an LXC on Proxmox, serving as the central database for n8n, the monitoring pipeline, and pgvector embeddings for the wiki.

Deployment#

Detail	Value
LXC host	postgresql
Container ID	108
IP	192.168.1.57
Port	5432
Version	16.13 (Debian 16.13-1.pgdg13+1)
OS	Debian 13 (unprivileged LXC)
Disk	4 GB (App-Storage ZFS pool)
RAM	1024 MiB
CPU	1 core
Installed via	tteck Proxmox helper scripts
Web UI	Adminer — not yet installed
SSH user	iluvatar (sudo, PermitRootLogin no)

Databases and Users#

Database	User	Purpose
homelab	homelab	n8n workflows, monitoring pipeline, pgvector wiki embeddings

Setup commands (run as postgres user)#

CREATE DATABASE homelab;
CREATE USER homelab WITH PASSWORD '<password>';
GRANT ALL PRIVILEGES ON DATABASE homelab TO homelab;
GRANT ALL ON SCHEMA public TO homelab;  -- required for n8n
\q

The GRANT ALL ON SCHEMA public step is required — without it n8n fails to start with a permissions error even though the database and user exist.

n8n

Tue, 21 Apr 2026 00:00:00 +0000

n8n#

What Was Established#

n8n is the automation and orchestration hub for the homelab. It runs as an LXC on Proxmox, connected to PostgreSQL for persistent workflow state and execution history. Community edition is sufficient for current use.

Deployment#

Detail	Value
LXC host	n8n
IP	192.168.1.169
Port	5678
URL	http://192.168.1.169:5678
Version	2.15.1 (Self Hosted)
Installed via	tteck Proxmox helper scripts
OS	Debian 13 (unprivileged LXC)
Config file	/opt/n8n.env

Configuration (/opt/n8n.env)#

N8N_SECURE_COOKIE=false
N8N_PORT=5678
N8N_PROTOCOL=http
N8N_HOST=192.168.1.169
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=192.168.1.57
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=homelab
DB_POSTGRESDB_USER=homelab
DB_POSTGRESDB_PASSWORD=<password>

After editing: systemctl restart n8n

Ollama Configuration

Mon, 13 Apr 2026 00:00:00 +0000

Ollama Configuration#

What Was Established#

Ollama is used as the primary model backend across the fleet. The configuration focuses on making the API accessible to other nodes (like the T480 orchestrator) and running models like Gemma 4.

Key Decisions#

To allow remote access from other machines in the homelab (e.g., from a Docker container or another PC), the Ollama service must be configured to listen on all network interfaces, not just localhost.

Open WebUI Deployment

Mon, 13 Apr 2026 00:00:00 +0000

Open WebUI Deployment#

What Was Established#

Open WebUI is deployed via Docker to provide a ChatGPT-like interface for interacting with local Ollama instances. It is configured to connect to the host’s Ollama API.

Key Decisions#

Because the WebUI runs inside a Docker container, it cannot reach localhost:11434 of the host machine directly. The OLLMA_BASE_URL must point to the host’s actual LAN IP or use the host.docker.internal gateway.

Current Configuration#

Docker Deployment#

docker run -d \
  --name open-webui \
  --restart always \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  --add-host=host.docker.internal:host-gateway \
  -e OLLAMA_BASE_URL=http://<YOUR_HOST_IP>:11434 \
  ghcr.io/open-webui/open-webui:main

Note: Replace <YOUR_HOST_IP> with the actual IP of the machine (e.g., 192.168.172.168) to ensure the container can route to the Ollama service.

Web Server Stack (Nginx + Apache)

Fri, 28 Mar 2025 00:00:00 +0000

Web Server Stack (Nginx + Apache)#

What Was Established#

In this setup, Nginx is utilized as a high-performance reverse proxy to handle incoming traffic and static content, while Apache serves as the backend for dynamic content (e.g., PHP/WordPress) due to its flexible .htaccess support.

Key Decisions#

Architecture: Nginx acts as the entry point (Port 80/443) and proxies requests to Apache running on a non-standard port (e.g., 8080).
Rationale: Leverages Nginx’s superior concurrency and static content handling with Apache’s ease of use for per-directory configuration.

Current Configuration#

Apache Backend Configuration#

Modify /etc/apache2/ports.conf to listen on a different port to avoid conflict with Nginx:

Nginx vs Apache for Static Hosting

Wed, 26 Mar 2025 00:00:00 +0000

Nginx vs Apache for Static Hosting#

What Was Established#

A comparison of Nginx and Apache for the purpose of hosting static HTML/CSS/JS files within a Proxmox LXC or VM.

Key Decisions#

Choose Nginx if: You prioritize performance, low memory footprint, and plan to use it as a reverse proxy for modern stacks (Node.js, Python).
Choose Apache if: You require .htaccess support for per-directory configuration or are working with legacy PHP/LAMP stacks.

Current Configuration#

Nginx Basic Static Config#

server {
    listen 80;
    root /var/www/html;
    index index.html;
}

Apache Basic Static Config#

<VirtualHost *:80>
    DocumentRoot /var/www/html
    DirectoryIndex index.html
</VirtualHost>

Deployment Commands (LXC)#

To create a standard Ubuntu 22.04 LXC for web hosting:

Web Server Deployment Pattern (Beginner)

Sun, 23 Mar 2025 00:00:00 +0000

Web Server Deployment Pattern (Beginner)#

What Was Established#

For a beginner-friendly, lightweight, and scalable homelab setup, a stack consisting of Ubuntu Server LTS and Nginx is the recommended standard. This provides a balance of ease of use, extensive documentation, and low resource overhead.

Key Decisions#

Operating System: Ubuntu Server LTS (chosen for stability, community support, and ease of management).
Web Server: Nginx (chosen over Apache for being lightweight, faster for static content, and better suited for future use as a reverse proxy).
Resource Allocation (Small Site): 1-2 CPU cores, 1-2 GB RAM, 10-2/GB Disk.

Current Configuration#

Nginx Site Configuration#

Default root directory: /var/www/html

Services on homelab

BlueBikes API Feeds Guide

BlueBikes API Feeds Guide#

What Was Established#

Key Decisions#

Current Configuration#

Core GBFS Endpoints#

Data Structure Examples#

Gluetun VPN Service

Gluetun VPN Service#

What Was Established#

Deployment Context#

Hinterflix Help Site - Cloudflare Deployment

Hinterflix Help Site - Cloudflare Deployment#

What Was Established#

Key Decisions#

Configuration Steps#

Homelab Dashboard

Homelab Dashboard#

What Was Established#

Deployment#

File Structure#

compose.yaml Entry#

Hugo Deployment to Cloudflare Pages - Troubleshooting

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Obsidian Integration for Hugo Date Format#

Jellyfin Docker Compose Reference

Jellyfin Docker Compose Reference#

compose.yaml#

Key Details#

Directory Layout#

Related Pages#

Jellyfin Help Link Integration

Jellyfin Help Link Integration#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Jellyfin LXC GPU Passthrough & Hardware Acceleration

Jellyfin LXC GPU Passthrough & Hardware Acceleration#

What Was Established#

Key Decisions#

Current Configuration#

Host GPU Details#

LXC Container GPU Devices#

Jellyfin Configuration#

Validation Commands#

Historical Notes#

Open Questions#

Related Pages#

MBTA Dashboard - Frontend Implementation

MBTA Dashboard - Frontend Implementation#

What Was Established#

Design Evolution#

Layout (1080x1920 Portrait)#

Key Features#

CSS Ticker/Marquee#

Station-Based Grouping#

Server-Side Proxy Architecture#

News Ticker#

Static Map#

Performance & Optimization#

Memory Constraints (Raspberry Pi 3B+)#

Font Standardization#

Current Configuration#

Historical Notes#

Related Pages#

Sources#

MBTA Dashboard - Kiosk Mode

MBTA Dashboard - Kiosk Mode#

What Was Established#

Anthias Deployment#

Hardware#

Display Configuration#

systemd Service (`/etc/systemd/system/pm2-administrator.service`)#

Servarr Stack (`/docker/servarr/compose.yaml`)#