Robert D. White

Introduction Three years ago I wrote about running a Matrix server with Docker Compose, where the interesting part was the federation-over-Cloudflare-tunnel arrangement and the observation that a Matrix homeserver makes a serviceable notification hub. That deployment has since moved into my RKE2 cluster, and the notification role has grown from a convenience into the primary reason the homeserver exists. Nearly every machine-generated message in my infrastructure now arrives in an end-to-end encrypted Matrix room. Feed digests from FreshRSS, Prometheus alerts, GitOps deployment results, Falco runtime detections, Authentik authentication events, media-library activity, uptime state changes, weather alerts, and notifications from the UniFi and Synology appliances all terminate in rooms whose contents the homeserver itself cannot read. Two AI agents live in those same encrypted rooms and answer questions there. ...

Introduction I consume far more feeds than I can reasonably examine with sustained attention, which means that the substantive difficulty lies not in volume alone but in the profoundly uneven distribution of relevance within that volume. On an active day, a hundred articles may arrive in rapid succession; perhaps four contain a development warranting action, while the remaining ninety-six obscure those few consequential pieces beneath a familiar and relentless accumulation of headlines, summaries, reposts, and derivative commentary. ...

A Reusable Access Layer I recently wrote about pages, a static-site host with an MCP upload tool. That server was the first in a fleet that has since grown to ten. I now run ten MCP servers in the cluster. Each presents one self-hosted application: congress-mcp, freshrss-mcp, googlenews-mcp, gsc-mcp, jetlog-mcp, media-mcp, monica-mcp, nodebyte-mcp, pages, and the Kubernetes server. They share a core manifest pattern, a bearer-token boundary, a hostname convention, and a deployment path. Adding the tenth took approximately forty minutes; most of that time went into writing tool descriptions. ...

Introduction Nine namespaces in my cluster depend upon a local language model. The SDR research stack tags transcriptions, the politics dashboard summarizes feeds, the congressional-trade tracker prepares daily summaries, and several agents submit work to the service continuously. Despite their differing purposes and operational rhythms, each consumer was designed to address one stable hostname on port 11434. That hostname fronts two active Ollama deployments: an RTX 5090 in a desktop tower that is intentionally powered down at intervals, and an NVIDIA GB10 Spark board whose unified-memory architecture causes GPU-backed allocations to count against the pod’s memory limit. The repository contains a CPU-only deployment manifest, but the active Kustomization excludes it under ordinary circumstances. The Spark deployment is therefore the operational fallback. ...

Introduction Consider an agent running in a cluster or on a server that needs to read the news. The customary response is to provide an HTTP client and permit it to fetch URLs, perhaps through an egress proxy intended to impose a measure of network hygiene. The agent in question is an in-cluster assistant with material access to its environment. It can receive a projected ServiceAccount token, whose effective authority derives from Kubernetes RBAC; it can control home automation; and it can reach several important internal services. Giving a system with that degree of reach a general-purpose fetch(url) tool creates a direct security problem: every page it reads becomes a potential source of adversarial instruction, and every host on the internet becomes a potential destination for whatever information the agent can assemble. ...