<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Anthony Pierre</title><link>https://anthonyapierre.com/posts/</link><description>Recent content in Posts on Anthony Pierre</description><generator>Hugo -- gohugo.io</generator><language>en-gb</language><lastBuildDate>Mon, 25 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://anthonyapierre.com/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>Self-Healing Homelab MCP with AWS Route 53, CloudWatch and Lambda</title><link>https://anthonyapierre.com/posts/self-healing-mcp-post/</link><pubDate>Mon, 25 May 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/self-healing-mcp-post/</guid><description>&lt;p&gt;There is a particular kind of frustration that comes from a tool dropping mid-session with no warning. My MCP server — the bridge between Claude and my homelab infrastructure — had developed a habit of going quiet at exactly the wrong moment. The fix I built turned out to be a solid piece of AWS architecture. The plot twist was that the problem itself was something else entirely.&lt;/p&gt;
&lt;h2 id="the-problem"&gt;The Problem&lt;/h2&gt;
&lt;p&gt;My MCP server runs on CT104 (ai-lab) inside a Proxmox LXC container on my home network, exposed via a Cloudflare tunnel. Claude connects to it over SSE (Server-Sent Events), which keeps a long-lived HTTP connection open so tool results can stream back in real time. When that connection dropped, the session was dead — no tools, no homelab access, nothing. The only recovery was a manual SSH in to restart the process.&lt;/p&gt;</description></item><item><title>Building a Self-Hosted Voice-to-Text Pipeline with Whisper and AWS Bedrock</title><link>https://anthonyapierre.com/posts/whisper-web-post/</link><pubDate>Sun, 26 Apr 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/whisper-web-post/</guid><description>&lt;p&gt;There is a small but persistent friction point in my workflow: I think faster than I type. When I am working through a problem or drafting something, the gap between thought and text slows everything down. I wanted to be able to speak, get clean written text back, and carry on without sending audio to a third-party API or paying per minute.&lt;/p&gt;
&lt;p&gt;This is how I built it.&lt;/p&gt;
&lt;h2 id="the-stack"&gt;The Stack&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;faster-whisper&lt;/strong&gt; - a CTranslate2-based reimplementation of OpenAI&amp;rsquo;s Whisper. No PyTorch dependency, significantly smaller image footprint (~500MB vs ~2GB), and genuinely faster on CPU.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;FastAPI&lt;/strong&gt; - the backend, handling audio uploads and browser recording.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;AWS Bedrock Nova Micro&lt;/strong&gt; - an optional cleanup pass that fixes punctuation, capitalisation, and removes filler words from the raw transcript.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Docker on Proxmox LXC&lt;/strong&gt; - containerised on my existing Docker host alongside Pierre and Sablier.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Cloudflare tunnel&lt;/strong&gt; - HTTPS without a reverse proxy, accessible from desktop and mobile.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="why-not-the-openai-whisper-api"&gt;Why Not the OpenAI Whisper API?&lt;/h2&gt;
&lt;p&gt;The hosted API is fine for occasional use but charges per minute of audio. More importantly, audio stays local with a self-hosted solution. Everything runs on my own infrastructure - the only external call is the optional Bedrock cleanup step, which sends only the raw text transcript, not the audio itself.&lt;/p&gt;</description></item><item><title>How GitHub Became the Backbone of My Infrastructure</title><link>https://anthonyapierre.com/posts/github-workflow-post/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/github-workflow-post/</guid><description>&lt;p&gt;I started this week thinking of GitHub as a place to store code. I ended it realising it is infrastructure.&lt;/p&gt;
&lt;p&gt;Over 48 hours of building a self-hosted scraping engine, deploying a portfolio site to AWS, and recovering from a broken WireGuard tunnel, GitHub quietly became the thread that held everything together. Here is what I did not expect.&lt;/p&gt;
&lt;h2 id="emergency-deployment"&gt;Emergency Deployment&lt;/h2&gt;
&lt;p&gt;My VPS went offline mid-project. No warning, no graceful shutdown, just gone. At that point, my portfolio site at anthonyapierre.com was running as a Hugo container on that same server.&lt;/p&gt;</description></item><item><title>From Cloudflare Pages to AWS: Hosting My Portfolio on S3 + CloudFront</title><link>https://anthonyapierre.com/posts/from-cloudflare-pages-to-aws/</link><pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/from-cloudflare-pages-to-aws/</guid><description>How I migrated my Hugo portfolio site from Cloudflare Pages to a production-grade AWS architecture using S3, CloudFront, ACM, IAM, and GitHub Actions — and what I learned along the way.</description></item><item><title>When My VPS Went Down: Migrating to Cloudflare Workers in a Panic</title><link>https://anthonyapierre.com/posts/vps-outage-cloudflare-migration/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/vps-outage-cloudflare-migration/</guid><description>&lt;p&gt;I&amp;rsquo;ll be honest, I didn&amp;rsquo;t plan to migrate my site to Cloudflare Workers today. My hand was forced.&lt;/p&gt;
&lt;p&gt;I woke up to alerts telling me my VPS was down. My portfolio site, &lt;code&gt;anthonyapierre.com&lt;/code&gt;, was completely unreachable. I&amp;rsquo;d been meaning to set up a proper failover for a while, but like most things that live on the &amp;ldquo;I&amp;rsquo;ll sort that eventually&amp;rdquo; list, it hadn&amp;rsquo;t happened yet.&lt;/p&gt;
&lt;p&gt;This is the story of how, on the very first day my site went fully live, an unexpected outage turned into something genuinely useful.&lt;/p&gt;</description></item><item><title>Rebuilding the OSINT Lab: FastAPI, WebSockets, and 11 Tools Confirmed</title><link>https://anthonyapierre.com/posts/osint-lab-update/</link><pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/osint-lab-update/</guid><description>&lt;p&gt;When I first built the OSINT lab, the goal was simple: a dedicated, network-isolated environment for open source intelligence work running inside a Proxmox LXC container. Maltego and SpiderFoot were up and running, the container was air-gapped from the rest of the homelab, and it did the job.&lt;/p&gt;
&lt;p&gt;The problem was the dashboard. The original implementation used Node.js with Server-Sent Events to stream tool output to the browser, and it was fragile. SSE connections would drop unpredictably, tool output would get cut off mid-run, and the whole thing had a tendency to fall over under any kind of sustained load. It worked just well enough to be annoying rather than broken enough to force a fix — until I decided to fix it properly.&lt;/p&gt;</description></item><item><title>Building the HomelabDashboard Android App from Scratch</title><link>https://anthonyapierre.com/posts/android-app-post/</link><pubDate>Tue, 24 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/android-app-post/</guid><description>&lt;p&gt;There is a certain point in homelab development where browser bookmarks and SSH sessions stop being a sensible way to manage things. When you are running 25+ LXC containers across a Proxmox host, a Romanian VPS, and a Docker stack, you want a single place to see everything — and you want it in your pocket.&lt;/p&gt;
&lt;p&gt;That is where HomelabDashboard came from. Not a third-party monitoring tool, not a pre-built solution — a native Android app built from scratch in Kotlin with Jetpack Compose, connected to a real Flask API running on my own infrastructure.&lt;/p&gt;</description></item><item><title>Running an AI Monitoring Agent on AWS Bedrock for £0.02 a Month</title><link>https://anthonyapierre.com/posts/aws-bedrock-agent-post/</link><pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/aws-bedrock-agent-post/</guid><description>&lt;p&gt;When I started building an AI monitoring agent for the homelab, the obvious concern was cost. AWS Bedrock is powerful, but running AI analysis on a continuous basis against 25+ containers sounded like a recipe for a surprising monthly bill.&lt;/p&gt;
&lt;p&gt;The solution was tiered model routing — and it keeps the entire operation running for approximately £0.02 per month.&lt;/p&gt;
&lt;h2 id="the-tiering-logic"&gt;The Tiering Logic&lt;/h2&gt;
&lt;p&gt;AWS Bedrock&amp;rsquo;s Nova model family has three tiers with very different price points. Nova Micro is the cheapest available at around $0.035 per million input tokens. Nova Lite sits in the middle. Nova Pro is the most capable and the most expensive.&lt;/p&gt;</description></item><item><title>A Year of Proxmox: Storage Migration, Kernel Updates, and Keeping 25 Containers Running</title><link>https://anthonyapierre.com/posts/proxmox-infrastructure-post/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/proxmox-infrastructure-post/</guid><description>&lt;p&gt;There is a gap between setting up a homelab and running one. The setup is documented everywhere. The running — the day-to-day operational decisions, the failures, the fixes, the things you wish someone had told you — less so. This is some of that.&lt;/p&gt;
&lt;h2 id="the-storage-migration"&gt;The Storage Migration&lt;/h2&gt;
&lt;p&gt;The Proxmox host started with the default local-lvm setup. It works fine when you are running a handful of containers, but local-lvm does not support snapshots for LXC containers, which matters when you want an AI agent taking safety snapshots before executing remediation actions.&lt;/p&gt;</description></item><item><title>Homelab AI Monitoring Agent</title><link>https://anthonyapierre.com/posts/public-homelab-ai-agent/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/public-homelab-ai-agent/</guid><description>&lt;p&gt;An AI-powered infrastructure monitoring agent that watches over 25+ self-hosted LXC containers, analyses metrics using AWS Bedrock, and delivers intelligent alerts via Telegram — with inline action buttons for semi-autonomous remediation.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="what-it-does"&gt;What It Does&lt;/h2&gt;
&lt;p&gt;The agent runs on a dedicated Proxmox LXC container and executes a pipeline every 15 minutes: collect metrics from the Proxmox API → pre-summarise to ~500 tokens → store in SQLite → send to AWS Bedrock for AI analysis → deliver actionable alerts via Telegram.&lt;/p&gt;</description></item><item><title>OSINT Research Environment</title><link>https://anthonyapierre.com/posts/public-osint/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/public-osint/</guid><description>&lt;p&gt;A self-contained, network-isolated research environment for open-source intelligence work. Built on a dedicated Proxmox LXC container with a non-root research user, curated toolset, and deliberate separation from production services.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="why-build-this"&gt;Why Build This&lt;/h2&gt;
&lt;p&gt;OSINT work involves visiting unknown sites, running aggressive network scanners, and handling data from potentially hostile sources. Running this on a shared system risks contaminating production services if something goes wrong.&lt;/p&gt;
&lt;p&gt;A dedicated isolated container solves this cleanly — if something goes sideways during an investigation, it stays contained. The container is intentionally stopped when not in use, reducing the attack surface further.&lt;/p&gt;</description></item><item><title>Reticulum Mesh Network</title><link>https://anthonyapierre.com/posts/public-reticulum/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/public-reticulum/</guid><description>&lt;p&gt;A resilient backup communication path to home infrastructure that operates independently of DNS, Cloudflare, and standard IP routing. Built after a Cloudflare global outage in November 2025 exposed a single point of failure in all remote access methods.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-problem"&gt;The Problem&lt;/h2&gt;
&lt;p&gt;Every remote access method I had — Proxmox management, service dashboards, SSH — routed through Cloudflare DNS. When Cloudflare went down globally, everything stopped resolving simultaneously. No fallback existed.&lt;/p&gt;
&lt;p&gt;The solution needed to be completely independent: no DNS lookups, no fixed IP addresses, no dependency on any third-party infrastructure.&lt;/p&gt;</description></item><item><title>Building an AI-Powered Homelab Monitor with AWS Bedrock</title><link>https://anthonyapierre.com/posts/building-homelab-ai-monitor/</link><pubDate>Sat, 28 Feb 2026 00:00:00 +0000</pubDate><guid>https://anthonyapierre.com/posts/building-homelab-ai-monitor/</guid><description>&lt;h2 id="the-problem"&gt;The Problem&lt;/h2&gt;
&lt;p&gt;Running a homelab with 25+ LXC containers means a lot can go wrong quietly. Disks fill up. Services crash overnight. Memory leaks build over days. By the time you notice, something important has been broken for hours.&lt;/p&gt;
&lt;p&gt;The standard answer is Grafana dashboards and Prometheus alerts — and I have those. But they tell you &lt;em&gt;what&lt;/em&gt; the numbers are, not &lt;em&gt;what they mean&lt;/em&gt;. A dashboard at 2am showing a container at 78% disk usage doesn&amp;rsquo;t tell you whether that&amp;rsquo;s normal for that container, whether it&amp;rsquo;s trending toward a problem, or whether you should actually wake up about it.&lt;/p&gt;</description></item></channel></rss>