Ollama runs as a self-contained Go binary/container, which drops cleanly into an existing Proxmox LXC on the homelab (CT 103/104 have spare capacity) alongside the Cloudflare tunnel already exposing homelab services. Its OpenAI-compatible REST API means bud (FastAPI) and life-automation (Vite/companion API) integrate by changing a base_url and using an empty API key, with zero new client libraries or protocol work.
The operator profile explicitly values self-hosted, budget-conscious, unattended systems, and bud already has a stated privacy gap: personal email content going to cloud AI APIs for classification. A local Ollama deployment directly closes that gap and matches the solo-operator, free-tier-first posture.
Implementation Options
01Ollama CT for bud email classification
bud4-8 hourslow risk
Stand up a new Proxmox LXC (or reuse CT 103/104 headroom) running Ollama with a Qwen3 or Llama 3 model pulled locally. Point bud's existing FastAPI classification call at the local Ollama base_url instead of the current cloud API, keeping the OpenAI SDK call signature identical. Add basic systemd/CT-level restart-on-failure so it runs unattended.
+Removes the only concrete privacy exposure identified in bud today (financial/purchase emails leaving the homelab)
+One-line base_url change in bud's existing OpenAI SDK integration, no new abstraction needed
-Classification quality/latency depends on homelab hardware (CPU-only inference may be slow or lower quality than the cloud model bud uses today)
-Adds one more service to monitor/update on the homelab; model files consume real disk space (multi-GB per model)
02Shared Ollama service across bud and life-automation
bud6-10 hoursmedium risk
Same CT deployment as above, but scope it as shared infrastructure from day one: both bud's classification calls and life-automation's companion API route through the same Ollama instance, each via its own base_url swap. Document model choice and VRAM/CPU budget once for both consumers.
+Avoids standing up two separate local-inference services later
+life-automation gets offline-capable AI responses as a side effect of solving bud's privacy problem
-Couples two projects' AI availability to one shared service - an outage or model swap affects both
-life-automation's needs (home automation queries) may want a different model/tuning than bud's email classification, forcing a compromise or multi-model juggling
03Minimal spike: single-model smoke test before committing
bud1-2 hourslow risk
Run Ollama in an existing CT with one small model (e.g. Qwen3 8B) and manually replay a handful of real bud email samples through it to compare classification accuracy against the current cloud API before touching production code.
+De-risks the quality question (does a local model classify email as well as the cloud API) before any code changes
+Very cheap - no new infra changes to bud itself
-Delays the actual privacy fix by another cycle
-Manual comparison is not rigorous - doesn't establish a real accuracy baseline
Eliminates bud's only identified privacy exposure by keeping personal email content (financial notifications, purchase confirmations, subscription emails) on the homelab instead of sending it to a cloud AI API for classification, with a one-line integration change.
This is the first trending item this cycle that maps to a named, concrete gap in an active project rather than general-purpose learning value - it converts a privacy concern the operator already flagged in bud into a solvable infrastructure task using hardware already owned.
03 · What Implementation Looks Like A new or reused Proxmox CT runs `ollama serve` with one pulled model. In bud's codebase, the OpenAI client instantiation changes its base_url (and drops the real API key) to point at the CT's address over the Cloudflare tunnel or internal network. No new classification logic is needed - the same prompt/response shape is reused. The operator sees no UI change; the observable difference is that email content classification traffic stops leaving the homelab, verifiable by checking bud's outbound API call logs.