Self-Hosted AI Assistant for Slack: 2026 Options

Why You Are Even Searching for This

You already have an AI option in Slack. Slack AI is built into paid plans, and Salesforce keeps pushing Agentforce into the channel sidebar as the default agent surface for Enterprise Grid. Both work, both are convenient, and both have the same hard property: every message the agent reads passes through someone else's inference pipeline, and the agent's memory of your team lives in a vendor's database you cannot inspect.

For a lot of teams that is a fine trade. For the rest - regulated industries, agencies handling client data under NDA, founders who do not want a third party indexing strategy threads, EU teams worried about US CLOUD Act exposure - the answer needs to be different. You want the chat UI of Slack, but you want the AI part to run on infrastructure you control, with secrets you own, and with no third party sitting in the middle.

This post walks through what "self-hosted AI assistant for Slack" actually means in 2026, the open-source options that ship a Slack adapter today, the architecture choices you cannot avoid, and where each option breaks down.

The Thing You Cannot Self-Host: Slack Itself

The first clarification is uncomfortable. Slack is not self-hostable. It runs exclusively on Salesforce's cloud, and even Enterprise Grid with International Data Residency only lets you pick a geographic region for storage. You do not get to install Slack on your own server, and you do not control the encryption keys.

What you can self-host is the agent on the other end of the Slack API. The message still hits Slack's servers - that is unavoidable as long as you use Slack as the chat surface. But the moment Slack delivers it to your bot, you decide where it goes next: which LLM provider sees it, which database stores the conversation, which vector store remembers it next month. That is the boundary you are actually drawing.

If you need the chat platform itself to live on your servers, you are looking at a Slack replacement (Mattermost, Rocket.Chat, Zulip), not a self-hosted Slack bot. Most teams keep Slack and only self-host the agent.

A schematic showing a Slack channel on the left and a self-hosted agent runtime on the right, with a single arrow labeled Socket Mode connecting them

What Self-Hosting Buys You

Three concrete things, and it is worth being honest about which one you actually care about before picking a stack.

Data control over what leaves the workspace. A self-hosted bot reads a Slack event, decides what context to forward to the LLM, and you wrote that decision logic. You can strip user names, redact regex patterns, route only certain channels to an external model, and keep others on a local one.

Your own model bill, not a per-seat AI tier. Slack AI is priced per user. Agentforce is priced per conversation. A self-hosted bot with a BYOK setup pays the model provider directly, usually pennies per active user per day on commodity API pricing.

A persistent memory you can audit. Hosted AI memory is opaque. A self-hosted agent keeps its memory in a Postgres or SQLite database you own. You can read it, export it, delete it, and back it up.

What self-hosting does not buy you: lower operational cost in the first month. You will spend an evening wiring up the bot, and you will be on the hook for restarts, model upgrades, and the occasional Slack scope migration. The savings show up at month three, not week one.

The Open-Source Options That Actually Ship a Slack Adapter in 2026

Most "AI bot for Slack" projects on GitHub turn out to be thin wrappers around the OpenAI API with no memory, no tool use, and no long-running runtime. The list below is filtered to projects that actually ship a Slack adapter, have a memory layer, and are maintained in 2026.

| Project | Shape | Slack mode | Good at | Falls short on | |---|---|---|---|---| | OpenClaw | Long-running personal agent runtime, 200K+ stars | Socket Mode, 24+ channels | Multi-channel breadth (Telegram + WhatsApp + Slack + Signal + iMessage in one daemon) | Personal-account oriented; team workspace ergonomics are basic | | Hermes Agent | Headless agent with memory and skills, runs as a service | Socket Mode via official adapter | Per-user allowlist, scheduled jobs, custom skills, MCP support | You manage the VPS yourself unless you use a managed host | | Archer (SlackAgent) | Slack-first agent built on Arcade + LangGraph | Built for Slack from line 1 | Native Slack UX (slash commands, ephemeral previews), Google/GitHub/Search integrations | Slack-only; no Telegram or WhatsApp fallback | | Moltworker | Self-hosted personal agent running on Cloudflare Workers | Webhook | Edge-runtime model, no VPS to babysit | Worker runtime constraints, smaller community | | Open Source Slack AI | Slack AI feature-parity utilities (thread + channel summaries) | App | Drops in to replace Slack AI's premium summary features | Not a full agent - summarization tools only, no agentic actions | | Mattermost + custom bot | Open-source Slack alternative with bot framework | Native | Full chat platform + bot in one self-hosted stack | You are also replacing Slack as the chat client, which is a much bigger migration |

The honest summary: if you want to keep Slack and you want a real agent (memory, tools, scheduled jobs, multi-step reasoning), the realistic shortlist in 2026 is OpenClaw, Hermes Agent, or Archer. The rest are either single-purpose utilities or full Slack replacements.

Socket Mode Is What Makes Self-Hosting Painless

Every option above except Moltworker uses Slack's Socket Mode. Understanding why matters before you pick a stack.

A traditional Slack app uses the Events API: Slack sends an HTTPS POST to a public URL you control whenever something happens. Self-hosting that means exposing a public HTTPS endpoint with a valid TLS certificate, which means a domain, a reverse proxy, a TLS certificate that auto-renews, and an open inbound port on the firewall. For a personal Mac or a small office server, that is the part that usually kills the project.

Socket Mode flips the direction. Your bot opens an outbound WebSocket to Slack and holds it open. Every event arrives over that single connection. No public URL, no inbound port, no TLS to manage. The bot can run on your laptop, on a $5 VPS, or behind a corporate firewall, and it will receive messages exactly the same way.

The tradeoff is that Socket Mode connections drop. The Slack docs are explicit about it: at scale the WebSocket reconnects, and any event that fires during the gap is lost - Slack does not replay it. Any production-grade self-hosted agent needs reconnection logic and an idempotent message handler, which the maintained projects above already ship.

The Hardening Checklist Nobody Mentions Until It Bites Them

The five things to lock down before letting a self-hosted bot read anything sensitive:

A numeric allowlist. Every serious Slack agent supports a SLACK_ALLOWED_USERS env var (or equivalent). It expects Slack's numeric user IDs (U01ABC234), not handles. Without it the safe default has to be deny-all - a bot invited to a public channel will otherwise answer anyone. Get your ID from your Slack profile's three-dot menu, "Copy member ID".

Scoped tokens, not user tokens. Use a bot token (xoxb-…) with the minimum scopes you need - typically app_mentions:read, chat:write, im:history, im:write, users:read. Avoid user tokens (xoxp-…) entirely; they grant your full account access to the bot, which is a much larger blast radius if the host gets compromised.

Secrets out of git. Every token (Slack bot token, app-level token, model provider key) lives in an .env file that is gitignored, or in a secrets manager. Public GitHub repos with a leaked xoxb- token get exploited within minutes.

A reverse proxy for any webhook path. If you do not use Socket Mode, your bot needs a public HTTPS endpoint. Put Caddy or Traefik in front for TLS termination and rate limiting. Never bind the agent directly to a public port.

A model provider you trust. Self-hosting the agent does nothing if you then send every Slack message to an LLM provider with weak privacy guarantees. Pick a provider with a no-training clause, or run the model locally (Ollama on a workstation with enough VRAM) for the most sensitive channels.

A deeper walkthrough of these tradeoffs lives in the self-hosted AI agent Docker guide, which is the most popular substrate for any of the runtimes above.

Where Hermes Agent Fits, and When Hermify Makes Sense

Hermes Agent is the option closest in spirit to what most teams searching this query want: a single headless runtime, Slack support via Socket Mode out of the box, allowlist by numeric ID, persistent memory in a database you control, custom skills, scheduled jobs, and a Docker image that runs on any $5 VPS. The step-by-step Slack install is documented in How to Set Up Hermes Agent on Slack - about ten minutes if you already have the runtime up.

A dark VPS terminal showing a docker compose ps output with a hermes-agent container in a healthy state and a small green status dot

The honest framing on Hermify: we built it for the second half of self-hosting that the README never warns you about. Picking the runtime is the easy day. Keeping the VPS patched, rotating Slack tokens, surviving a model provider's incident, rebuilding the container after a Hermes update, and watching the bot reconnect cleanly after a Slack outage is the part that consumes evenings. Hermify runs that ops layer for you while still giving you BYOK on the model side - same data boundary, less plumbing. If you would rather own the entire stack from VPS up, the self-hosted vs managed pricing breakdown lays out the real numbers so you can pick on substance, not vibes.

If you are ready to skip the infra evenings, Get started with Hermify and you will have a Hermes Agent ready to wire into Slack in under five minutes. If you would rather do it all yourself, the open-source options above are real and worth your time. Either path keeps your Slack content out of someone else's inference pipeline, which is the actual point.