---
title: "How Slack Connects"
description: "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
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

<CardGroup cols={2}>
  <Card title="Slack App Setup" icon="slack" href="/configuration/slack-app">
    Create the per-agent Slack app that holds the tokens used to open the Socket Mode connection.
  </Card>
  <Card title="Environment Variables" icon="key" href="/configuration/env-vars">
    Where `SLACK_APP_TOKEN` and `SLACK_BOT_TOKEN` live, and what they're for.
  </Card>
</CardGroup>
