One of the most common questions from new users:Documentation Index
Fetch the complete documentation index at: https://slackhive.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
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 |
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.
Is it secure?
Yes - Socket Mode is what Slack recommends for local dev and internal tools. Four reasons:- Encrypted. The connection is
wss://- WebSocket Secure, same TLS ashttps://. Nobody on your Wi-Fi can read the traffic. - 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. - 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.
- Revocable. If a token leaks, rotate it in the Slack admin panel. The active connection dies instantly.
- If someone steals
xapp-...orxoxb-...off your laptop, they can impersonate SlackHive. Protect your.env. - If your laptop is compromised, so is anything SlackHive can see. Protect your laptop.
Confirming it’s live
If you want to see the WebSocket connection with your own eyes: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).
Related
Slack App Setup
Create the per-agent Slack app that holds the tokens used to open the Socket Mode connection.
Environment Variables
Where
SLACK_APP_TOKEN and SLACK_BOT_TOKEN live, and what they’re for.