> ## Documentation Index > Fetch the complete documentation index at: https://slackhive.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # How Slack Connects > SlackHive works from your laptop with no public URL, no ngrok, no port forwarding. Here's why - and whether it's safe. One of the most common questions from new users: > I'm running SlackHive on my laptop. How does Slack know where to send messages? I never opened a port. I never set up ngrok. How does it *just work*? Short answer: **Socket Mode**. Your laptop dials out to Slack over a persistent WebSocket, and Slack pushes events down that connection. Slack never has to find your machine. ## The two ways a Slack app can get events | | Webhooks (HTTP) | Socket Mode (WebSocket) | | ---------------------------- | ------------------------------------------- | ---------------------------------------------- | | Who starts the connection? | Slack → your server | Your laptop → Slack | | Need a public URL? | Yes (`https://my-app.com/events`) | No | | Need NAT / firewall changes? | Yes | No | | Typical use | Production deployments on a server with DNS | Local dev, internal tools, anything behind NAT | SlackHive uses **Socket Mode** for every agent, so you don't need ngrok, a reverse proxy, or a production hostname to run it on your laptop. ## The analogy that usually clicks Think of it like a doorbell vs. a phone call you make. **Webhook = doorbell.** Slack needs your public street address to ring your bell. Your laptop at home doesn't have one - it sits behind your Wi-Fi router, which is why webhooks would normally need ngrok to lend you a temporary public address. **Socket Mode = you call Slack.** Your laptop dials Slack first: *"Keep the line open, tell me whenever something happens."* Slack holds that line open, and every Slack message flows down it. Your laptop replies on the same line. Key point: **you dialed out.** Slack never had to find you. That's why it works from home Wi-Fi, a coffee shop, or behind any corporate NAT - outgoing calls always work, even when nobody can reach you directly. The "phone line" is a WebSocket (`wss://wss-primary.slack.com/...`), and it stays open as long as the runner is running. Stop SlackHive → line hangs up → Slack has nowhere to send messages → commands stop working. ## Does it need "internet presence"? No - just **internet access**. * **Internet access** = you can reach out to other servers. Required. * **Internet presence** = others can reach you at a public address. **Not** required. Your router's NAT lets your laptop reach out but blocks strangers from reaching in. Socket Mode rides on an outgoing connection, so NAT is fine with it - the same reason your browser works on any network without configuration. ## Is it secure? Yes - Socket Mode is what Slack recommends for local dev and internal tools. Four reasons: 1. **Encrypted.** The connection is `wss://` - WebSocket Secure, same TLS as `https://`. Nobody on your Wi-Fi can read the traffic. 2. **Authenticated.** Opening the socket requires an **app-level token** (`xapp-...`) that proves you're the real SlackHive app. Slack rejects the connection if the token is invalid. 3. **No open door.** Webhooks require a public URL - a door on the internet that attackers scan for. Socket Mode opens no ports. You dialed out; nothing is listening for incoming connections. 4. **Revocable.** If a token leaks, rotate it in the Slack admin panel. The active connection dies instantly. The real risks are generic to any app: * If someone steals `xapp-...` or `xoxb-...` off your laptop, they can impersonate SlackHive. Protect your `.env`. * If your laptop is compromised, so is anything SlackHive can see. Protect your laptop. These are "secure your machine" problems, not "Socket Mode is leaky" problems. The transport itself is solid. ## Confirming it's live If you want to see the WebSocket connection with your own eyes: ```bash theme={null} lsof -iTCP -sTCP:ESTABLISHED -nP | grep -i slack ``` You'll see an established TCP connection from the runner process to a Slack edge IP on port `443`. That's the WebSocket. If that grep returns nothing, the runner hasn't connected yet - check `~/.slackhive/logs/runner.log` for the Bolt startup line, and verify `SLACK_APP_TOKEN` and `SLACK_BOT_TOKEN` are set for the agent. ## When you'd switch to webhooks Almost never, for SlackHive's use case. Socket Mode is the recommended path for self-hosted deployments too - a VM running SlackHive is just a machine that dials out to Slack, same as your laptop. You'd only reach for webhooks if: * You need to serve thousands of workspaces from one app (enterprise distribution), or * Your org forbids outbound WebSockets (rare, and the same policy usually forbids inbound ingress anyway). SlackHive doesn't support webhook mode today. If you need it, [open an issue](https://github.com/pelago-labs/slackhive/issues). ## Related Create the per-agent Slack app that holds the tokens used to open the Socket Mode connection. Where `SLACK_APP_TOKEN` and `SLACK_BOT_TOKEN` live, and what they're for.