Building a Netflix-Style Media Server with Claude: Just 15MB

From Six Apps to One: The Pain Points of Media Servers

If you run a home media server, chances are you've already installed Sonarr, Radarr, Lidarr, Bazarr, Prowlarr, and Seerr. Each of these six applications ships with its own mini operating system to keep it running — even when idle, Sonarr and Radarr each consume roughly 110-140 MB of memory. One developer grew frustrated with this and used Claude to help write code for an all-in-one app called Holyarrs. Its download size is only about 15 MB, and with a library of 12,800 movies and shows, its idle memory usage is around 70 MB.

According to the original Reddit post, the app's goal is clear: handle all media management functions in a single app, with an experience that rivals Netflix. Compared to traditional setups that consume hundreds of MB of memory just sitting idle, Holyarrs achieves an order-of-magnitude reduction in resource efficiency.

Sonarr, Radarr, Lidarr, Bazarr, Prowlarr, and Seerr (formerly Overseerr) are commonly used open-source tools in the *arr ecosystem, each responsible for a category of media management tasks: Sonarr manages TV series, Radarr manages movies, Lidarr manages music, Bazarr handles subtitles, Prowlarr acts as an indexer aggregator, and Seerr handles user requests and discovery. They are typically deployed as separate Docker containers or services, each with a built-in web server and background task scheduler, so even when idle they each consume considerable memory. Understanding this division of labor helps clarify that what Holyarrs needs to consolidate isn't a single function, but six interdependent workflows.

The Hidden Pitfall of Claude Writing Code: Uncontrolled Size

The developer discovered a key issue while using Claude: Claude doesn't care at all about code size. Left unchecked, the app will gradually become bloated. This isn't a problem unique to Claude — it's a common weakness of AI coding tools, which prioritize feature implementation and rarely consider resource constraints proactively.

To counter this trend, the developer set hard limits before writing any code: an idle memory ceiling, startup speed, and app size. Every feature had to fit within these constraints before it could ship. This "define constraints first, then write code" approach is the core methodology for building lightweight applications with AI.

Three Key Decisions: Testing, De-systemizing, Adding Safeguards

Replace Guesswork with Real Measurements

The developer built the same homepage (containing 10,000 posters) in two different ways and measured performance for each. One approach was about 3x lighter and took only half the time to render the screen, so it was adopted. This measurement-based approach to decision-making avoids the uncertainty of optimizing by gut feeling.

In UI performance optimization, "rendering a list with tens of thousands of posters on one screen" is a classic heavy-load scenario. The two common implementation paths are: creating all DOM nodes at once, or using virtual scrolling/windowing techniques to render only the elements within the visible area. The latter significantly reduces the number of nodes and layout calculations, thereby lowering memory usage and render time. By building the same homepage two ways and measuring each, the developer essentially turned "which architecture is lighter" from a judgment call into a reproducible benchmark — consistent with the "measure first, then optimize" principle emphasized in front-end performance engineering.

Remove the Built-in Operating System

The biggest reason Holyarrs is so small is that it doesn't bundle an operating system. It's just a program with the web app built in directly, nothing else. This not only dramatically cuts down size but also reduces the attack surface — there are no extraneous components to exploit.

Many self-hosted applications use an "app + runtime + system libraries" packaging approach. For example, Electron-based desktop apps bundle Chromium and Node.js together, and container images often include a full distribution's userspace. These approaches are easy to deploy but multiply size and memory overhead. Holyarrs chose to ship just a single program with the web frontend built in directly, effectively minimizing runtime dependencies. The accompanying security benefit is a reduced attack surface: no extra package manager, shell, or system services to exploit, which narrows the vulnerability exposure window.

Use Automated Checks to Prevent Regression

The developer set up automated checks: run with a 12,800-item media library, and if idle memory exceeds 250 MB, the build fails. Claude repeatedly breached this line until the check mechanism took effect, after which memory usage stabilized at around 70 MB. Another check kills the process mid-task and fails it if it doesn't recover within 2 seconds — in practice, recovery takes about half a second. These checks remain in place as features are added, and any change that makes the app heavier can't pass.

According to cross-referencing of the original Reddit post and the project roadmap page, Holyarrs' complete roadmap and demo video are publicly available at holyarrs.coderluii.dev. For developers who want to build lightweight apps with Claude, this process of "set limits, measure and compare, automate guardrails" is worth learning from.

A performance budget turns resource ceilings into automatically verifiable metrics, commonly seen in front-end build pipelines — for example, limiting bundle size or first-screen load time. Holyarrs extends this idea to runtime: using a fixed-size media library as the baseline load, failing if idle memory exceeds a threshold; and verifying crash recovery capability with a "kill the process mid-task, require recovery within a time limit" check. Such checks are typically integrated into CI, so every commit is subject to the same set of constraints, acting as an automated gatekeeper while AI continuously generates code, preventing silent performance regressions.

Implications for AI Programming

The Holyarrs case reveals an easily overlooked fact: AI coding tools are good at generating features but bad at self-restraint. Developers need to play the role of architect and gatekeeper, turning performance budgets into executable checks rather than hoping AI will voluntarily comply. When constraints are encoded as tests, AI output can truly become controllable.