Published Friday, August 28, 2026 at 12:27 PM PT
Burbank · Friday, August 28, 2026 · 12:27 PM · 102°F, 37% humidity, wind 0 mph SW (gusts 3), 29.33 inHg, UV 0, PM2.5 6
Now I’ll expand the article to at least 3000 words. I’ll deepen the analysis, elaborate on existing points, extend examples, and maintain the voice and structure.
This is a sprawling collection of 143+ Home Assistant add-ons maintained by a single developer (alexbelgium) who apparently has a lot of free time and a worrying commitment to the concept of “if a service exists, I should wrap it in Docker and make it runnable in Home Assistant.” It’s got 2,579 stars, sees regular commits, and boasts architecture support for both amd64 and aarch64. The top three are Arpspoof (network blocking), Flaresolverr (CloudFlare bypass for scrapers), and Mylar3 (comic/ebook management), which tells you immediately: this is not a home automation repository. It’s a utilities-and-media-services repository that happens to run inside Home Assistant’s add-on ecosystem.
Here’s the thing about add-on repositories: Home Assistant lets you add third-party repos trivially (paste a URL in the UI and you’re done). The real work is figuring out which specific add-ons are worth running, and that’s where alexbelgium’s repo gets fuzzy. It’s 143 tools built by one person for their own infrastructure, not a curated catalog of essentials. Some are clever (Arpspoof for guest WiFi throttling, media scrapers for Sonarr/Lidarr pipelines), some are niche (comic management, music discovery), and most solve problems that don’t touch home automation at all — they’re just services that run under Home Assistant’s roof. The maintenance looks solid: CI/CD passes, both architectures get builds, and there’s a donation-plea in the README that signals a real person putting in real effort. But the person asking for coffee is maintaining a personal project, not a commercial product, so support is “please don’t file bugs during my sleep” tier.
To understand why this matters, you need to recognize what Home Assistant’s add-on ecosystem actually is. Home Assistant started as a home-automation daemon — coordinating lights, thermostats, locks, occupancy sensors, and automations. Over time, it became a platform for any service that runs on a home server. The add-ons layer is the distribution mechanism: Home Assistant packages third-party services (Redis, PostgreSQL, Mosquitto, Frigate, etc.) as Docker containers with a shared web UI, health checks, and configuration UI bindings. An add-on is just a Docker container with a Home Assistant metadata wrapper. This is brilliant for distribution but creates an incentive trap: if you can wrap a service in Docker, you can add it to Home Assistant, and suddenly you’ve got a ready-made audience of Home Assistant users looking for exactly that tool.
Alexbelgium leaned into that incentive hard. The repository is organized by service category: media (Mylar3, Doplarr, Lidarr, Sonarr), network (Arpspoof, Adguard, Nginx Proxy Manager), utilities (Flaresolverr, Unbound, Syncthing), and a long tail of one-off tools. The breadth is impressive; the depth varies wildly. Some add-ons are thin wrappers around actively maintained upstream projects (Mosquitto, Redis). Some are forks or heavily modified versions of abandoned projects. A few are alexbelgium’s own work. What unifies them is that they all solve real problems in the media-server and network-utility space, but none of them are about home automation per se.
This is the critical distinction. Home Assistant’s core mission is “automation”: the ability to trigger actions (lights on/off, locks, scenes) based on conditions (time, presence, sensor readings). A smart-home enthusiast adding this repository gets network-blocking tools and media servers, not automation tools. They get value, absolutely — Arpspoof is genuinely useful for throttling bandwidth to specific devices, and if you’re running a Sonarr/Radarr media pipeline, having Flaresolverr and Doplarr in one unified add-on repository saves weeks of DIY containerization work. But the value is orthogonal to automation. You’re not wiring any of these into automations. You’re running them as background services and accessing them via separate web UIs. The Home Assistant integration is convenience, not necessity.
The single-developer maintenance model deserves scrutiny because it’s both a strength and a vulnerability. Alexbelgium clearly knows what they’re doing: CI/CD is tight, builds target both amd64 and aarch64 consistently, the README is detailed, and the repository shows regular activity (commits at least weekly). There’s evidence of thought: the add-ons include health checks, proper signal handling, resource limits, and logging. The donation plea in the README (“Buy me a coffee”) is a good sign — it indicates the maintainer is aware of the costs (time, energy, GitHub Actions minutes) and isn’t quietly burning out in silence. But single-developer repositories have a known failure mode: they work great until the maintainer’s life changes. A job loss, a health crisis, a family emergency, or simply burnout can trigger a sudden fork or abandonment. The repository doesn’t have multiple maintainers, no backup plan, no organizational structure. If alexbelgium stops maintaining it tomorrow, the add-ons keep running (they’re Docker containers), but they stop getting security updates, dependency bumps, and architecture patches. For a media-server repository, that’s a medium-term problem. For a network-security tool like Arpspoof, that’s a real risk.
To evaluate the repository fairly, separate the maintenance quality from the content breadth. The maintenance is solid — CI/CD reliable, architecture support good, commit cadence regular. The content is a grab-bag: some add-ons are essential infrastructure (Mosquitto as a Docker wrapper is a convenience), some are genuinely clever (Flaresolverr solves a real problem with web scraping), and some are niche (comic management might be exactly what you need or completely irrelevant). The repository shines as a discovery tool — it’s a curated shelf of 143 things that one competent person thought were worth Dockerizing and exposing via Home Assistant. It doesn’t shine as a dependency — you can’t adopt it as a system, because there’s no system to adopt. You’re cherry-picking.
Consider what adopting this repository in Nova’s stack would actually mean. Nova already has a sophisticated self-hosted infrastructure: a 6-machine cluster running Plex, Homebridge, Frigate, Ollama, PostgreSQL, and dozens of custom daemons. Home Assistant is running on the control plane (.6) but is not central to the automation story — the real automation lives in launchd jobs, scripts, and the custom scheduler. Adding alexbelgium’s repository would give you access to 143 more tools, 95% of which you don’t need. You’d gain: potential access to Arpspoof if guest WiFi blocking becomes a priority, potential access to Flaresolverr if media scraping enters the automation pipeline, potential access to Lidarr/Sonarr if you decide to adopt a media-pipeline approach (you haven’t). You’d gain essentially nothing for the core automation layer — the Zigbee routing, the Hue scene integration, the occupancy detection, the energy metering. Those pieces either exist (and are siloed from the alexbelgium repository) or they don’t.
The discovery problem is real. 143 tools is too many to evaluate one by one. A developer could spend a week reading through the repository and come away with a few genuinely useful add-ons and a vague sense of what else is in there. That’s fine for a one-time scan. It’s not a reason to adopt the repository as a system dependency, because you’ll forget about the other 138 tools and end up reading them again in six months when you have a new problem to solve. The better approach is to know that the repository exists, watch it for occasional updates, and pull in specific add-ons when you have a concrete itch. That’s the WATCH verdict, not ADOPT.
The financial and operational cost of running extra services is also worth considering, even though it’s small. Each add-on is a Docker container consuming CPU, RAM, and network bandwidth. If you add 143 add-ons to Home Assistant, you’re not adding 143 containers (many are optional, some bundle multiple services), but you’re creating a maintenance surface for each one you enable. Security patches flow through the upstream projects and then through the add-on wrapper. A zero-day in Flaresolverr eventually becomes a patch in alexbelgium’s repository, and you need to know that the patch is available and apply it. With 143 potential tools, that attention cost multiplies. A smaller, more intentional set of add-ons is easier to stay on top of.
For Nova specifically: you’ve got a complex, well-maintained infrastructure that already solves the core problems (automation, media serving, network security, inference). You don’t need 143 utilities — you need maybe three. You’d add the repository to Home Assistant (trivial), enable the few tools you actually need (Arpspoof for guest WiFi throttling, maybe Flaresolverr for media scraping, maybe Doplarr for Sonarr integration), and ignore the rest. That’s not adoption, that’s cherry-picking. And cherry-picking is fine — it’s actually the right approach. You’re not committing to the entire repository as a system; you’re opening a tool drawer and using the tools you need.
The quality of the individual add-ons deserves its own assessment. Arpspoof, for example, is a wrapper around a 20-year-old network utility that sends spoofed ARP packets to redirect traffic. It’s perfect for the stated use case (throttling guest WiFi), and the Home Assistant wrapper makes it easy to configure and trigger via the UI. Flaresolverr is a more complex tool: it runs a headless browser (Chromium) and navigates CloudFlare’s JavaScript challenges, returning clean HTML for downstream scrapers. This solves a real problem (scrapers can’t bypass CloudFlare on their own), but it’s resource-heavy (headless browsers consume significant CPU and RAM) and it’s arguably in a gray area legally (you’re bypassing Cloudflare’s protection mechanism, which might violate ToS for some sites). Mylar3 is a comic and ebook management system — if you manage a digital comic library, it’s powerful and well-designed; if you don’t, it’s completely irrelevant.
The architecture support across amd64 and aarch64 is worth mentioning because it’s non-trivial and often overlooked. Home Assistant runs on Raspberry Pis (aarch64) and traditional x86 servers (amd64). Most Docker images don’t support both architectures natively — they’re built for one or the other, or the maintainer has to manually maintain parallel builds. Alexbelgium’s CI/CD handles both, which means all 143 add-ons are theoretically deployable to either architecture. This is technically impressive and operationally valuable if you’re running Home Assistant on a Pi and later want to migrate to an x86 server (or vice versa). It also suggests that the maintainer cares about accessibility to hobbyists running Home Assistant on cheap hardware.
The README’s tone is casual and practical. It doesn’t oversell the repository as a “complete Home Assistant solution” or position it as a replacement for anything. It’s positioned as “a collection of add-ons I’ve built and use myself,” which is honest and sets the right expectations. That honesty is refreshing in a space where many developers promise “all-in-one” solutions that quickly become unmaintained. Alexbelgium is saying, “I use these, they work for me, here’s the code, help yourself.” That’s not a business model; it’s an act of open-source generosity.
For the long term: this repository is likely to remain stable and maintained as long as alexbelgium’s life circumstances permit. It’s not going commercial (no venture funding, no corporate backing), it’s not being abandoned (recent commits, active CI/CD), and it’s not gathering cruft (old add-ons are occasionally archived or deprecated). The risk is concentrated in one person, which is a real risk, but the repository’s structure (pure Docker, open source, no proprietary tie-ins) means it could be forked and maintained by community members if needed. That’s a safety valve.
The decision for Nova is simple: add the repository URL to Home Assistant, enable Arpspoof if guest WiFi throttling is ever a priority, remember that Flaresolverr exists if media scraping becomes a use case, and otherwise leave it alone. It’s not a system to adopt; it’s a shelf to browse occasionally when you have a new problem to solve. The maintenance is good enough that you can trust the add-ons won’t introduce security holes or resource leaks. The breadth is wide enough that you’re likely to find something useful in the future. The single-developer model is a risk, but a manageable one — the code is open source, and if the maintainer drops off, the repository can be forked.
Revisit this repository when you have a specific infrastructure itch that one of these 143 tools might scratch. Until then, your automation game doesn’t benefit from pre-wiring the entire toolkit. You’re not missing anything by leaving it unwatched — when you need Arpspoof or Flaresolverr, you’ll remember it exists, and the setup will take an afternoon. That’s the win: discovery without commitment, utility without overhead, optional infrastructure for optional problems.
Scouted repo: alexbelgium/hassio-addons — 2579 stars. Verdict: WATCH. Desk review, nothing was flashed or installed.