Most "personal AI" products want you inside their chat window, on their cloud, with their memory of your files. nanobot flips that: a small Python agent you run yourself, talk to from a browser or Telegram, and point at whatever model you already pay for (or host locally).
It is from HKUDS, MIT licensed, and has taken off hard on GitHub (tens of thousands of stars in a short stretch). The pitch is not another mega-framework. It is a self-hosted personal agent with a WebUI, tools, memory, MCP, chat channels, and enough automation to stay useful after the demo day.
What nanobot actually is
Think of it as an agent gateway you own. You install the nanobot-ai package (Python 3.11+), wire a model provider or a local OpenAI-compatible server, and start working from the bundled WebUI, a terminal UI, or a chat app.
Out of the box it can:
- Chat in the browser or CLI, with session history that sticks around
- Connect Telegram, Discord, Slack, Mattermost, email, WeChat/Feishu, Linear, and similar channels
- Read common office files (PDF, Word, Excel, PowerPoint) for summarising and Q&A
- Use shell, web fetch/search, cron-style automations, image generation hooks, and MCP servers
- Keep longer-term preferences through its Dream memory flow
- Expose a Python SDK and an OpenAI-compatible Agent API for your own apps
Docs live at nanobot.wiki. There is also a "start without a technical background" path if the terminal is new to you, plus a serious deployment guide once you want it always on.
Why people self-host this instead of a SaaS agent
Your workspace stays yours. Config, sessions, memory, and generated artifacts sit under a directory you control (typically ~/.nanobot). That matters when the agent can see files, run tools, or sit in a company Slack.
Model choice. nanobot does not ship a model. You bring Anthropic, another OpenAI-compatible API, or a local LLM server. Swap providers, set fallbacks, keep inference where your budget and privacy rules allow.
Chat where the team already is. A private Telegram or Mattermost bot that can summarise a PDF and schedule a follow-up beats yet another web tab nobody opens after onboarding.
Readable core. The project leans on being small enough to inspect. If you care about MCP, cron, and channel auth, you can actually find those knobs instead of hunting through a proprietary admin panel.
Who it fits (and who should wait)
Good fit: solo operators and small teams who want a persistent agent on a VPS; folks already running Ollama or another local API and tired of paste-only chat UIs; Canadian shops that need prompts, uploads, and bot tokens on infrastructure they can point at in a PIPEDA conversation.
Maybe wait: if you only need a shared ChatGPT-style UI over Ollama, something like Open WebUI is simpler. nanobot is heavier on agent behaviour (tools, channels, automations). Also plan time for secrets, allowlists, and channel pairing before you expose anything to the public internet.
What running it takes
Quick path on a workstation: the official install script (or uv tool install nanobot-ai / pip in a venv), then nanobot webui or the onboard wizard. Prove a reply with nanobot agent -m "Hello!" before you turn it into a service.
On a server, Docker Compose from the repo is the repeatable option. Official usage means building their Dockerfile; third-party Hub images are not maintained by the project. Bind-mount the host config dir to /home/nanobot/.nanobot so sessions and memory survive restarts. Default compose limits are modest (around 1 CPU / 1G RAM per service), which matches the "ultra-lightweight" claim for the agent process itself. The model server, if local, is the part that eats RAM or GPU.
Security notes from their own docs are worth taking literally:
- Keep API keys and bot tokens in env vars or locked-down config, not world-readable files
- Use channel allowlists / pairing before inviting a bot into a busy workspace
- Gateway health defaults to loopback; if you bind WebUI/WebSocket to
0.0.0.0, set a strong token (or trusted-proxy auth) or it will refuse to start - Put TLS and access control in front of any public hostname
systemd user units and macOS LaunchAgents exist if you prefer bare metal over Compose. There is even a Render blueprint, but a Canadian VPS with Docker keeps the data story cleaner for many of our clients.
Hosting it in Canada
nanobot is a natural fit for a small Docker VPS in a Canadian data centre: persistent volume for ~/.nanobot, reverse proxy with HTTPS, firewall so only 443 (and maybe SSH) faces the world. Run a local model on a bigger box if you need it; or keep nanobot thin and call a cloud API while still owning the agent workspace, chat bridges, and logs.
Back up the config directory like you would any app with secrets and memory. Updates are frequent; test on a copy of the workspace before you yank production forward.
Bottom line
nanobot is for people who want a personal AI agent they can actually host: WebUI, chat apps, tools, memory, MCP, without renting the whole stack from a vendor. It is still young and moving fast, so treat production like any agent with shell access: lock down channels, rotate tokens, and do not give it more filesystem power than you mean to.
Want help standing up nanobot (or a local model next to it) on Canadian infrastructure? Talk with Swift Host. We will size the VPS for the agent and the model separately, not pretend one tiny plan covers both.
