If you run a media server at home, you probably run six apps just to get a movie onto it: Sonarr for shows, Radarr for movies, Lidarr for music, Bazarr for subtitles, Prowlarr for indexers and Seerr for requests. Six setups, six databases, six things to update, and an interface nobody else in the house wants to touch.

I wanted one app that does all of it and feels like Netflix. So I built HolyArrs. It launched this week, it's free and AGPL-3.0, and the Docker image is about 15 MB.

I built it with Claude Code. This post is about the part nobody warns you about: Claude doesn't care about size. Left alone, every build gets a little heavier. Here's what I did about it.

Set the limits before writing anything

Before any code existed, I wrote down how much memory the app could use sitting idle, how fast it had to start, and how big the image could be. Every feature had to fit inside those numbers. If a feature didn't fit, the feature changed, not the limit.

Test instead of guessing

When there were two ways to build something, I built both and measured them. The home page shows thousands of posters, so I built it two different ways and loaded both with the same 10,000 titles. One was about 3x lighter and drew the screen in half the time. That's the one that shipped.

Claude is great at writing both versions quickly. It's bad at telling you which one is cheaper. Measuring settles it.

No operating system in the box

The image is one Go program with the web app built into it, and nothing else. No shell, no package manager, no OS underneath. That's where most of the size difference comes from, and it also means there's very little inside for an attacker to use.

The stack is boring on purpose: Go, a Svelte frontend embedded in the binary, and SQLite.

Checks that fail when it gets heavy

This is the rule that actually worked. The test suite runs the app with a library of about 12,800 movies and shows, and fails if idle memory goes over 250 MB. Before that check existed, Claude kept creeping past the limit, one reasonable-looking change at a time. Once the check was there, it stopped.

There's a second one that kills the app in the middle of a job and fails if it isn't back within 2 seconds.

These checks stay in as features get added. If a change makes it heavier, it doesn't ship.

How I work with Claude

I design each part and write the spec. Claude Code writes most of the code from the spec. A second agent reviews it, and then I review and test everything myself on my own server. I've been in software and security for over 10 years, so anything touching keys, sign-in or the network gets read line by line, and the app had a full pentest before release.

Launch night

The real test was people using it. Bug reports started coming in on Discord within the first hour, some of them with the exact file and line that was wrong. Three fixes went out within four hours of launch.

Try it

It runs next to your current setup without touching it, and your files never move. If you don't like it, delete the container.

It's a beta, so don't make it your main app yet. If you try it, I'd love to hear what breaks.