Assistente de IA self-hosted no Slack: opções 2026

Por que você está procurando isto

Você já tem uma opção de IA dentro do Slack. O Slack AI vem embutido nos planos pagos, e a Salesforce continua empurrando o Agentforce como a superfície de agente padrão na barra lateral do Enterprise Grid. As duas funcionam, as duas são cômodas e as duas têm a mesma propriedade dura: cada mensagem que o agente lê passa pelo pipeline de inferência de outra pessoa, e a memória que esse agente constrói sobre seu time mora num banco de dados do fornecedor que você não pode inspecionar.

Para muitos times essa troca é aceitável. Para o resto - setores regulados, agências que tratam dados de cliente sob NDA, founders que não querem um terceiro indexando threads de estratégia, times europeus preocupados com o CLOUD Act dos EUA - a resposta precisa ser outra. Você quer a UI de chat do Slack, mas quer que a parte de IA rode em infraestrutura que você controla, com segredos que são seus e sem um terceiro no meio.

Este texto percorre o que "assistente de IA self-hosted no Slack" realmente significa em 2026, as opções open source que hoje trazem um adapter de Slack, as escolhas de arquitetura inevitáveis e onde cada opção falha.

O que você não consegue self-hostar: o próprio Slack

O primeiro esclarecimento é desconfortável. Slack não é self-hostável. Ele roda exclusivamente na nuvem da Salesforce, e nem o Enterprise Grid com International Data Residency te deixa fazer mais do que escolher uma região geográfica para o armazenamento. Você não instala o Slack no seu servidor e não controla as chaves de criptografia.

O que você consegue self-hostar é o agente do outro lado da API do Slack. A mensagem continua passando pelos servidores do Slack - é inevitável enquanto o Slack for sua superfície de chat. Mas no momento em que o Slack entrega essa mensagem para o seu bot, você decide para onde ela vai depois: qual provedor de LLM a vê, qual banco guarda a conversa, qual vector store lembra dela no mês que vem. Essa é a fronteira real que você está traçando.

Se você precisa que a plataforma de chat em si viva nos seus servidores, está procurando um substituto do Slack (Mattermost, Rocket.Chat, Zulip), não um bot self-hosted para Slack. A maioria dos times mantém o Slack e só self-hospeda o agente.

Um esquema com um canal do Slack à esquerda e um runtime de agente self-hosted à direita, ligados por uma única seta com o rótulo Socket Mode

O que o self-hosting te compra

Três coisas concretas, e vale a honestidade de saber qual delas realmente te importa antes de escolher um stack.

Controle sobre o que sai do workspace. Um bot self-hosted lê um evento do Slack, decide qual contexto repassa para o LLM, e essa lógica de decisão foi você que escreveu. Você consegue tirar nomes de usuário, redigir padrões regex, rotear só certos canais para um modelo externo e manter outros num modelo local.

Sua própria conta do modelo, não uma camada de IA por usuário. Slack AI é cobrado por usuário. Agentforce é cobrado por conversa. Um bot self-hosted com BYOK paga ao provedor do modelo direto, normalmente centavos por usuário ativo por dia em preços de API padrão.

Uma memória persistente que você pode auditar. A memória da IA hospedada é opaca. Um agente self-hosted guarda sua memória numa Postgres ou SQLite sua. Você lê, exporta, apaga e faz backup.

O que self-hosting não te compra: menos custo operacional no primeiro mês. Vai investir uma noite cabeando o bot e fica responsável por reinícios, atualizações de modelo e a migração ocasional de scopes do Slack. A economia aparece no terceiro mês, não na primeira semana.

As opções open source que realmente trazem um adapter de Slack em 2026

A maioria dos projetos "AI bot for Slack" do GitHub acaba sendo um wrapper fino em volta da API da OpenAI, sem memória, sem uso de ferramentas e sem runtime de longa duração. A lista abaixo está filtrada para projetos que de fato trazem um adapter de Slack, têm uma camada de memória e são mantidos em 2026.

| Projeto | Forma | Modo Slack | Bom em | Onde falha | |---|---|---|---|---| | OpenClaw | Runtime de agente pessoal de longa duração, 200K+ stars | Socket Mode, 24+ canais | Largura multicanal (Telegram + WhatsApp + Slack + Signal + iMessage num mesmo daemon) | Voltado para conta pessoal; ergonomia para workspaces de time é básica | | Hermes Agent | Agente headless com memória e skills, roda como serviço | Socket Mode via adapter oficial | Allowlist por usuário, jobs agendados, skills customizadas, suporte a MCP | Você cuida do VPS, a menos que use um host gerenciado | | Archer (SlackAgent) | Agente nativo de Slack sobre Arcade + LangGraph | Pensado para Slack desde o começo | UX nativa do Slack (slash commands, previews efêmeras), integrações com Google/GitHub/Search | Só Slack; sem fallback para Telegram ou WhatsApp | | Moltworker | Agente pessoal self-hosted rodando em Cloudflare Workers | Webhook | Modelo edge-runtime, sem VPS para cuidar | Restrições do runtime de Workers, comunidade menor | | Open Source Slack AI | Utilidades equivalentes às funções premium do Slack AI (resumos de thread e canal) | App | Encaixa como substituto dos resumos premium do Slack AI | Não é um agente completo - só ferramentas de resumo, sem ações agênticas | | Mattermost + bot custom | Alternativa open source ao Slack com framework de bots | Nativo | Plataforma de chat completa e bot num stack self-hosted | Você também está trocando o Slack como cliente de chat, uma migração bem maior |

O resumo honesto: se você quer continuar no Slack e quer um agente de verdade (memória, ferramentas, jobs agendados, raciocínio multi-passo), a shortlist realista em 2026 é OpenClaw, Hermes Agent ou Archer. O resto são utilidades de propósito único ou substitutos completos do Slack.

Socket Mode é o que torna self-hosting indolor

Todas as opções acima exceto o Moltworker usam o Socket Mode do Slack. Vale entender por que antes de escolher um stack.

Um app tradicional do Slack usa a Events API: o Slack manda um POST HTTPS para uma URL pública sua sempre que algo acontece. Self-hostar isso significa expor um endpoint HTTPS público com certificado TLS válido, o que implica um domínio, um proxy reverso, um certificado TLS com auto-renovação e uma porta de entrada aberta no firewall. Para um Mac pessoal ou um servidor de escritório pequeno, essa costuma ser a parte que mata o projeto.

O Socket Mode inverte a direção. Seu bot abre um WebSocket de saída para o Slack e mantém aberto. Todo evento chega por essa única conexão. Sem URL pública, sem porta de entrada, sem TLS para gerenciar. O bot pode rodar no seu notebook, num VPS de $5 ou atrás de um firewall corporativo e vai receber as mensagens igual.

A contrapartida é que conexões Socket Mode caem. A doc do Slack é explícita: em escala o WebSocket reconecta e qualquer evento que dispare durante o intervalo é perdido - o Slack não replica. Qualquer agente self-hosted de qualidade precisa de lógica de reconexão e de um handler idempotente, e isso é algo que os projetos mantidos acima já trazem.

A checklist de hardening que ninguém menciona até doer

As cinco coisas para travar antes de deixar um bot self-hosted ler qualquer coisa sensível:

Uma allowlist numérica. Todo agente sério do Slack suporta uma env var SLACK_ALLOWED_USERS (ou equivalente). Ela espera IDs numéricos do Slack (U01ABC234), não handles. Sem isso o default seguro precisa ser deny-all - senão um bot convidado para um canal público responderia para qualquer um. Pegue seu ID no menu de três pontos do seu perfil do Slack, "Copy member ID".

Tokens com escopo, não tokens de usuário. Use um bot token (xoxb-…) com os escopos mínimos que você precisa - tipicamente app_mentions:read, chat:write, im:history, im:write, users:read. Evite user tokens (xoxp-…) de forma absoluta; eles dão ao bot acesso total à sua conta, o que multiplica o raio de impacto se o host for comprometido.

Segredos fora do git. Cada token (bot token do Slack, app-level token, chave do provedor do modelo) mora num arquivo .env no gitignore, ou num gerenciador de segredos. Repos públicos do GitHub com um xoxb- vazado são explorados em minutos.

Um proxy reverso para qualquer rota webhook. Se você não usar Socket Mode, seu bot precisa de um endpoint HTTPS público. Coloque Caddy ou Traefik na frente para terminar TLS e fazer rate limit. Nunca amarre o agente direto numa porta pública.

Um provedor de modelo confiável. Self-hostar o agente não adianta se depois você manda cada mensagem do Slack para um LLM com garantias de privacidade fracas. Escolha um provedor com cláusula de no-training, ou rode o modelo localmente (Ollama numa workstation com VRAM suficiente) para os canais mais sensíveis.

Uma análise mais profunda dessas decisões está no guia Docker do agente de IA self-hosted, que é a base mais popular para qualquer um dos runtimes acima.

Onde Hermes Agent se encaixa e quando Hermify faz sentido

Hermes Agent é a opção mais próxima em espírito do que a maioria dos times que faz essa busca quer: um único runtime headless, suporte a Slack via Socket Mode pronto, allowlist por ID numérico, memória persistente num banco que você controla, skills customizadas, jobs agendados e uma imagem Docker que roda em qualquer VPS de $5. A instalação passo a passo do Slack está documentada em Como configurar o Hermes Agent no Slack - cerca de dez minutos se você já tem o runtime de pé.

Um terminal escuro de VPS mostrando um docker compose ps com um contêiner hermes-agent em estado healthy e um pequeno ponto verde de status

O enquadramento honesto sobre o Hermify: construímos para a segunda metade do self-hosting, aquela que o README nunca te avisa. Escolher o runtime é o dia fácil. Manter o VPS atualizado, rodar rotações de tokens do Slack, sobreviver a um incidente do provedor de modelo, reconstruir o contêiner depois de um update do Hermes e ver o bot reconectar limpo depois de uma queda do Slack é a parte que consome noites. O Hermify roda essa camada de ops por você e ainda assim te deixa BYOK no modelo - mesma fronteira de dados, menos encanamento. Se você prefere ter o stack inteiro do VPS para cima, o comparativo de preço self-hosted vs gerenciado coloca os números reais na mesa para você decidir com substância, não com sentimento.

Se você está pronto para pular as noites de infra, comece com o Hermify e terá um Hermes Agent pronto para plugar no Slack em menos de cinco minutos. Se prefere fazer tudo na mão, as opções open source acima são reais e valem o seu tempo. Qualquer um dos caminhos mantém o conteúdo do seu Slack fora do pipeline de inferência de outra pessoa, que é o ponto de verdade.