micro/mu: A Single Go Binary That Runs Your Agent, Mail Server and Inbox

The problem Mu targets: how much of the stack you actually own

The README frames the question directly: how much of the system can you run yourself. It lists the services, the tools, the APIs, and concedes the models may be out of reach, then says Mu attempts everything else in a single binary on one machine in one place in one system. That is a narrower pitch than a general agent framework. It is a consolidation pitch. The stated scope covers a personal assistant, a launch pad, a unified inbox, clients over web, SMS and email, services as building blocks, and self-hosted SMTP, XMPP, SFTP and SSH. Read the topic list and the intended audience becomes clearer: email, smtp, xmpp, mcp, agent. This is for someone who already thinks in terms of running their own mail and chat, not someone shopping for a chat UI. The trade is explicit. You get fewer moving parts and one place to look, and you accept that one binary is now the thing standing between you and your inbound mail.

What the single binary actually contains, and how data flows

The architecture described is flat rather than layered. Mu is the runtime. Micro is the first agent and the default one. Services sit underneath as building blocks: mail, chat, news, video, search, markets, weather. Data gets archived locally, which the README says keeps it searchable and turns it into contextual memory. Then the loop closes: services and the archive become tools for Micro and for any agent you create. The stated benefit is that Micro can answer from what is true now rather than only from what a model remembers, and the examples given are this morning's news, this minute's price, your own mail. Agents you write are the same shape as Micro: a name, an instruction, and the tools they may reach. Each gets an address, so agent+yours@ reaches it from anywhere that can send mail, the same way agent@ reaches Micro. That address-per-agent design is the most distinctive part of the model. It means the mail server is not a separate integration you bolt on later; it is the transport for agent invocation.

Install path, and the default that points at micro.mu

The quick install is a shell script and a flag: curl -fsSL https://raw.githubusercontent.com/micro/mu/main/install.sh | sh, then mu --serve, then open http://localhost:8080. The first account you create is the admin. The README itself says to let them know if the guide is broken, which is a fair signal about how much operational polish to expect. The setup command, mu setup, walks through picking an AI provider and pasting a key. Keys are read from the environment: ANTHROPIC_API_KEY, ATLASCLOUD_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY, or OPENAI_BASE_URL, with Ollama named as the local option that costs nothing. Web search reads BRAVE_API_KEY and video reads YOUTUBE_API_KEY. Everything else, mail, Google sign-in, Stripe, is described as optional. The part worth reading twice: the binary is a client and by default calls https://micro.mu, the hosted instance. The README states plainly that without pointing it elsewhere, mu news list on the machine you just installed calls the hosted instance rather than the one you are running. mu login https://your.host saves the address and a token, MU_URL and --url override per shell and per command, and mu config get reports which instance is in use and why. Docker and from-source paths exist: git clone then docker compose up, or git clone then go install. The Docker Compose file and install script are in the repository; this review has not executed either.

The CLI and HTTP API share one catalogue

Every service is a mu subcommand, and every tool is a command made of the service then the method. The README notes that mu news list and mu news_list are the same call, so the underscore form is not a separate surface. Examples given include mu news search "ai safety", mu web search, mu markets list --category stocks, mu weather forecast --lat 51.5 --lon -0.12, mu docs list --collection notes, and mu x402 for per-call payment configuration. Authentication has three routes: mu login opens /token in a browser for a PAT you paste back, mu config set token xxx sets it directly, or MU_TOKEN carries it in the environment. The README says mu --help reads the same catalogue the agent does, which is the design point worth noting: the CLI is not a thin wrapper maintained separately from the agent's tool list. The HTTP side mirrors this at /api/v1/<service>/<method>, with arguments in the query string or a JSON body, Bearer tokens or an OAuth client, and /mcp for tools over MCP. A priced endpoint returns 402 without a token, which the README says an x402 client pays per call with no account at all. That is an unusual arrangement: anonymous, metered access to the same endpoints that authenticated users reach.

mu ask and mu agent run in opposite directions

The README flags a naming trap and it is worth repeating because it changes what you need installed. mu ask sends the request to the instance. It needs your token and no model key of your own. Examples are mu ask "what is in my inbox?" and mu ask --agent research "anything new this week?". mu agent is the reverse: it runs the agent here, on your machine, with your own model key, renting tools from an instance over x402 and paying per call. Same word in English, opposite ways round. If you skim the docs and reach for the wrong one, you will either be paying per call for something your instance would have answered, or wondering why a local run is asking for a token. The distinction also defines two deployment shapes. In the first, Mu is your server and your CLI is a remote control. In the second, Mu is a tool vendor and your machine does the reasoning, which is the configuration where the AGPL-3.0 licence on the server side matters less to you.

Embedded files mean editing some config requires a rebuild

Configuration splits in two, and the split is not cosmetic. A set of files is embedded in the binary, so the README says editing means rebuilding: home/cards.json for home screen cards, service/news/feeds.json for RSS feeds, service/chat/prompts.json for chat topics, service/video/channels.json for YouTube channels, and service/places/locations.json for saved locations. The rest lives in /admin/config on the server. For a runtime whose whole argument is that you run it yourself, hardcoding the news feed list and the saved locations into the compiled artifact is a real constraint. Changing which RSS feeds your agent reads is not a config edit, it is a build. There is a mitigation in the same paragraph: docs/INSTALL.md is named as the reference for every setting the code reads, so the embedded list is at least documented rather than implied. Still, if your deployment is a container built from a tagged release, plan for how a feed change gets from a JSON file into a running process. The README does not describe that workflow, and this review cannot confirm one exists.

Where Mu is the wrong tool, and what to compare it against

Mu is the wrong tool if you want an assistant that is someone else's operational problem. The moment you run mu --serve you own the SMTP listener, the XMPP endpoint, the archive, and the upgrade path. The README's own framing supports that reading: it asks how much of the system you can run yourself and answers with a single binary, which is a commitment, not a convenience. It is also the wrong tool if you want to change agent behaviour without a build, given the embedded JSON files above, or if AGPL-3.0 is incompatible with how you ship software. On alternatives, the honest comparison is not another agent runtime but the assembled stack: a hosted assistant plus a separate mail server plus a separate search API. That arrangement gives you independent upgrade cycles and lets you swap one piece without touching the others. Mu's difference in approach is that the archive and the services become the agent's tools by construction, so mail, news and markets are not integrations you write but capabilities the runtime already has, reachable at the same address your agent answers on. The cost of that integration is that the pieces move together. You cannot upgrade the mail handling without considering the agent, because they are the same process. The README does not describe a plugin boundary or a stable internal API for replacing one service, and nothing in the supplied material suggests one exists.

Maintenance, release cadence and the AGPL-3.0 boundary

The release history shows v1.8.0, v1.7.4 and v1.7.3 within a few days of each other in September 2026, with the last push to main on the same day as v1.8.0. That is a fast cadence, and for a self-hosted binary that terminates your inbound mail, fast releases mean you should decide early whether you track main, track tags, or pin. The README does not describe a migration process between versions, a compatibility policy for the /api/v1 surface, or a rollback path, and this review cannot confirm any of those exist. On licensing: the repository is AGPL-3.0. The practical consequence to check before you build on it is the network clause, which is why the licence matters more for the mu ask deployment shape (where users reach your modified Mu over a network) than for the mu agent shape (where the binary runs locally against someone else's instance). That is a description of the licence's structure, not legal advice; if you plan to modify and expose Mu, have someone qualified read the terms against your distribution model.

Editorial conclusion

Adopt Mu if you already run your own mail or chat infrastructure and want an agent that draws on live services and a local archive rather than a model's memory, and if AGPL-3.0 fits how you distribute whatever you build on it. Do not adopt it if you want a hosted assistant with no operational surface, or if you cannot accept that the binary defaults to micro.mu until you run mu login against your own host. Before committing, verify three things: run mu config get after mu login to confirm which instance your CLI is actually calling, check docs/INSTALL.md for the full list of settings the code reads, and confirm whether the files you need to change (home/cards.json, service/news/feeds.json, service/chat/prompts.json, service/video/channels.json, service/places/locations.json) being embedded means a rebuild in your deployment.

Official sources

1. Issues
2. License: AGPL-3.0
3. micro/mu on GitHub
4. README
5. Releases