29 lines
1.3 KiB
Markdown
29 lines
1.3 KiB
Markdown
# Keep the bot online
|
||
|
||
TabBot’s availability model is your hardware.
|
||
|
||
## Required for the gateway to stay up
|
||
|
||
- The **runner tab** is open (not discarded by the browser).
|
||
- The **BridgeSwarm native host** is running.
|
||
- The machine is awake. Sleep/hibernate drops TCP to Discord.
|
||
- Prefer keeping the runner **focused**. Background tab throttling is real; TabBot warns when the runner is hidden.
|
||
- Power settings: disable “sleep when idle” if you meant 24/7 on a mini PC.
|
||
|
||
## What does not keep it online
|
||
|
||
- Leaving Studio open without a runner
|
||
- “Remember this profile”
|
||
- Exporting a backup
|
||
- HoneyPeer’s website ([tab-bot.rest](https://tab-bot.rest))
|
||
|
||
Closing the runner, refreshing it after `sessionStorage` is gone without a new handshake, or calling `client.destroy()` stops that bot. That is the product thesis, not an outage HoneyPeer can SLA.
|
||
|
||
## Practical setups
|
||
|
||
- A dedicated Chromium profile + a machine that does not sleep
|
||
- One runner tab per bot, under the host max (see [Max clients](/docs/runtime/max-clients))
|
||
- Do not run TabBot on a phone browser and expect a stable gateway
|
||
|
||
If you need a bot that survives laptop lids, you want a VPS and a Node discord.js process — not TabBot. That is not a support failure; it is the architecture. Hangout anyway: [Community](/docs/guide/community).
|