Come eseguire nanobot 24/7 su un Mac mini dedicato (agente AI self-hosted)

1. Perché eseguire nanobot su un Mac mini?

nanobot è costruito attorno a un processo gateway di lunga durata: la documentazione ufficiale dice di tenere nanobot gateway in esecuzione perché gestisce la consegna in background per le app di chat, i topic della WebUI, le automazioni pianificate, i trigger locali e l'heartbeat. Questo funziona solo su una macchina che non va mai in stop. Un Mac mini dedicato di MyRemoteMac ti offre esattamente questo, un Mac Apple Silicon fisico, tutto tuo, online 24/7 con SLA del 99,9%, root completo, accesso SSH e VNC e una VPN WireGuard, a un prezzo mensile fisso invece della fatturazione di un VPS tier GPU. E poiché è macOS, nanobot può usare la sua sandbox exec Seatbelt integrata (sandbox-exec, fornito con macOS) ed eseguire un modello Ollama locale sulla stessa macchina.

2. Prerequisiti

nanobot viene distribuito come pacchetto PyPI nanobot-ai con wheel di piattaforma per macOS 13+ su Apple Silicon e Intel che includono la WebUI e l'interfaccia da terminale nativa. Il percorso di installazione standard non richiede Node.js, Homebrew né Git. Ecco cosa ti serve:

• Un Mac mini dedicato di MyRemoteMac, M4 da $85/mese (16 GB / 256 GB) o M6 da $149/mese. Entrambi sono Apple Silicon e coperti dalla wheel macOS arm64.
• Accesso SSH al tuo Mac mini (incluso nel tuo abbonamento MyRemoteMac) e un account utente standard, non root per eseguire nanobot, il SECURITY.md del progetto dice di non eseguirlo mai come root.
• Python 3.11 o più recente e curl. L'installer in un comando si interrompe se trova solo un python3 più vecchio; uv o pipx sono opzionali ma consigliati quando pip segnala externally-managed-environment.
• Un provider LLM: una chiave API (Anthropic, OpenAI, OpenRouter, Gemini, DeepSeek, Groq, Mistral e circa 40 altri sono integrati) oppure un server locale compatibile OpenAI come Ollama in esecuzione sullo stesso Mac mini.
• Un account di messaggistica su Telegram, Discord, Slack o WhatsApp per raggiungere il tuo agente (Telegram è il più rapido: un token bot da @BotFather e nessuna porta in ingresso).

3. Passo 1: Connettiti via SSH e installa nanobot

Connettiti al tuo Mac mini via SSH con le credenziali della tua dashboard MyRemoteMac. Esegui ogni comando di questa guida come utente macOS normale, mai come root: il LaunchAgent che installerai più avanti viene eseguito nella sessione di quell'utente.

Connettiti via SSH e verifica Python

# Connect to your Mac mini as a standard user (never root: SECURITY.md)
ssh admin@your-server-ip

# Confirm you are on Apple Silicon
uname -m
# arm64

# nanobot needs Python 3.11 or newer: install a current Python first if this is older
python3 --version
# Python 3.12.x

# curl is used to fetch the one-command installer
which curl

Installa nanobot

Il percorso predefinito del progetto è un installer in un comando che installa o aggiorna nanobot-ai da PyPI usando un ambiente virtuale attivo, uv, pipx o un venv gestito in ~/.nanobot/venv, e stampa il comando esatto che ha usato. Poiché SSH_CONNECTION è impostata, salta la WebUI nel browser ed esegue invece la procedura guidata da terminale nanobot onboard --wizard. Prima fai un'anteprima con --dry-run. Se preferisci gestire l'installazione da solo, uv e pipx sono le alternative documentate:

# Option A, official one-command installer: preview, then run
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dry-run
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh
# Over SSH it runs the terminal wizard `nanobot onboard --wizard` instead of opening the WebUI.
# The script reads NANOBOT_SKIP_WIZARD / PYTHON from sh's own environment, so set them on sh, not on curl:
# curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | NANOBOT_SKIP_WIZARD=1 sh
# curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | PYTHON=/path/to/python3.12 sh

# Option B: uv (isolated tool install, no externally-managed-environment errors)
uv tool install nanobot-ai

# Option C: pipx, or pip inside a virtual environment
pipx install nanobot-ai
# python3 -m pip install nanobot-ai
# pip says "externally-managed-environment"? Use Option A or B: never --break-system-packages

Verifica l'installazione

Se nanobot non è nel tuo PATH in una nuova shell, usa il runner stampato dall'installer (uv tool run, pipx run o il venv gestito) oppure aggiungi ~/.local/bin al tuo PATH:

nanobot --version
# 0.3.5

# `nanobot` not found? Use the runner the installer printed:
uv tool run --from nanobot-ai nanobot --version
pipx run --spec nanobot-ai nanobot --version
~/.nanobot/venv/bin/python -m nanobot --version

4. Passo 2: Configura un provider di modelli (API o Ollama locale)

nanobot legge tutto da ~/.nanobot/config.json (provider, preset di modello, canali, strumenti) e conserva memoria, skill e file generati in ~/.nanobot/workspace/. La procedura guidata da terminale crea entrambi. Gli snippet di configurazione nella documentazione ufficiale usano chiavi in camelCase e vanno uniti al file, non incollati per intero. Il file viene letto una sola volta all'avvio, quindi riavvia il gateway dopo ogni modifica.

Esegui la procedura guidata da terminale

# Documented path for SSH / headless installs (the installer already ran it unless skipped)
nanobot onboard --wizard
# Creates ~/.nanobot/config.json and ~/.nanobot/workspace/

# Later, after an upgrade: merge new default fields without overwriting your values
nanobot onboard --refresh

Aggiungi un provider e un preset di modello

Un preset associa un provider a un modello. L'esempio della documentazione è Anthropic diretto con claude-opus-4-5; l'errore più comune al primo avvio è mischiare la chiave API di un provider con l'ID modello di un altro, quindi fissa sempre il provider nel preset. Gli esempi ufficiali fanno riferimento alla chiave come ${ANTHROPIC_API_KEY}, risolta dall'ambiente del processo che avvia nanobot e mai riscritta nel file. Funziona per le sessioni in primo piano avviate dalla tua shell (l'ereditarietà dell'ambiente da parte del processo --background scollegato non è documentata), ma il LaunchAgent generato al Passo 4 non trasporta variabili d'ambiente, quindi per un deployment con launchd salva la chiave in config.json e blocca il file come descritto in SECURITY.md:

# Merge into ~/.nanobot/config.json (key from console.anthropic.com)
{
  "providers": {
    "anthropic": { "apiKey": "sk-ant-YOUR_API_KEY_HERE" }
  },
  "modelPresets": {
    "primary": {
      "provider": "anthropic",
      "model": "claude-opus-4-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": { "defaults": { "modelPreset": "primary" } }
}

# Docs alternative for shell-started sessions: "apiKey": "${ANTHROPIC_API_KEY}"
# (resolved from the environment at startup; an unset variable fails fast with ConfigLoadError)

# Lock the config down (SECURITY.md)
chmod 700 ~/.nanobot && chmod 600 ~/.nanobot/config.json

Opzionale: usa un modello locale con Ollama

nanobot ha un provider ollama dedicato. Avvia Ollama sul Mac mini separatamente (vedi la nostra guida agli LLM su Mac mini), poi punta il provider a http://localhost:11434/v1, il nome del modello è il tag Ollama grezzo, senza prefisso, e la maggior parte delle configurazioni Ollama non richiede una chiave API. Le catene di fallback fanno riferimento ai nomi dei preset, quindi puoi tenere un modello frontier hosted come primario e un preset locale come fallback (o viceversa):

# Ollama must already be running on the Mac mini (started separately, outside nanobot)
# Merge into ~/.nanobot/config.json: model = raw Ollama tag, no prefix, no API key needed
{
  "providers": {
    "ollama": { "apiBase": "http://localhost:11434/v1" }
  },
  "modelPresets": {
    "primary": {
      "provider": "ollama",
      "model": "llama3.2",
      "maxTokens": 4096,
      "contextWindowTokens": 32768
    }
  },
  "agents": { "defaults": { "modelPreset": "primary" } }
}

# Fallback chains use preset names, not model IDs: context is sized for the smallest window in the chain
# "agents": { "defaults": { "modelPreset": "primary", "fallbackModels": ["localSmall"] } }

Verifica la configurazione e invia un primo messaggio

La documentazione è esplicita: non aggiungere app di chat, server MCP, fallback o un servizio finché questo non funziona.

# Check the setup without calling a model
nanobot status

# First one-shot message (since v0.3.5 a bare `nanobot` opens the terminal UI instead)
nanobot -m "Hello!"

5. Passo 3: Collega i canali di messaggistica

La documentazione delle app di chat di nanobot copre Telegram, Discord, Slack, WhatsApp, WeChat, WeCom, Feishu/Lark, DingTalk, QQ, Matrix, Email, Mattermost, Linear, Microsoft Teams, Signal e Mochat, oltre alla WebUI integrata, all'interfaccia da terminale e a un'API compatibile OpenAI (nanobot serve). iMessage non è supportato. Le dipendenze dei canali sono funzionalità opzionali: abilitale con nanobot plugins enable <channel> prima di attivare il canale nella configurazione. Telegram è il più rapido da far funzionare, long polling per impostazione predefinita, quindi nessuna porta in ingresso sul Mac mini. La guida Telegram consiglia la modalità solo pairing per la prima configurazione: ometti allowFrom e approva il tuo primo DM dalla CLI locale fidata:

# 1. In Telegram, open @BotFather, send /newbot and copy the token (format: 1234567890:AAF...)

# 2. Enable the optional Telegram feature in the same Python environment as nanobot
nanobot plugins enable telegram

# 3. Merge into ~/.nanobot/config.json: omit allowFrom to use pairing-only mode
{ "channels": { "telegram": { "enabled": true, "token": "1234567890:AAF..." } } }

# 4. The channel must be listed, then run the gateway in the foreground for a first test
nanobot channels status
nanobot gateway

# 5. DM your bot once: it answers with a pairing code. Approve it from a second SSH session:
nanobot agent -m "/pairing approve ABCD-EFGH"

# 6. Stop the foreground gateway with Ctrl+C before installing the service in Step 4

Collega Discord, Slack o WhatsApp

Discord richiede un token bot con il MESSAGE CONTENT INTENT abilitato nel Developer Portal; mantieni il groupPolicy predefinito mention così il bot risponde solo quando viene @menzionato. Slack usa il Socket Mode (un token bot più un token a livello app con connections:write) e non richiede alcun URL pubblico, ma i DM sono aperti per impostazione predefinita, imposta dm.policy su allowlist per ottenere i codici di pairing. WhatsApp si collega tramite codice QR ed è puro Python dalla v0.3.0 (nessun bridge Node.js); il suo database di sessione equivale all'accesso completo all'account, quindi mantieni ~/.nanobot/whatsapp-auth con permessi 0700 e usa un numero separato:

# Discord: bot token with MESSAGE CONTENT INTENT enabled in the Developer Portal
{ "channels": { "discord": { "enabled": true, "token": "YOUR_DISCORD_BOT_TOKEN",
    "groupPolicy": "mention", "allowChannels": [] } } }

# Slack, Socket Mode (xoxb bot token + xapp app-level token with connections:write), no public URL
nanobot plugins enable slack
{ "channels": { "slack": { "enabled": true, "botToken": "xoxb-...", "appToken": "xapp-...",
    "dm": { "policy": "allowlist" } } } }

# WhatsApp: the CLI prints a QR code; scan it from WhatsApp > Linked Devices
# (if the QR is not readable in your terminal, run the same command over VNC; our advice: use a separate number)
nanobot plugins enable whatsapp
nanobot channels login whatsapp
{ "channels": { "whatsapp": { "enabled": true, "allowFrom": ["33612345678"] } } }
chmod 700 ~/.nanobot/whatsapp-auth   # session DB = full account access

# Every channel: verify it is listed, then restart the gateway
nanobot channels status

Controllo degli accessi: allowFrom e pairing

Ogni canale che supporta i DM segue la stessa regola. Con allowFrom omesso, il primo DM restituisce un codice di pairing che approvi da una chat già approvata o dalla CLI. Una lista non vuota è una allowlist rigorosa: tutti gli altri vengono ignorati. Il wildcard aggira il pairing e permette a chiunque possa raggiungere il canale di parlare con il bot, la documentazione lo ammette solo intenzionalmente o temporaneamente in una sandbox privata, mai in produzione:

# channels.<name>.allowFrom semantics
#   omitted          → pairing-only mode: the first DM returns a code such as ABCD-EFGH
#   ["123456789"]    → static allowlist (your numeric Telegram/Discord ID), everyone else ignored
#   ["*"]            → anyone who can reach the channel: never in production

# Pairing management from the trusted local CLI
nanobot agent -m "/pairing approve ABCD-EFGH"
nanobot agent -m "/pairing deny ABCD-EFGH"
nanobot agent -m "/pairing revoke 123456789"

# Slack / Mattermost need "dm": { "policy": "allowlist" } to issue pairing codes;
# "dm": { "enabled": false } disables DMs where you do not need them

6. Passo 4: Metti in sicurezza, esegui 24/7 con launchd, aggiorna

Ferma il gateway in primo piano (Ctrl+C) prima di proseguire. nanobot documenta tre modi per mantenere attivo il gateway su macOS: un LaunchAgent che scrive da solo, un processo in background scollegato gestito dalla CLI, oppure un semplice processo in primo piano per i test. Per un Mac mini headless 24/7 usa il LaunchAgent, è l'unica opzione che launchd supervisiona e riavvia in caso di errore. Prima metti in sicurezza la configurazione.

Metti in sicurezza prima di rendere persistente

La raccomandazione ufficiale per la produzione è sia la protezione del workspace a livello applicativo sia la sandbox exec del sistema operativo, Seatbelt su macOS. Seatbelt confina i comandi shell dell'agente al workspace (lettura-scrittura), ai media (sola lettura) e ai percorsi di sistema necessari, maschera la directory di configurazione ~/.nanobot e punta HOME e TMPDIR al workspace. Non limita l'accesso alla rete, e restrictToWorkspace da solo non è una sandbox del sistema operativo. Se l'agente non ha affatto bisogno di una shell, rimuovi del tutto lo strumento. Mantieni inoltre tools.maxSessionMessagesPerMinute al valore predefinito di 6 e imposta un limite di spesa sul tuo provider LLM:

# Official production recommendation on macOS: merge into ~/.nanobot/config.json
{
  "tools": {
    "restrictToWorkspace": true,
    "exec": { "sandbox": "seatbelt" }
  }
}

# Agent does not need a shell? Remove the tool entirely instead:
# { "tools": { "exec": { "enable": false } } }

# Seatbelt sets HOME and TMPDIR to the workspace and masks ~/.nanobot. Scripts that need
# extra paths get them via tools.exec.sandboxRoBinds / sandboxRwBinds (use sparingly).
# Neither Seatbelt nor bwrap restricts network access.

# Keep WebUI / API on localhost (defaults: WebUI 127.0.0.1:8765, health 127.0.0.1:18790, serve 127.0.0.1:8900)
# and leave tools.webuiAllowRemotePackageInstall = false and tools.ssrfWhitelist = []

Installa il LaunchAgent

nanobot gateway install-service scrive ~/Library/LaunchAgents/ai.nanobot.gateway.plist, che esegue python -m nanobot gateway --foreground con il tuo Python attuale, si avvia al caricamento (RunAtLoad), si riavvia in caso di crash (KeepAlive con SuccessfulExit false) e registra i log in ~/.nanobot/logs/. Fallisce con address already in use se un gateway manuale è ancora in esecuzione, quindi fermalo prima e fai un'anteprima con --dry-run:

# Stop any manually started gateway first (otherwise: "address already in use")
nanobot gateway stop

# Preview the plist, then install it
nanobot gateway install-service --manager launchd --dry-run
nanobot gateway install-service --manager launchd
# Writes ~/Library/LaunchAgents/ai.nanobot.gateway.plist
# Runs: python -m nanobot gateway --foreground  (RunAtLoad, KeepAlive on failure)
# Logs: ~/.nanobot/logs/

Gestisci il servizio

Il LaunchAgent vive nel dominio gui del tuo utente, quindi viene eseguito una volta che esiste la sessione di login di quell'utente, la documentazione lo descrive come un servizio che resta online dopo il tuo login. Dopo un riavvio di un Mac mini headless torna attivo solo se il tuo utente effettua il login automaticamente; fai un test di riavvio una volta e verifica con launchctl list. Riavvialo dopo ogni modifica a config.json:

# Is it loaded?
launchctl list | grep ai.nanobot.gateway

# Restart after every config.json edit (config is read at startup only)
launchctl kickstart -k gui/$(id -u)/ai.nanobot.gateway

# Remove the service
nanobot gateway uninstall-service --manager launchd

# Second, isolated instance on the same Mac (own config, workspace, port and LaunchAgent).
# docs/multiple-instances.md: "Each instance must use a different port if they run at the same time"
# nanobot onboard --config ~/.nanobot-telegram/config.json --workspace ~/.nanobot-telegram/workspace
# Merge into ~/.nanobot-telegram/config.json (default gateway port is 18790; change the WebSocket
# channel port too if that instance also enables the WebUI, default 8765):
# { "gateway": { "host": "127.0.0.1", "port": 18792 },
#   "channels": { "websocket": { "port": 8766 } } }
# nanobot gateway install-service --manager launchd --name nanobot-telegram \
#   --config ~/.nanobot-telegram/config.json --workspace ~/.nanobot-telegram/workspace
# (for a one-off foreground run instead: nanobot gateway --config ~/.nanobot-telegram/config.json --port 18792)

Alternativa più leggera: nanobot gateway --background

Il README lo definisce l'unico comando che promuove il gateway condiviso alla modalità background persistente. È comodo per i test ma non è supervisionato dal sistema operativo, quindi non torna attivo da solo dopo un riavvio, non mischiarlo con il LaunchAgent:

nanobot gateway --background
nanobot gateway status
nanobot gateway logs
nanobot gateway restart
nanobot gateway stop

Aggiorna nanobot

Non esiste un comando nanobot update: aggiorna con lo stesso metodo che hai usato per installare. Il progetto ti chiede di controllare gli aggiornamenti ogni settimana e ha pubblicato cinque avvisi di sicurezza nel 2026, quindi aggiorna tempestivamente. Leggi prima le note di rilascio, la v0.3.5 ha spostato i file di sessione in sessions/<workspace-id>/ e ti dice di fare un backup di configurazione, workspace e archivio delle sessioni e di fermare prima i vecchi processi. Quindi ferma il gateway (disinstalla il LaunchAgent, oppure nanobot gateway stop in modalità background), fai il backup, aggiorna, poi riavvialo, non lasciare mai che due versioni scrivano contemporaneamente sullo stesso workspace:

# 1. Stop the old gateway first (v0.3.5 release notes: never let two versions write the same workspace)
nanobot gateway uninstall-service --manager launchd   # LaunchAgent (nanobot documents no plain launchd stop)
# nanobot gateway stop                                  # --background mode

# 2. Back up config, workspace and sessions
cp -R ~/.nanobot ~/nanobot-backup-$(date +%F)

# 3. Upgrade with the same method you installed with
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh
# or: uv tool upgrade nanobot-ai
# or: pipx upgrade nanobot-ai
# or: python3 -m pip install -U nanobot-ai

nanobot --version
nanobot onboard --refresh      # merge new default config fields, keep your values

# 4. Start again so the new code and config are loaded
nanobot gateway install-service --manager launchd     # LaunchAgent: reinstall (RunAtLoad starts it)
# nanobot gateway --background                          # --background mode

7. Risoluzione dei problemi comuni

# Python too old? Point the installer at a 3.11+ interpreter
python3 --version
PYTHON=/path/to/python3.12 sh -c "$(curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh)"

# "externally-managed-environment" → isolated install, never --break-system-packages
uv tool install nanobot-ai
# or: pipx install nanobot-ai

# "curl: command not found" → skip the script
uv tool install nanobot-ai

# `nanobot` not on PATH in a new shell
uv tool run --from nanobot-ai nanobot --version
pipx run --spec nanobot-ai nanobot --version
~/.nanobot/venv/bin/python -m nanobot --version
export PATH="$HOME/.local/bin:$PATH"

# Validate without spending tokens
nanobot status

# Provider and model must match in the preset: provider "anthropic" ↔ "claude-opus-4-5",
# provider "openai" ↔ "gpt-5", provider "openrouter" ↔ "anthropic/claude-opus-4.5", provider "ollama" ↔ "llama3.2"

# ConfigLoadError at startup = a ${VAR} placeholder is unset in the starting process' environment
# (the generated LaunchAgent passes no environment → store the key in config.json + chmod 600)

# Watch the gateway with verbose logging (also verifies MCP servers)
nanobot gateway --verbose

# Is the channel enabled and listed?
nanobot plugins enable telegram
nanobot channels status

# Pending pairing? Approve it from the CLI
nanobot agent -m "/pairing approve ABCD-EFGH"

# Edited config.json? Restart the gateway
launchctl kickstart -k gui/$(id -u)/ai.nanobot.gateway
# or: nanobot gateway restart

# Token revoked? Generate a new one via @BotFather (/mybots > API Token) and update config.json
# WhatsApp "login expired"? nanobot channels login whatsapp

# "address already in use" → a manual gateway still holds the port
nanobot gateway stop
nanobot gateway install-service --manager launchd

# Loaded? Logs?
launchctl list | grep ai.nanobot.gateway
ls ~/.nanobot/logs/

# Gone after a reboot: a gui-domain LaunchAgent starts once your user has logged in.
# If your setup allows automatic login for the nanobot user, enable it and reboot-test;
# WARNING: auto-login trades console-login security for reboot survival, confirm with your ops policy first.

# Ports: WebUI 8765 (localhost), health endpoint 18790, `nanobot serve` API 8900
# Generic SSH tip (not a nanobot feature): reach the localhost WebUI from your laptop
# ssh -N -L 8765:127.0.0.1:8765 admin@your-server-ip   → http://127.0.0.1:8765

8. Analisi dei costi vs. VPS cloud

nanobot in sé è gratuito (MIT). Ciò che paghi è l'host e l'utilizzo dell'LLM. Il confronto degli host qui sotto riutilizza le fasce di prezzo dei VPS cloud delle nostre guide OpenClaw e Hermes; l'utilizzo dell'API LLM è fatturato separatamente dal tuo provider ed è identico su entrambi gli host, a meno che tu non esegua un modello Ollama locale sul Mac mini, nel qual caso l'inferenza costa $0. nanobot non pubblica cifre sull'impronta di RAM o CPU (si descrive solo come ultraleggero), quindi il dimensionamento dei piani qui sotto è qualitativo.

Ipotesi: i prezzi dei VPS sono le stesse fasce usate in tutte le nostre guide per istanze tier AI con GPU e non sono preventivi di un provider specifico; i prezzi MyRemoteMac sono le tariffe mensili attuali in USD (1 Gbps inclusi, Mac mini M6 disponibile dal 22 settembre 2026). La distinzione M4/M6 è una raccomandazione, non un requisito misurato: un Mac mini M4 è più che sufficiente per un bot personale su provider hosted; scegli l'M6 quando la stessa macchina serve anche un modello Ollama locale o più istanze nanobot.

9. nanobot vs. OpenClaw

Entrambi sono agenti AI personali open source (MIT), self-hosted e always-on pilotati dalle tue app di chat, entrambi eseguono un gateway persistente ed entrambi registrano il proprio LaunchAgent launchd (ai.nanobot.gateway vs ai.openclaw.gateway). Il README di nanobot definisce persino nanobot gateway il punto di ingresso familiare se arrivi da OpenClaw. Le differenze stanno nello stack e nella proposta. OpenClaw è TypeScript su Node.js (26.1+ o 24.16+ via Homebrew) installato con npm; nanobot è Python 3.11+ da PyPI (nanobot-ai), installato con uno script in una riga, uv o pipx, senza alcun Node.js. La proposta di OpenClaw è l'ampiezza e la community più grande; quella di nanobot è un core piccolo e leggibile, il pairing per canale più una sandbox exec Seatbelt di macOS integrata (novità della v0.3.5), più istanze isolate su un solo Mac (multiple-instances.md) e un SDK Python più un'API compatibile OpenAI. OpenClaw supporta iMessage; nanobot no.

Se vuoi l'assistente più completo, con la community e l'elenco di canali più grandi, leggi la nostra guida a OpenClaw su Mac mini. Se vuoi un agente Python leggero che puoi leggere da cima a fondo, più istanze in sandbox, oppure Ollama sullo stesso Mac mini, nanobot è la scelta migliore. Una terza opzione, Hermes Agent, è trattata nella nostra guida a Hermes su Mac mini. Il Mac mini, il servizio launchd e l'opzione Ollama locale sono gli stessi per tutti e tre.

10. FAQ

11. Fonti e approfondimenti

Ogni comando, percorso e chiave di configurazione di questa guida proviene dal repository ufficiale di nanobot (README e albero docs/, letti il 28 settembre 2026, v0.3.5) e dal suo SECURITY.md. La documentazione del repository può essere più recente dell'ultima release del pacchetto, quindi ricontrolla sul repository se un comando si comporta diversamente.

• Repository GitHub di nanobot (HKUDS/nanobot): Install e Quick Start
• Quick start (config.json, workspace, aggiornamento con lo stesso metodo)
• Deployment: LaunchAgent macOS (install-service, launchctl kickstart)
• Riferimento di configurazione (segreti, segnaposto ${VAR}, MCP, strumenti web)
• Configurazione: Sicurezza (restrictToWorkspace, sandbox Seatbelt, exec.enable)
• Provider (preset, catene di fallback, mismatch provider/modello)
• Provider: Ollama (apiBase /v1, tag del modello grezzo)
• App di chat (Telegram, Discord, Slack, WhatsApp, allowFrom, pairing)
• Guida: agente AI Telegram (modalità solo pairing, configurazione headless)
• Guida: agente AI locale sicuro (binding a localhost, un workspace per confine di fiducia)
• Riferimento CLI (onboard --wizard / --refresh, gateway, plugins, channels)
• WebUI (127.0.0.1:8765, tokenIssueSecret, accesso LAN)
• Automazioni (strumento cron, trigger locali, heartbeat)
• Più istanze su una sola macchina
• Risoluzione dei problemi (Python 3.11+, externally-managed-environment, porte)
• SECURITY.md (mai eseguire come root, chmod 600/700, limitazioni note)
• Avvisi di sicurezza (cinque pubblicati nel 2026)
• Release v0.3.5 (15 settembre 2026: layout delle sessioni, Seatbelt, durata del gateway)
• PyPI: nanobot-ai (richiede Python 3.11+, wheel macOS 13+)

Guide correlate