What we mean by full coverage
The scope of services Kochab supports, why we aim for parity with the mature clients, and where the lines get drawn.
“Supported services” is a slippery phrase. Every media app claims a list, and the lists rarely tell you how deep the support goes. A read-only dashboard and a full management client can both claim Sonarr support and mean completely different things.
This is where Kochab’s scope comes from, and what we mean when we say “full coverage.”
The bar: parity with the mature clients
The honest reference point is nzb360. It has been the mobile client self-hosters actually use for years, and the reason is that it manages, not just monitors, the services it lists. You can act on a stalled download, approve a request, edit a grab, walk a full Servarr workflow from your phone.
Kochab aims for that same depth, across the same breadth, cross-platform. That means Sonarr, Radarr, Prowlarr, Lidarr, Readarr, the indexers, the download clients, the request tools, the media servers, and the host itself. Not a curated subset. Not the popular three. The full stack.
One client for every Servarr
The *arr family shares an API shape. Sonarr, Radarr, Prowlarr, Lidarr, Readarr, and the rest expose command structures that are more alike than different. Kochab is built against the shared API contract first, with per-service specialization where it matters.
The practical effect: when a new Servarr lands, or an existing one ships a new endpoint, the client doesn’t need a full rewrite per service. One piece of work covers most of the family. That’s how we keep the surface wide without the app collapsing under its own integrations.
Usenet-forward downloads
The supported download clients are the Usenet workhorses: SABnzbd and NZBGet, with combined-search tool NZBHydra2 on the roadmap. That is a deliberate choice, not an oversight. Kochab leads with Usenet, and that is where the focus stays.
Heterogeneous hosts get their own surface
A self-hosted stack isn’t just media services. It runs on something, and for most people that something is Unraid, TrueNAS, Synology, or a custom Linux box. Those hosts have disks, temperatures, Docker containers, and load. And those numbers matter to the same person who’s about to approve a 4K grab.
So Kochab treats the host as a first-class surface, starting with Unraid, with TrueNAS and Synology on the roadmap. Storage arrays, disk temps, system load, and Docker container controls (start, stop, update, autostart, logs) live alongside the media services, not buried behind a settings screen.
What is not on the list
A few projects get asked about often enough that it’s worth being explicit.
- Bazarr, Kapowarr, Bindery, NZBHydra2, TrueNAS, and Synology are on the roadmap, not in the app yet. See the services page for the full list of what’s planned.
- Archived projects are out. If upstream has stopped maintaining a service, we won’t carry the maintenance burden of supporting it either.
- Read-only dashboards for services outside the core loop aren’t the goal. Kochab is a management client, not a status board.
What “supported” actually means here
When a service is on the list, the intent is full management depth: the same kinds of actions you’d take in the service’s own web UI, structured for a phone. Coverage is priority-ordered, and the changelog is honest about which services are fully wired and which are still queued.
That’s the deal: a wide list, deep per-service control, and a client that grows with the stack rather than lagging behind it.