From Silicon to SSDs: Building an AI Anomaly Detector and a Self-Hosted Media Server

Bhavya Sharma — Fri, 21 Aug 2026 08:07:27 +0000

Over the past few months, I've been heads-down on two very different but equally satisfying builds: an AI-powered anomaly detection agent for business KPIs, and a self-hosted media and storage server running on a Raspberry Pi. One lives entirely in the cloud of data and statistics; the other lives on a physical board sitting on my desk. Together, they've taught me a lot about what it actually takes to go from "cool idea" to "something that works reliably, end to end."

Here's the story of both.

Project 1: The AI Anomaly Agent — Turning a Spreadsheet into a Monitoring System
The problem

Most teams look at their KPI dashboards, notice something weird happened, and then someone spends an afternoon digging through spreadsheets to figure out why. That reactive cycle — human happens to notice, human investigates, human explains — doesn't scale, and it's easy for a real problem to sit unnoticed for days.

I wanted to build something that closes that loop automatically: an agent that watches KPI data on its own, flags when something is statistically out of the ordinary, explains why in plain English, and pushes that explanation straight to the people who need it — without anyone needing to open the spreadsheet first.

What I built

The AI Anomaly Agent is a Python pipeline that takes a business's KPI data (traffic, conversion rate, revenue, etc.) and turns it into an automated monitoring and alerting system. It's built as five distinct stages, each with a single clear job:

generate_data.py — produces a synthetic KPI dataset with realistic, deliberately injected anomalies, so the whole pipeline can be tested against known-good and known-bad data.
anomaly_agent.py — the core logic. It loads the KPI data, computes a rolling 14-day baseline for each metric, and flags any day where a metric deviates by a z-score of 2.0 or more from that baseline. Critically, it also cross-references anomalies that happen on the same day across different metrics, which is where the interesting insights live.
make_charts.py — renders trend charts for each metric with the flagged anomalies visually marked, so a human can see at a glance where things went off script.
report_pdf.py — assembles the findings and charts into a clean, polished PDF report — something you could actually hand to a stakeholder.
email_alert.py — sends that report as an automated email alert via SMTP, so the whole thing runs without anyone babysitting it.

The tech stack is intentionally lean: Python, pandas and numpy for the statistical heavy lifting, matplotlib for the charts, reportlab for PDF generation, and smtplib for delivering the alert. Nothing exotic — just the right tool for each stage of the pipeline.

Why the statistics matter

The core detection logic isn't just "is this number bigger than yesterday." A rolling 14-day baseline means the agent adapts to a metric's normal week-to-week rhythm instead of comparing against a single arbitrary day. And using a z-score threshold (≥ 2.0) means a flag actually means something statistically — it's not just noise from ordinary day-to-day variance.

The part I'm most proud of, though, is the cross-referencing step. A single anomalous metric can be a fluke. But when two metrics move together on the same day, that's a pattern worth explaining — and that's exactly what the agent is built to catch.

A real example from the sample data

Running the agent against the sample dataset, it caught a day where:

Traffic jumped to 18,702 — a +102.5% spike over the 14-day average
Conversion rate dropped to 1.84 — a -44.8% decline over the same window

Because these two anomalies landed on the same day, the agent's analyst note flagged them together and offered a plain-English interpretation: traffic and conversion rate moving in opposite directions on the same day usually points to a change in traffic quality — like a new campaign or referral source bringing in a wave of less-qualified visitors — rather than something broken on the site itself.

That's the real value of the project: it's not just detecting a spike, it's giving a starting hypothesis for why, which saves an analyst the first hour of investigation.

What this project taught me

Building this end-to-end — not just the detection math, but the charts, the PDF generation, and the automated email delivery — showed me how much of a "smart" system is actually just careful engineering around a simple statistical core. The anomaly detection itself is a few lines of pandas. Making it into something a team would actually use — a report that looks good, an alert that shows up in your inbox — is most of the work.

Project 2: A Self-Hosted Media & Storage Server on a Raspberry Pi
The problem

I wanted a personal media server — something to store and stream my own media library — without handing that data to a third-party cloud service. That meant building the whole stack myself: hardware, storage, networking, and the media server software, all self-hosted on a Raspberry Pi.

What I built

The setup is a small but complete self-hosted infrastructure stack:

A dedicated SSD for storage, partitioned and formatted, with a persistent, UUID-based auto-mount configured in /etc/fstab so it's reliably available after every reboot.
Jellyfin, installed and configured as a systemd service, pointed at the SSD's media library (movies, TV, music).
Nginx running as a reverse proxy in front of Jellyfin — including WebSocket support and streaming-friendly timeout settings, both of which matter a lot for smooth playback.
A static local IP plus router port forwarding, so the server is reachable from other devices on the network.
Ongoing maintenance: watching disk usage, keeping the OS and packages updated, and making sure services recover cleanly after a reboot.

The request flow is simple but deliberate: a client hits Nginx on port 80, which proxies through to Jellyfin on port 8096, which in turn streams media straight from the dedicated SSD mounted at /mnt/storage.

The tech stack: Raspberry Pi OS (64-bit, Lite, headless — no desktop environment, SSH only), Nginx, Jellyfin, systemd, ext4 with fstab-based mounting, and a fair amount of general Linux networking and port-forwarding configuration.

A real bug, and how I found it

Not everything worked on the first try — which is honestly the more interesting part of any build like this. At one point, Jellyfin's library scan found the media folders but reported zero files inside them. No errors, no crash — it just came up empty.

The diagnosis took some digging: the SSD had been mounted as root-owned, which meant the Jellyfin service — running under its own dedicated user — had no read permission on the media directories at all. From Jellyfin's point of view, the folders were simply invisible.

The fix was straightforward once I found the cause: re-owning the storage path to the Jellyfin service user with chown -R jellyfin:jellyfin /mnt/storage, then re-running the scan. Files showed up immediately.

That one bug ended up being a good lesson in how much of self-hosting is really about permissions and service boundaries, not the "big" software you install. There were four other real issues along the way too — fstab device-naming quirks, Nginx 502 errors, streaming buffering, and getting remote access working — each with its own small diagnosis-and-fix story, all documented in the project's troubleshooting log.

What this project taught me

Building software is one skill. Keeping a physical machine alive, correctly permissioned, network-reachable, and running the same service reliably after every reboot is a different one — closer to systems administration than development. This project forced me to get comfortable with that side of things: reading logs, understanding why a service can't see a file even though the file is clearly there, and building things to survive a reboot rather than just survive the first run.

Tying it together

These two projects sit at opposite ends of a spectrum — one is about extracting insight from data at a high level of abstraction, the other is about wrangling physical storage, permissions, and network configuration on a single-board computer. But the underlying lesson from both was the same: the "smart" or "impressive" part of a project (the anomaly detection, the streaming server) is usually a small fraction of the actual work. The rest is the unglamorous but essential engineering — clean pipelines, correct permissions, services that recover after a crash, reports that are actually readable — that makes something go from "it worked once on my machine" to "it's a system I trust."

Repos, full source, and complete troubleshooting notes:

AI Anomaly Agent: https://github.com/BhavyaSharma69/ai-anomaly-agent

Self-Hosted Media Server: https://github.com/BhavyaSharma69/self-hosted-media-server

DEV Community: Bhavya Sharma

From Silicon to SSDs: Building an AI Anomaly Detector and a Self-Hosted Media Server