Comment faire tourner nanobot 24h/24 sur un Mac mini dédié (agent IA auto-hébergé)

1. Pourquoi faire tourner nanobot sur un Mac mini ?

nanobot est construit autour d'un processus gateway de longue durée : la documentation officielle demande de garder nanobot gateway en fonctionnement, car c'est lui qui assure la livraison en arrière-plan pour les messageries, les sujets de la WebUI, les automatisations planifiées, les déclencheurs locaux et le heartbeat. Cela ne fonctionne que sur une machine qui ne se met jamais en veille. Un Mac mini dédié chez MyRemoteMac vous offre exactement cela, un Mac Apple Silicon physique, rien qu'à vous, en ligne 24h/24 avec un SLA de 99,9 %, un accès root complet, SSH et VNC et un VPN WireGuard, pour un tarif mensuel fixe au lieu d'une facturation VPS de tier GPU. Et comme c'est macOS, nanobot peut utiliser sa sandbox exec Seatbelt intégrée (sandbox-exec, livré avec macOS) et faire tourner un modèle Ollama local sur la même machine.

2. Prérequis

nanobot est distribué sous forme de package PyPI nanobot-ai, avec des wheels de plateforme pour macOS 13+ sur Apple Silicon et Intel qui embarquent la WebUI et l'interface terminal native. Aucune dépendance à Node.js, Homebrew ou Git n'est requise pour le chemin d'installation standard. Voici ce dont vous avez besoin :

• Un Mac mini dédié chez MyRemoteMac, M4 dès 85 $/mois (16 Go / 256 Go) ou M6 dès 149 $/mois. Les deux sont Apple Silicon et couverts par la wheel macOS arm64.
• Un accès SSH à votre Mac mini (fourni avec votre abonnement MyRemoteMac) et un compte utilisateur standard, non root pour exécuter nanobot, le SECURITY.md du projet dit de ne jamais l'exécuter en root.
• Python 3.11 ou plus récent et curl. L'installateur en une commande s'interrompt s'il ne trouve qu'un python3 plus ancien ; uv ou pipx sont optionnels mais recommandés lorsque pip signale externally-managed-environment.
• Un fournisseur de LLM : une clé API (Anthropic, OpenAI, OpenRouter, Gemini, DeepSeek, Groq, Mistral et une quarantaine d'autres sont intégrés) ou un serveur local compatible OpenAI tel qu'Ollama tournant sur le même Mac mini.
• Un compte de messagerie sur Telegram, Discord, Slack ou WhatsApp pour joindre votre agent (Telegram est le plus rapide : un token de bot via @BotFather et aucun port entrant).

3. Étape 1 : Connexion en SSH et installation de nanobot

Connectez-vous en SSH à votre Mac mini avec les identifiants de votre tableau de bord MyRemoteMac. Exécutez chaque commande de ce guide en tant qu'utilisateur macOS normal, jamais en root : le LaunchAgent que vous installerez plus tard s'exécute dans la session de cet utilisateur.

Connexion en SSH et vérification de 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

Installation de nanobot

Le chemin par défaut du projet est un installateur en une commande qui installe ou met à jour nanobot-ai depuis PyPI en utilisant un environnement virtuel actif, uv, pipx ou un venv géré dans ~/.nanobot/venv, et affiche la commande exacte qu'il a utilisée. Comme SSH_CONNECTION est défini, il saute la WebUI du navigateur et lance à la place l'assistant terminal nanobot onboard --wizard. Prévisualisez-le d'abord avec --dry-run. Si vous préférez gérer l'installation vous-même, uv et pipx sont les alternatives documentées :

# 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

Vérification de l'installation

Si nanobot n'est pas dans votre PATH dans un nouveau shell, utilisez le lanceur affiché par l'installateur (uv tool run, pipx run ou le venv géré) ou ajoutez ~/.local/bin à votre 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. Étape 2 : Configuration d'un fournisseur de modèle (API ou Ollama local)

nanobot lit tout depuis ~/.nanobot/config.json (fournisseurs, presets de modèles, canaux, outils) et conserve la mémoire, les skills et les fichiers générés dans ~/.nanobot/workspace/. L'assistant terminal crée les deux. Les extraits de configuration de la documentation officielle utilisent des clés en camelCase et sont conçus pour être fusionnés dans le fichier, pas collés en bloc. Le fichier est lu une seule fois au démarrage : redémarrez donc la gateway après chaque modification.

Lancement de l'assistant terminal

# 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

Ajout d'un fournisseur et d'un preset de modèle

Un preset associe un fournisseur à un modèle. L'exemple de la documentation est Anthropic en direct avec claude-opus-4-5 ; l'échec le plus courant au premier lancement est de mélanger une clé API d'un fournisseur avec un identifiant de modèle d'un autre, donc épinglez toujours le fournisseur dans le preset. Les exemples officiels référencent la clé sous la forme ${ANTHROPIC_API_KEY}, résolue depuis l'environnement du processus qui démarre nanobot et jamais réécrite. Cela fonctionne pour les sessions au premier plan lancées depuis votre shell (l'héritage de l'environnement par le processus détaché --background n'est pas documenté), mais le LaunchAgent généré à l'Étape 4 ne transporte aucune variable d'environnement ; pour un déploiement launchd, stockez donc la clé dans config.json et verrouillez le fichier comme le décrit 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

Optionnel : utiliser un modèle local avec Ollama

nanobot dispose d'un fournisseur ollama dédié. Démarrez Ollama séparément sur le Mac mini (voir notre guide LLM sur Mac mini), puis pointez le fournisseur vers http://localhost:11434/v1, le nom du modèle est le tag Ollama brut, sans préfixe, et la plupart des installations Ollama n'ont pas besoin de clé API. Les chaînes de repli (fallback) référencent des noms de presets : vous pouvez donc garder un modèle frontière hébergé en principal et un preset local en repli (ou l'inverse) :

# 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"] } }

Vérification de la configuration et envoi d'un premier message

La documentation est explicite : n'ajoutez pas de messageries, de serveurs MCP, de fallbacks ni de service tant que ceci ne fonctionne pas.

# 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. Étape 3 : Connexion des canaux de messagerie

La documentation des messageries de nanobot couvre Telegram, Discord, Slack, WhatsApp, WeChat, WeCom, Feishu/Lark, DingTalk, QQ, Matrix, Email, Mattermost, Linear, Microsoft Teams, Signal et Mochat, plus la WebUI intégrée, l'interface terminal et une API compatible OpenAI (nanobot serve). iMessage n'est pas supporté. Les dépendances des canaux sont des fonctionnalités optionnelles : activez-les avec nanobot plugins enable <channel> avant d'activer le canal dans la configuration. Telegram est le plus rapide à mettre en place, long polling par défaut, donc aucun port entrant sur le Mac mini. Le guide Telegram recommande le mode appairage seul pour la première configuration : omettez allowFrom et approuvez votre premier message privé depuis la CLI locale de confiance :

# 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

Connexion de Discord, Slack ou WhatsApp

Discord nécessite un token de bot avec le MESSAGE CONTENT INTENT activé dans le Portail développeur ; conservez le groupPolicy par défaut mention pour que le bot ne réponde que lorsqu'il est @mentionné. Slack utilise le Socket Mode (un token de bot plus un token de niveau application avec connections:write) et ne nécessite aucune URL publique, mais les messages privés sont ouverts par défaut, réglez dm.policy sur allowlist pour obtenir des codes d'appairage. WhatsApp se relie via un QR code et est en pur Python depuis la v0.3.0 (plus de pont Node.js) ; sa base de données de session équivaut à un accès complet au compte, donc gardez ~/.nanobot/whatsapp-auth en mode 0700 et utilisez un numéro distinct :

# 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

Contrôle d'accès : allowFrom et appairage

Chaque canal capable de messages privés suit la même règle. Avec allowFrom omis, le premier message privé renvoie un code d'appairage que vous approuvez depuis une conversation déjà approuvée ou la CLI. Une liste non vide est une liste blanche stricte : tous les autres sont ignorés. Le joker (wildcard) contourne l'appairage et laisse quiconque peut atteindre le canal parler au bot, la documentation ne l'autorise qu'intentionnellement ou temporairement dans un bac à sable privé, jamais en production :

# 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. Étape 4 : Durcissement, exécution 24h/24 avec launchd, mise à jour

Arrêtez la gateway au premier plan (Ctrl+C) avant d'aller plus loin. nanobot documente trois façons de maintenir la gateway en vie sous macOS : un LaunchAgent qu'il écrit lui-même, un processus détaché en arrière-plan géré depuis la CLI, ou un simple processus au premier plan pour les tests. Pour un Mac mini headless 24h/24, utilisez le LaunchAgent, c'est la seule option que launchd supervise et redémarre en cas d'échec. Durcissez d'abord la configuration.

Durcir avant de passer en persistant

La recommandation de production officielle est d'utiliser à la fois la protection du workspace au niveau applicatif et la sandbox exec de l'OS, Seatbelt sous macOS. Seatbelt confine les commandes shell de l'agent au workspace (lecture-écriture), aux médias (lecture seule) et aux chemins système nécessaires, masque le répertoire de configuration ~/.nanobot et pointe HOME et TMPDIR vers le workspace. Elle ne restreint pas l'accès réseau, et restrictToWorkspace seul n'est pas une sandbox OS. Si l'agent n'a pas du tout besoin d'un shell, retirez l'outil entièrement. Conservez aussi tools.maxSessionMessagesPerMinute à sa valeur par défaut de 6 et définissez un plafond de dépenses chez votre fournisseur de 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 = []

Installation du LaunchAgent

nanobot gateway install-service écrit ~/Library/LaunchAgents/ai.nanobot.gateway.plist, qui exécute python -m nanobot gateway --foreground avec votre Python actuel, démarre au chargement (RunAtLoad), redémarre en cas de crash (KeepAlive avec SuccessfulExit à false) et journalise dans ~/.nanobot/logs/. Il échoue avec address already in use si une gateway manuelle tourne encore : arrêtez-la d'abord et prévisualisez avec --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/

Gestion du service

Le LaunchAgent vit dans le domaine gui de votre utilisateur : il s'exécute donc dès que la session de connexion de cet utilisateur existe, la documentation le décrit comme restant en ligne après votre connexion. Après un redémarrage d'un Mac mini headless, il ne revient que si votre utilisateur se connecte automatiquement ; testez un redémarrage une fois et vérifiez avec launchctl list. Redémarrez-le après chaque modification de 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)

Alternative plus légère : nanobot gateway --background

Le README la présente comme la seule commande qui promeut la gateway partagée en mode arrière-plan persistant. Elle est pratique pour les tests mais n'est pas supervisée par l'OS : elle ne revient donc pas d'elle-même après un redémarrage, ne la mélangez pas avec le LaunchAgent :

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

Mise à jour de nanobot

Il n'existe pas de commande nanobot update : mettez à jour avec la même méthode que celle utilisée à l'installation. Le projet vous demande de vérifier les mises à jour chaque semaine et a publié cinq avis de sécurité en 2026, donc mettez à jour rapidement. Lisez d'abord les notes de version, la v0.3.5 a déplacé les fichiers de session vers sessions/<workspace-id>/ et vous demande de sauvegarder la configuration, les workspaces et le stockage des sessions, et d'arrêter d'abord les anciens processus. Arrêtez donc la gateway (désinstallez le LaunchAgent, ou nanobot gateway stop en mode arrière-plan), sauvegardez, mettez à jour, puis redémarrez-la, ne laissez jamais deux versions écrire simultanément dans le même 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. Résolution des problèmes courants

# 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. Analyse des coûts vs VPS cloud

nanobot lui-même est gratuit (MIT). Ce que vous payez, c'est l'hôte et la consommation de LLM. La comparaison d'hôtes ci-dessous reprend les fourchettes de VPS cloud de nos guides OpenClaw et Hermes ; la consommation d'API LLM est facturée séparément par votre fournisseur et est identique sur l'un ou l'autre hôte, sauf si vous faites tourner un modèle Ollama local sur le Mac mini, auquel cas l'inférence coûte 0 $. nanobot ne publie aucun chiffre d'empreinte RAM ou CPU (il se décrit seulement comme ultra-léger), le dimensionnement des plans ci-dessous est donc qualitatif.

Hypothèses : les prix des VPS sont les mêmes fourchettes utilisées dans l'ensemble de nos guides pour des instances de tier IA avec GPU et ne sont pas des devis d'un fournisseur précis ; les prix MyRemoteMac sont les tarifs mensuels actuels en USD (1 Gbps inclus, Mac mini M6 disponible depuis le 22 septembre 2026). La répartition M4/M6 est une recommandation, pas une exigence mesurée : un Mac mini M4 suffit largement pour un bot personnel sur des fournisseurs hébergés ; choisissez le M6 lorsque la même machine sert aussi un modèle Ollama local ou plusieurs instances nanobot.

9. nanobot vs OpenClaw

Les deux sont des agents IA personnels open source (MIT), auto-hébergés et toujours allumés, pilotés depuis vos messageries ; les deux font tourner une gateway de longue durée et les deux enregistrent leur propre LaunchAgent launchd (ai.nanobot.gateway vs ai.openclaw.gateway). Le README de nanobot qualifie même nanobot gateway de point d'entrée familier si vous venez d'OpenClaw. Les différences se situent dans la pile technique et le positionnement. OpenClaw est en TypeScript sur Node.js (26.1+ ou 24.16+ via Homebrew) installé avec npm ; nanobot est en Python 3.11+ depuis PyPI (nanobot-ai), installé avec un script en une ligne, uv ou pipx, sans aucun Node.js. Le positionnement d'OpenClaw, c'est l'étendue fonctionnelle et la communauté plus large ; celui de nanobot, c'est un cœur petit et lisible, l'appairage par canal plus une sandbox exec Seatbelt macOS intégrée (nouveauté de la v0.3.5), plusieurs instances isolées sur un même Mac (multiple-instances.md) et un SDK Python plus une API compatible OpenAI. OpenClaw supporte iMessage ; nanobot non.

Si vous voulez l'assistant le plus complet, la communauté et la liste de canaux les plus larges, lisez notre guide OpenClaw sur Mac mini. Si vous voulez un agent Python léger que vous pouvez lire de bout en bout, plusieurs instances en sandbox, ou Ollama sur le même Mac mini, nanobot est le meilleur choix. Une troisième option, Hermes Agent, est couverte dans notre guide Hermes sur Mac mini. Le Mac mini, le service launchd et l'option Ollama local sont les mêmes pour les trois.

10. FAQ

11. Sources et lectures complémentaires

Chaque commande, chemin et clé de configuration de ce guide provient du dépôt officiel nanobot (README et arborescence docs/, consultés le 28 septembre 2026, v0.3.5) et de son SECURITY.md. La documentation du dépôt peut être plus récente que la dernière version publiée du package : revérifiez donc auprès du dépôt si une commande se comporte différemment.

• Dépôt GitHub nanobot (HKUDS/nanobot) : Installation et démarrage rapide
• Démarrage rapide (config.json, workspace, mise à jour avec la même méthode)
• Déploiement : LaunchAgent macOS (install-service, launchctl kickstart)
• Référence de configuration (secrets, placeholders ${VAR}, MCP, outils web)
• Configuration : Sécurité (restrictToWorkspace, sandbox Seatbelt, exec.enable)
• Fournisseurs (presets, chaînes de repli, décalage fournisseur/modèle)
• Fournisseurs : Ollama (apiBase /v1, tag de modèle brut)
• Messageries (Telegram, Discord, Slack, WhatsApp, allowFrom, appairage)
• Guide : agent IA Telegram (mode appairage seul, configuration headless)
• Guide : agent IA local sécurisé (liaison localhost, un workspace par périmètre de confiance)
• Référence CLI (onboard --wizard / --refresh, gateway, plugins, channels)
• WebUI (127.0.0.1:8765, tokenIssueSecret, accès LAN)
• Automatisations (outil cron, déclencheurs locaux, heartbeat)
• Plusieurs instances sur une même machine
• Dépannage (Python 3.11+, externally-managed-environment, ports)
• SECURITY.md (jamais en root, chmod 600/700, limitations connues)
• Avis de sécurité (cinq publiés en 2026)
• Version v0.3.5 (15 septembre 2026 : organisation des sessions, Seatbelt, durée de vie de la gateway)
• PyPI : nanobot-ai (nécessite Python 3.11+, wheels macOS 13+)

Guides associés