StreamHive is a browser ops deck. There is no app to download, no installer, no second window that has to stay in the tray. Paste your channel, pick viewers, choose a proxy strategy and a chat persona, save as a preset, hit Start run. The run holds until you stop it or the stream actually ends. The product is that panel, not a binary we ship you.
Everything you can tune is visible in one place: channel, viewer count, proxy pool, presets, and the toggles for retention smoothing, gradual ramp, and chat personas. Hidden settings are how people get a curve they cannot replay. If it changes the hold, it is on the deck. If it is not on the deck, it is not part of the product you are being asked to trust.
Presets are the bespoke bit. Steady Growth, Launch Spike, Chat Warmup — each is a different curve with different host and chat behaviour, not a sticker on the same slider. Steady Growth climbs slowly and holds flat. Launch Spike spends more of the twenty-per-tick spawn budget without becoming a thundering herd. Chat Warmup puts voices in the room on a separate host surface before the count peaks. Save one that already moved Kick's public count on your channel and replay it next time.
The public site is not the ops deck. On streamhive.net, `/landing` is the marketing home and `/waitlist/demo` is how you join a batch. The operator UI lives at `/` only in dashboard mode, locally, next to the Flask helper. Public CTAs that sent people to `/` were a bug: in waitlist mode that path 301s back to landing, not into a control panel. If you arrived from search, you are looking at the marketing surface. The deck is what you get when a batch opens.
That split is load-bearing. The marketing pages cannot start a bot, cannot write logs, and cannot see your channel. The deck talks only over Socket.IO to a local helper. There is no REST start/stop path and no remote account API in the tree that would let a stranger on the waitlist fire a hold. Treating the landing page as if it were the product is how you confuse a waitlist with a running session.
What the deck actually shows, once a run is up, is Kick — not our sockets. Live Viewers is Kick's viewer_count, polled ~5s through one spare unique host, off the spawn path. Active Bots is live websockets. They are allowed to disagree. A deck that reported Active as viewers would be a prettier product and a worse one. We would rather the panel look humble when Kick has not converted the hold yet.
Host hygiene is not a power-user footnote; it is the geometry the deck is built around. One unique reserved host per session, no sharing, no direct-connect fallback when a tunnel fails, no fake channel IDs if Kick does not resolve the slug. Hunters acquire their own slot and host inside the worker. Dead hunters are reaped. Spawn caps at twenty per tick so the control loop keeps answering. The slider is a request. The pool is the ceiling.
Chat is a second product surface on the same deck, not a checkbox that reuses viewer IPs. Kick chat is its own Socket.IO path, started on its own event, and it refuses to run without a reserved host of its own. Viewers watch; chatters talk. Mixing them on one address is the fastest way to look synthetic. If you want both, budget hosts for both. If you want only a warm room, you can run chat without a viewer fill — the deck will not couple them to save you a proxy.
The honesty note belongs on a product post because the deck is where the ToS exposure lives. Inflating viewer numbers and running fake chatters against your own channel violate Kick's terms. A browser UI, unique hosts, and staged ramps do not make that compliant. They make the run look less like a block of identical viewers arriving at once. Realism is not permission. We say so on the deck and we say so here.
Verification is the same whether you found us from `/landing` or from a friend. Boot the helper and the UI, pick a live low-viewer channel, record Kick's public count, start, and wait until Kick moves. Keep the session logs. If Kick never moves after sockets are up, it failed, even if Active looks perfect. We do not treat a boot-only smoke as a pass, and neither should you. The product is a hold Kick agrees with, or it is not a product.
Why browser, specifically? Because the people who run this already have a tab on the channel and a tab on Kick's API. A native app that hid the same knobs behind a title bar would not make the curve more real. It would make the session harder to watch next to the public count. The deck is supposed to sit beside Kick, not replace it. That is also why Live Viewers is a proxied Kick JSON and not a number we compute from sockets.
Mobile control is the same deck in a smaller viewport, not a second app. Channel, count, pool, presets, start, stop. If a control cannot fit on a phone, it did not belong as a hidden desktop-only flag either. The point of one panel is that the person who started the hold can stop it from the couch without SSHing into anything.
When a stream actually ends, the deck should say so. Consecutive Kick 200s for your channel with a null livestream flip stream_offline, set should_stop, and show stopped / 'Stream ended - bot stopped.' A mismatched payload from a bad free proxy does not count. The UI has to learn that from the bot on the same tick, or you will sit there believing you are still filling a room that went dark. Self-stop is part of the product, not an edge case for the log file.
Free proxies are how you find out whether the curve fits. They rotate, they die, they are the wrong ceiling for a nightly four hundred. The deck will load them, live-check them, and hold what survives. Paid ISP lists you upload are how you make the same preset repeatable. The product does not pretend those are the same job. Calibration is free. Production is a list you control, deduped by host, never fallen back to your real IP.
A first session, if you have never opened the deck. Twenty-five viewers. All proxy types or a small ISP list. A live channel with tens of viewers, not thousands, so a lift is visible. Watch Kick's count, watch Live Viewers track it, watch Active climb as unique hosts allow. Save Steady Growth if that is the curve you got. Do not raise the slider until Kick has agreed with the small run. The product is that loop — configure, start, read Kick, save, replay — not a download button.
Packaged builds exist for operators who want the helper as an exe. They are still the same deck talking to the same local process. Packaging is distribution, not a different product. If you are on the waitlist, you are not choosing between an app and a site; you are waiting for a batch of the browser deck. When marketing fully lives on `/landing`, `/waitlist/demo` retires. The deck stays the deck.
What we will not add to the panel just to look like a bigger product: a fake viewer number, a fake channel id, a chat that shares viewer IPs, a start path that does not need a host, or a status that says RUNNING when the stream has ended. Each of those would make the screenshot nicer. Each of them would make the deck something other than the product we are willing to put next to Kick's own tab.
What lives next to the knobs matters as much as the knobs. Live Monitoring has to stay coherent with Kick: LIVE VIEWERS / Now / Peak / Average track the public count, Active climbs toward the requested number as unique hosts allow, Unique Hosts / Live Proxies / Requests move, Status is RUNNING with Stop Bot once sockets are up, and CPU / memory / network are not frozen at zero. A pretty panel that fails any of those is a screenshot, not a deck.
We will not grow the panel into an admin console. There is no staff UI in this product and no second JSON format for 'how StreamHive runs StreamHive.' One JSON per operator/channel is the ship spec; the knobs on the page are the spec. If a control cannot be explained as something you would change between streams, it does not belong on the deck. Complexity that only we would use is how a browser panel turns into the app we refused to ship.
So: one browser panel, presets you replay, Kick as the source of truth, unique hosts as the ceiling, chat on its own surface, and a waitlist that is not the operator UI. The ops deck is the product because everything that changes a hold is on it, and everything that would only make the screenshot prettier is not.