Assistente AI self-hosted per Slack: le opzioni del 2026

Perché stai cercando proprio questo

Hai già un'opzione AI dentro Slack. Slack AI è integrato nei piani a pagamento, e Salesforce continua a spingere Agentforce nella sidebar del canale come superficie agente predefinita per Enterprise Grid. Funzionano entrambi, sono entrambi comodi, e hanno entrambi la stessa proprietà scomoda: ogni messaggio che l'agente legge passa attraverso la pipeline di inferenza di qualcun altro, e la memoria che l'agente ha del tuo team vive in un database di un fornitore che non puoi ispezionare.

Per molti team è uno scambio del tutto accettabile. Per gli altri (settori regolamentati, agenzie che gestiscono dati di clienti sotto NDA, founder che non vogliono che una terza parte indicizzi i thread di strategia, team UE preoccupati dall'esposizione al CLOUD Act statunitense) la risposta deve essere diversa. Vuoi l'interfaccia chat di Slack, ma vuoi che la parte AI giri su infrastruttura che controlli tu, con segreti che possiedi tu, e senza nessuna terza parte seduta nel mezzo.

Questo articolo ti guida attraverso cosa significhi davvero "assistente AI self-hosted per Slack" nel 2026, le opzioni open-source che oggi includono un adattatore Slack, le scelte architetturali che non puoi evitare, e dove ciascuna opzione mostra i suoi limiti.

La cosa che non puoi self-hostare: Slack stesso

La prima precisazione è scomoda. Slack non è self-hostable. Gira esclusivamente sul cloud di Salesforce, e perfino Enterprise Grid con International Data Residency ti permette soltanto di scegliere una regione geografica per l'archiviazione. Non puoi installare Slack sul tuo server, e non controlli le chiavi di crittografia.

Quello che puoi self-hostare è l'agente che sta dall'altro capo dell'API di Slack. Il messaggio passa comunque per i server di Slack: è inevitabile finché usi Slack come superficie di chat. Ma nel momento in cui Slack lo consegna al tuo bot, decidi tu dove va dopo: quale provider LLM lo vede, quale database memorizza la conversazione, quale vector store se ne ricorderà il mese prossimo. È questo il confine che stai tracciando davvero.

Se hai bisogno che la piattaforma di chat stessa viva sui tuoi server, allora stai cercando un sostituto di Slack (Mattermost, Rocket.Chat, Zulip), non un bot Slack self-hosted. La maggior parte dei team tiene Slack e self-hosta soltanto l'agente.

Uno schema che mostra un canale Slack a sinistra e un runtime agente self-hosted a destra, con una singola freccia etichettata Socket Mode che li collega

Cosa ti dà il self-hosting

Tre cose concrete, e vale la pena essere onesti su quale di queste ti interessi davvero prima di scegliere uno stack.

Controllo sui dati che escono dallo spazio di lavoro. Un bot self-hosted legge un evento di Slack, decide quale contesto inoltrare all'LLM, e quella logica decisionale l'hai scritta tu. Puoi rimuovere i nomi utente, oscurare pattern regex, instradare solo certi canali verso un modello esterno e tenerne altri su uno locale.

La tua bolletta del modello, non una fascia AI per postazione. Slack AI ha un prezzo per utente. Agentforce ha un prezzo per conversazione. Un bot self-hosted con setup BYOK paga il provider del modello direttamente, di solito pochi centesimi per utente attivo al giorno ai prezzi standard delle API.

Una memoria persistente che puoi verificare. La memoria AI ospitata è opaca. Un agente self-hosted tiene la sua memoria in un database Postgres o SQLite che possiedi tu. Puoi leggerla, esportarla, cancellarla e farne il backup.

Cosa il self-hosting non ti dà: costi operativi più bassi nel primo mese. Passerai una serata a cablare il bot, e sarai tu il responsabile dei riavvii, degli aggiornamenti del modello e dell'occasionale migrazione degli scope di Slack. I risparmi arrivano al terzo mese, non alla prima settimana.

Le opzioni open-source che nel 2026 includono davvero un adattatore Slack

La maggior parte dei progetti "bot AI per Slack" su GitHub si rivela un sottile wrapper attorno all'API di OpenAI, senza memoria, senza uso di strumenti e senza un runtime di lunga durata. L'elenco qui sotto è filtrato sui progetti che includono davvero un adattatore Slack, hanno un livello di memoria e sono mantenuti nel 2026.

Progetto	Forma	Modalità Slack	Punti di forza	Dove non arriva
OpenClaw	Runtime di agente personale di lunga durata, oltre 200K stelle	Socket Mode, oltre 24 canali	Ampiezza multicanale (Telegram + WhatsApp + Slack + Signal + iMessage in un unico daemon)	Orientato all'account personale; l'ergonomia per gli spazi di lavoro di team è basilare
Hermes Agent	Agente headless con memoria e skill, gira come servizio	Socket Mode tramite adattatore ufficiale	Allowlist per utente, processi pianificati, skill personalizzate, supporto MCP	Gestisci tu stesso il VPS, a meno che tu non usi un host gestito
Archer (SlackAgent)	Agente Slack-first costruito su Arcade + LangGraph	Pensato per Slack dalla prima riga	UX Slack nativa (slash command, anteprime effimere), integrazioni Google/GitHub/Search	Solo Slack; nessun fallback Telegram o WhatsApp
Moltworker	Agente personale self-hosted che gira su Cloudflare Workers	Webhook	Modello edge-runtime, nessun VPS da accudire	Vincoli del runtime Worker, community più piccola
Open Source Slack AI	Utility con parità di funzionalità rispetto a Slack AI (riepiloghi di thread + canali)	App	Si inserisce per sostituire le funzioni premium di riepilogo di Slack AI	Non è un agente completo: solo strumenti di riepilogo, nessuna azione agentica
Mattermost + bot personalizzato	Alternativa open-source a Slack con framework per bot	Nativa	Piattaforma di chat completa + bot in un unico stack self-hosted	Stai anche sostituendo Slack come client di chat, il che è una migrazione molto più grande

Il riassunto onesto: se vuoi tenere Slack e vuoi un agente vero (memoria, strumenti, processi pianificati, ragionamento multi-step), la rosa realistica nel 2026 è OpenClaw, Hermes Agent o Archer. Il resto sono o utility a scopo singolo o sostituti completi di Slack.

La Socket Mode è ciò che rende indolore il self-hosting

Ogni opzione qui sopra, tranne Moltworker, usa la Socket Mode di Slack. Capire perché conta prima di scegliere uno stack.

Una classica app Slack usa la Events API: Slack invia un POST HTTPS a un URL pubblico che controlli tu ogni volta che accade qualcosa. Self-hostarla significa esporre un endpoint HTTPS pubblico con un certificato TLS valido, il che vuol dire un dominio, un reverse proxy, un certificato TLS che si rinnova da solo e una porta in entrata aperta sul firewall. Per un Mac personale o il server di un piccolo ufficio, è di solito la parte che fa morire il progetto.

La Socket Mode inverte la direzione. Il tuo bot apre un WebSocket in uscita verso Slack e lo tiene aperto. Ogni evento arriva su quell'unica connessione. Nessun URL pubblico, nessuna porta in entrata, nessun TLS da gestire. Il bot può girare sul tuo laptop, su un VPS da 5$ o dietro il firewall aziendale, e riceverà i messaggi esattamente nello stesso modo.

Il compromesso è che le connessioni Socket Mode cadono. La documentazione di Slack lo dice esplicitamente: a regime il WebSocket si riconnette, e qualsiasi evento scatti durante l'interruzione va perso: Slack non lo ritrasmette. Qualsiasi agente self-hosted di livello produzione ha bisogno di logica di riconnessione e di un gestore di messaggi idempotente, cosa che i progetti mantenuti qui sopra includono già.

La checklist di hardening che nessuno menziona finché non scotta

Le cinque cose da blindare prima di lasciare che un bot self-hosted legga qualcosa di sensibile:

Una allowlist numerica. Ogni agente Slack serio supporta una variabile d'ambiente SLACK_ALLOWED_USERS (o equivalente). Si aspetta gli ID utente numerici di Slack (U01ABC234), non gli handle. Senza, il default sicuro deve essere deny-all: un bot invitato in un canale pubblico altrimenti risponderebbe a chiunque. Recupera il tuo ID dal menu a tre puntini del tuo profilo Slack, "Copia ID membro".

Token con scope limitati, non token utente. Usa un token bot (xoxb-…) con gli scope minimi che ti servono: di norma app_mentions:read, chat:write, im:history, im:write, users:read. Evita del tutto i token utente (xoxp-…); concedono al bot l'accesso completo al tuo account, il che è un raggio di esplosione molto più ampio se l'host viene compromesso.

Segreti fuori da git. Ogni token (token bot Slack, token a livello di app, chiave del provider del modello) vive in un file .env che è in gitignore, oppure in un secrets manager. I repo GitHub pubblici con un token xoxb- trapelato vengono sfruttati nel giro di pochi minuti.

Un reverse proxy per qualsiasi percorso webhook. Se non usi la Socket Mode, il tuo bot ha bisogno di un endpoint HTTPS pubblico. Metti Caddy o Traefik davanti per la terminazione TLS e il rate limiting. Non legare mai l'agente direttamente a una porta pubblica.

Un provider del modello di cui ti fidi. Self-hostare l'agente non serve a nulla se poi mandi ogni messaggio Slack a un provider LLM con garanzie di privacy deboli. Scegli un provider con una clausola no-training, oppure fai girare il modello localmente (Ollama su una workstation con abbastanza VRAM) per i canali più sensibili.

Un approfondimento su questi compromessi vive nella guida Docker all'agente AI self-hosted, che è il substrato più diffuso per uno qualsiasi dei runtime qui sopra.

Dove si colloca Hermes Agent, e quando ha senso Hermify

Hermes Agent è l'opzione più vicina nello spirito a ciò che vuole la maggior parte dei team che cercano questa query: un singolo runtime headless, supporto Slack via Socket Mode out of the box, allowlist per ID numerico, memoria persistente in un database che controlli tu, skill personalizzate, processi pianificati e un'immagine Docker che gira su qualsiasi VPS da 5$. L'installazione su Slack passo dopo passo è documentata in Come configurare Hermes Agent su Slack: circa dieci minuti se hai già il runtime attivo.

Un terminale VPS scuro che mostra l'output di docker compose ps con un container hermes-agent in stato healthy e un piccolo pallino di stato verde

L'inquadramento onesto su Hermify: l'abbiamo costruito per la seconda metà del self-hosting di cui il README non ti avverte mai. Scegliere il runtime è il giorno facile. Tenere il VPS aggiornato, ruotare i token di Slack, sopravvivere all'incidente di un provider del modello, ricostruire il container dopo un aggiornamento di Hermes e guardare il bot riconnettersi in modo pulito dopo un'interruzione di Slack è la parte che consuma le serate. Hermify gestisce quel livello operativo al posto tuo pur lasciandoti il BYOK sul lato del modello: stesso confine dei dati, meno cablaggio. Se preferisci possedere l'intero stack dal VPS in su, l'analisi dei prezzi self-hosted vs gestito mette nero su bianco i numeri reali, così puoi scegliere sulla sostanza, non sulle sensazioni.

Se sei pronto a saltare le serate sull'infrastruttura, inizia con Hermify e avrai un Hermes Agent pronto da collegare a Slack in meno di cinque minuti. Se preferisci fare tutto da solo, le opzioni open-source qui sopra sono reali e valgono il tuo tempo. Entrambi i percorsi tengono i tuoi contenuti Slack fuori dalla pipeline di inferenza di qualcun altro, che è il punto vero.