Why a mobile app for a self-hosted stack

Browser tabs work, but they are not how you want to manage a homelab from your phone. The case for a dedicated client.

The honest version of the argument for Kochab starts with the thing every self-hoster already does: managing the stack from a phone browser.

It works. You have Sonarr and Radarr pinned. Prowlarr is in another tab. When a download stalls you open SABnzbd, find the job, hit retry, switch back. When someone in the house wants a movie, you open Jellyseerr on mobile web, approve it, switch to Radarr to confirm the grab, switch to your media server to check it landed. Five tabs, three pinches to zoom, and a couple of re-authentications later, the thing is handled.

It works. It is also the thing Kochab replaces.

Browser tabs are not a mobile interface

Each *arr has a competent web UI. They were designed for a desk and a wide screen, and on a phone they get by through grace of responsive CSS and your willingness to pinch. Every service is a separate destination with its own login state, its own navigation patterns, and its own idea of what “the dashboard” should show.

Managing a stack this way is less like using an app and more like visiting five small offices in a row to accomplish one task. The information you actually care about at a glance, what’s downloading, what’s playing, what failed, what’s about to air, is spread across all of them, and the only place it converges is in your head.

What a dedicated client changes

A native mobile app can do something a browser fundamentally cannot: treat the stack as one system instead of five.

In Kochab, your active downloads from SABnzbd and NZBGet live in one queue, with the grab source (Sonarr, Radarr) labeled on each job. A failed retry is one tap. Jellyseerr requests show up alongside the queue that will fulfill them. Now-playing sessions from your media server sit one screen away from the downloads that feed it. The host itself, disk temperatures, Docker containers, load, is its own surface, because for a self-hoster those are not side concerns.

None of that is impossible in a browser. It is just impossible in one browser tab. The convergence is the product.

The case for native, specifically

A responsive web wrapper could centralize the view too. But on a phone, the things that make a client feel like a client are the things wrappers tend to skip: background push when a download finishes, credentials stored in the OS keychain, a navigation model built for thumbs, offline awareness of what it just fetched.

Push is the big one. A download finishing at 2am is the canonical self-hosting event, and “you’ll see it next time you open the tab” is not really an answer. Native push, delivered through a small data-only relay, is.

Who this is not for

If you only run Sonarr and you check it from a desk, the web UI is genuinely fine and Kochab is overkill. The case for a dedicated client gets stronger with every service you add and every time you want to act on the stack from somewhere that is not your desk. nzb360 users already know this; they’ve been carrying a real client for years. Kochab is the same bet, made for a stack that has grown well beyond newsgroups.

The stack outgrew the browser a long time ago. The phone is just now catching up.