Memoh: A self-hosted multi-agent platform that gives each bot its own cloud computer

What Memoh actually does

Memoh solves a specific problem: running multiple AI agents that each need their own persistent environment. Instead of sharing a single shell or API session, every agent gets a dedicated cloud computer with its own filesystem, desktop, browser, and network. This matters for agents that must keep state across sessions, browse the web, or run GUI workflows without interfering with each other. The intended users are individuals who want a personal agent, teams that assign one agent per member, or operators who want to run a fleet of agents on a single machine. The README positions it as a platform, not a single bot. It is not a chatbot framework; it is an infrastructure layer that hosts agents and connects them to chat channels.

The architecture: workspaces, channels, and the split-process option

The repository layout and deployment instructions reveal the core mechanism. The full stack runs a Server and a Channel as separate services when you set an internal RPC shared secret. The secret, stored in config.toml under internal_rpc.shared_secret, enables a two-process deployment where the server and the channel runtime communicate over RPC. If you leave that secret empty, the server embeds the channel runtime and runs as a single all-in-one process, including external channels, email, and webhook endpoints. This is a deliberate trade-off: the split mode isolates the channel layer, but the all-in-one mode is simpler for bare-metal installs. Each agent workspace is isolated, which is the key design choice. The README does not detail how isolation is enforced under the hood, so you should assume it relies on container or VM boundaries, but the exact mechanism is not documented in the material.

Getting it running: one-liner and manual Docker steps

The fastest path is the installer script: curl -fsSL https://memoh.sh | sh. For a manual deployment, the README gives a concrete sequence. First clone with submodules: git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/memohai/Memoh.git. Then copy the sample config: cp conf/app.docker.toml config.toml. You must edit config.toml and generate a shared secret with export MEMOH_INTERNAL_RPC_SHARED_SECRET="$(openssl rand -hex 32)". Finally run docker compose up -d. The installer supports a China mirror via USE_CN_MIRROR=true. The README warns not to run the installer with sudo; it will use sudo docker internally if needed. This is a practical detail for users behind restrictive Docker permissions.

Hosting external agents: ACP support for Claude Code and Codex

One distinctive feature is Agent Hosting via ACP (Agent Client Protocol, though the README does not spell out the acronym). You can host external agents inside Memoh workspaces, with Claude Code and Codex listed as current examples. This is configured per bot, meaning each bot can have its own external agent instance. This is different from Memoh's built-in agent, which uses your own API keys. The value is that you can keep using tools you already know while gaining Memoh's workspace isolation, memory, and channel integration. The README does not explain how ACP is implemented or what limitations exist, so you should verify the protocol version and compatibility with the specific agent versions you plan to host.

Memory and channels: the integration surface

Memoh claims built-in long-term memory across sessions and platforms, out of the box. It also supports Mem0 and OpenViking as external memory providers. The built-in memory is a differentiator: agents remember context even when you switch from Telegram to Discord, for example. The channel list includes Telegram, Discord, Lark, WeChat, QQ, Email, and more, though the README does not enumerate all ten. Each bot manages its own MCP connections, which means you can attach external tool servers per bot. This is a strong feature for teams that need different tools for different agents. However, the README does not describe how memory is stored, indexed, or retrieved, so you cannot assess quality from this material alone.

Automation and skills: scheduled tasks and modular extensions

The platform includes Automation for scheduled tasks, which is a recurring workflow trigger. Skills are modular and can be installed from a Supermarket, a curated template repository. The README also mentions delegating to sub-agents, which implies a hierarchy where a main agent can spawn smaller agents for specific tasks. The Supermarket is a separate repository (github.com/memohai/supermarket). This is a plugin-like system, but the README does not explain how skills are packaged, versioned, or sandboxed. Given that skills can teach agents how to use UI components (via the UI sub-project), there is a risk of executing arbitrary code. You should treat skills as untrusted until you inspect the Supermarket contents.

Licensing and maintenance costs

Memoh is licensed under AGPL-3.0. This is a strong copyleft license: if you modify the code and offer it as a network service, you must make the source available to users. For internal use, this is usually fine, but it is a real constraint if you plan to build a proprietary product on top of Memoh. The project is actively maintained: the latest release v0.18.0 was pushed on 2026-08-17, with v0.17.0 and v0.16.0 in the preceding weeks. The release cadence suggests a serious project. The maintenance cost is moderate: you need to keep the submodules updated, and the README notes that existing checkouts can use git pull with a post-merge hook, or run mise run submodule-init if the hook was not installed. GitHub's source archives omit submodules, so you must use the attached source zip or tarball for a buildable release. This is a concrete upgrade trap.

The wrong tool for some scenarios

Memoh is not the right choice if you want a fully managed, zero-setup cloud service. Memoh Cloud is still on a waitlist, so self-hosting is the only option today. That means you take on server maintenance, Docker management, and secret handling. The internal RPC secret must be kept private and reused when the stack is recreated, which is a common source of configuration drift. The README does not document failure modes such as what happens when the server restarts mid-task, or how memory is backed up. If you need guaranteed uptime or a SLA, you would be better off with a commercial alternative. Also, if you only need a single agent without isolation, Memoh's overhead is unjustified; a simple script or a hosted coding agent would be simpler.

A real alternative: running agents directly versus using Memoh

The most direct alternative is to run Claude Code or Codex directly on your own machine, without Memoh. That approach gives you full control over the environment, but you lose the always-on cloud workspace, the long-term memory across sessions, and the multi-channel integration. Memoh's value proposition is that it wraps these agents in an isolated, persistent environment with a chat interface. Another alternative is to use a general-purpose automation platform like n8n, which handles scheduled tasks and integrations but does not give each agent its own computer. The key difference is that Memoh focuses on agent identity and workspace isolation, whereas n8n focuses on workflow orchestration. If your primary need is scheduled workflows with API calls, n8n is simpler. If you need agents that browse, use a desktop, and remember context, Memoh is closer to the mark.

Editorial conclusion

Adopt Memoh if you need a self-hosted, multi-agent platform where each bot has its own isolated workspace and persistent memory, and you are comfortable managing your own infrastructure and API keys. Avoid it if you require a zero-maintenance managed service (Memoh Cloud is still on a waitlist) or if AGPL-3.0 licensing conflicts with your distribution model. Before deploying, verify the exact configuration keys in config.toml, test the submodule-based build process, and confirm that your target channels (Telegram, Discord, Lark, WeChat, QQ, Email) are supported in your region. The project is actively maintained with regular releases, but the documentation is thin on failure modes, so plan to validate your own backup and recovery procedures.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes