# Memoh: self-hosted cloud computers for AI agents

> Memoh gives each agent an isolated workspace with a filesystem, desktop, browser and long-term memory, and hosts Claude Code or Codex inside it. Here is how the Go stack deploys, what it costs to run, and where it stops being the right tool.

**memohai/Memoh** — ✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.

- Repository: https://github.com/memohai/Memoh
- Website: https://memoh.ai
- Stars: 2,539 · Forks: 244
- Language: Go
- License: AGPL-3.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/memohai-memoh

## The problem Memoh solves: agents that die with your laptop

Most agent setups are tied to the machine you are sitting at. Close the lid and the scheduled task stops, the browser session dies, and the next conversation starts from nothing. Memoh's answer is to give every agent its own cloud computer: a dedicated workspace with a filesystem, network, desktop and browser, running on a server rather than on your desk. The README states the goal plainly, that agents stay online 24/7 even when your laptop is closed.

The audience is narrower than the tagline suggests. This is for people who already run a coding agent and want it to keep working, or for teams that want one bot per person without each person provisioning a machine. The README lists three shapes: run one for yourself, assign one to each team member, or spin up a fleet. It is not a hosted chat wrapper. You supply the API keys, and the README says you can bring your own or host existing Claude Code and Codex agents inside Memoh workspaces through ACP, configured per bot.

## How the Go server, workspaces and channels fit together

Memoh is a Go monorepo with a Vue front end and a small Rust crate, and the dependency list in go.mod shows what the isolation is built on: containerd, runc-adjacent specs, CNI for networking, and a PTY package for terminal sessions. That is the mechanism behind the claim that each bot gets its own computer. Workspaces are containers with their own network namespace, not directories with a prefix.

Storage is Postgres plus pgvector, and docker-compose.yml defines them as two separate services, postgres on database memoh and pgvector on memoh_vector. The vector store is what backs long-term memory, including the optional Mem0 and OpenViking integrations the README mentions. A third service, migrate, runs memoh-server migrate up against Postgres before the server starts, so schema changes are applied by a dedicated container rather than at boot.

Channels are the other half. Telegram, Discord, Lark, WeChat, QQ and Email are named in the README, and go.mod carries SDKs for Discord, Lark, LINE, DingTalk and IMAP. The README describes an important architectural switch: leave internal_rpc.shared_secret empty in config.toml and the server embeds the channel runtime as a single all-in-one process; set the secret and you opt into a split two-process deployment with a separate memoh-channel service. Both are supported. The split is what the Compose stack uses, and the README warns to keep the secret private and reuse the same value whenever the stack is recreated.

## Installing Memoh and running a first agent

The shortest path is the install script the README gives. It is a shell script served from memoh.sh, and the README explicitly says not to run the whole installer with sudo; the installer uses sudo docker internally if Docker requires it.

```bash
curl -fsSL https://memoh.sh | sh
```

If image pulls are slow from where you are, the README documents a mirror flag rather than a different URL.

```bash
curl -fsSL https://memoh.sh | USE_CN_MIRROR=true sh
```

For a manual deployment you clone with submodules, copy the Docker config template, and bring the stack up. Note the shallow submodule flags: the repository uses submodules, and the README states that GitHub's automatic source archives omit submodule contents, so the attached Memoh-<version>-source.zip or .tar.gz asset is the buildable archive.

```bash
git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/memohai/Memoh.git
cd Memoh
cp conf/app.docker.toml config.toml
export MEMOH_INTERNAL_RPC_SHARED_SECRET="$(openssl rand -hex 32)"
docker compose up -d
```

After the stack is healthy, the work moves to the Web UI, where you add a bot, bind a channel, and give it a model key. The README does not document the UI steps in detail, so treat the docs site as the reference for bot creation. What it does document is the deployment shape: Compose runs Server and Channel as separate services, and the migrate container applies migrations first.

If you are upgrading a bare-metal install or running without Docker, the instruction is different. Leave internal_rpc.shared_secret empty and the server embeds the channel runtime, keeping external channels, email and webhook endpoints in one process with no memoh-channel process required. Existing setup checkouts can keep using git pull, because the post-merge hook initializes the new submodule and setup enables recursive updates for future pulls. If that hook was never installed, the README gives one recovery command.

```bash
mise run submodule-init
```

## The operational weight of per-agent isolation

Isolation is not free, and Memoh's own Compose file admits it. The server service runs privileged with pid: host, which is a broad grant. That is what lets it manage containers and workspaces, but it means the server container is not a security boundary in the way a normal application container is. If you are deploying this on a host that also runs other tenants' workloads, that is the detail to look at first.

The Compose file also sets an explicit memory ceiling and comments that the Go runtime backs off at GOMEMLIMIT instead of hitting the container's OOM kill, with the guidance to keep GOMEMLIMIT at roughly 85% of mem_limit when overriding either. So the resource story is not automatic. You are expected to size the host, and every workspace you add consumes memory whether or not its agent is doing anything, because the point is that it stays online.

The wrong-tool case is a single assistant with one conversation history. If that is what you need, you are paying for containerd, CNI, two Postgres instances and a privileged server process to get a result a small application with one database table would give you. Memoh is also the wrong choice if you cannot run a persistent server at all, since the entire value proposition is uptime while your own machine is off. The README points to Memoh Cloud as a waitlist, not as an available service, so there is no hosted fallback documented today.

## Memoh compared with a plain agent plus a memory library

The closest alternative is not another multi-agent platform. It is running your agent directly on a server with a memory library bolted on, for example Claude Code in a tmux session with a vector store the agent queries through an MCP server. That approach is lighter and has no privileged component. The difference in approach is where the isolation lives: with the plain setup, one agent process and one filesystem serve everything, and memory is a tool the model chooses to call. In Memoh, isolation is the substrate. Each bot's filesystem, network and desktop are separate by construction, and memory is built in rather than assembled.

That distinction matters most with multiple users or multiple bots that should not see each other's files. It matters least with one agent and one operator. The README's own feature list, MCP support, skills, scheduled tasks and browser use, is all reachable in the plain setup too, so the deciding factor is the workspace boundary and the always-on guarantee, not the feature checklist.

## Licence and the cost of staying current

Memoh is licensed AGPL-3.0, and the README repeats that at the bottom. The practical consequence is the network clause: if you modify Memoh and let users interact with it over a network, the AGPL's source-availability obligation is the thing to read carefully. Self-hosting it unmodified for your own team is the straightforward case. Embedding it in a product you distribute is where you want your own reading of the licence rather than a summary. Nothing here is legal advice.

Upgrade cost is visible in the release cadence. v0.16.0 landed on 2026-07-11, v0.17.0 on 2026-07-29, and v0.18.0 on 2026-08-17, with the last push to the repository on 2026-08-17. Three minor releases in about five weeks, and the root package.json carries version 0.19.0 while the newest tagged release is v0.18.0, so the main branch is already ahead of the last tag. Minor versions at that rate mean migrations arrive often, and the migrate container exists precisely because schema changes are routine. Budget for reading release notes before each pull, and note that the submodule handling changed at some point, which is why the post-merge hook and mise run submodule-init matter.

## Conclusion

Adopt Memoh if you want per-agent isolation and 24/7 uptime on hardware you control, and you are willing to own Postgres, pgvector and the container runtime underneath it. Skip it if a single chat bot with one shared memory store is enough, or if AGPL-3.0 obligations conflict with how you ship. Before committing, verify the interactive installer on a throwaway host, confirm that the config.toml written by the installer matches conf/app.docker.toml, and check whether you want the split two-process deployment or the single all-in-one process.

## FAQ

### Is Memoh free to self-host?

The repository is licensed AGPL-3.0 and the README describes self-hosting the full stack on your own infrastructure, so there is no licence fee for that path. You still pay for the server, and you supply your own model API keys.

### How do I install Memoh on my own server?

The README gives a one-line install, curl -fsSL https://memoh.sh | sh, and a manual path that clones the repository with submodules, copies conf/app.docker.toml to config.toml, and runs docker compose up -d. It warns not to run the whole installer with sudo.

### Can Memoh host Claude Code and Codex agents?

Yes. The README lists Agent Hosting as a feature, stating that external agents are hosted inside Memoh workspaces via ACP, currently Codex and Claude Code, configured per bot.

### Does Memoh keep running when my laptop is closed?

That is the stated design goal. The README says agents stay online 24/7 even when your laptop is closed, because each one runs in its own workspace on the server you deploy rather than on your local machine.

## Sources

- [Official documentation](https://memoh.ai)
- [Official README](https://github.com/memohai/Memoh#readme)
- [Project repository](https://github.com/memohai/Memoh)
- [Release notes](https://github.com/memohai/Memoh/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/memohai-memoh