Run OpenHuman on a cloud Mac: Memory Tree 24/7 and how to split with OpenClaw

If you have ever re-explained your client stack to ChatGPT in the morning and again in a Slack thread by afternoon, you already know the problem: agents multiply, but context stays fragmented. OpenHuman is an open-source desktop system that tries to fix that by pulling Gmail, Notion, GitHub, calendars, and more into a local memory store on macOS, Windows, or Linux—not by opening yet another chat tab. The repo lives at tinyhumansai/openhuman; setup and connector behavior are documented in the OpenHuman GitBook.

This article is not an install walkthrough. It is a hosting decision guide for people who intend to run OpenHuman seriously: whether it belongs on a laptop or a dedicated cloud Mac mini, how it pairs with OpenClaw on a remote Mac, and when renting a cloud Mac beats keeping auto-fetch on a machine that sleeps when you close the lid. Weekend experiments are fine on a local MacBook; if you need 7×24 sync, stable OAuth egress, and disk you can grow, read on.

1. What OpenHuman actually does: memory pipeline, not another copilot

Officially, OpenHuman is a desktop personal AI system: Rust core, TypeScript UI, and one-click OAuth for third-party apps (public materials cite 118+ integrations). The product bet is not “smarter model replies” but a persistent data pipeline. Its Memory Tree compresses mail, calendar events, documents, and code activity into Markdown, then stores them in SQLite and an Obsidian-style local vault—the docs call this an Obsidian-style wiki.

By default, auto-fetch runs on roughly a 20-minute cadence (auto-fetch docs): new mail, calendar changes, and repo commits are pulled to the host and indexed. In practice that means the assistant can answer “what did I promise that client yesterday?” or “who merged the blocking PR this week?”—but only if the host stays awake, the network stays up, and the disk does not silently fill.

Compared with Copilot-style tools that answer the current prompt, OpenHuman behaves more like a private ETL plus agent layer on your own hardware. You are choosing to trade cloud convenience for local retention and connector breadth. That trade only pays off if the machine running it is reliable enough to keep the pipeline warm.

2. OpenHuman vs OpenClaw: remember vs execute

Many Nuvcloud readers already run OpenClaw (docs.openclaw.ai, openclaw.ai). The split is simple:

• OpenHuman aggregates your digital life into searchable memory—best for “draft a reply from recent mail,” “what conflicts with this week’s meetings and commits,” or “summarize what changed across Notion and GitHub.”
• OpenClaw turns macOS into an orchestrated execution surface—webhooks, Gateway, runners, and tight coupling with self-hosted GitHub Actions macOS runners.

In real teams the sane pattern is two machines or two roles: OpenHuman on an always-on cloud Mac to “grow memory,” OpenClaw on another node for CI and automation. If you only have one 16GB box, pick one job and run it well—do not enable every connector and a parallel runner on the same volume.

OpenHuman is not a substitute for build pipelines; OpenClaw is not a substitute for a unified mail-and-docs memory graph. They complement each other when you respect resource boundaries and separate OAuth scopes.

3. When running OpenHuman on a cloud Mac is the rational move

OpenHuman runs fine on a local MacBook. Move it to a dedicated cloud Mac mini when two or more of these are true:

• You travel, close the lid, or rely on home broadband that drops—and you still want auto-fetch to continue.
• Your memory vault grows tens of gigabytes per week and a thin laptop SSD is the bottleneck.
• Corporate OAuth or SaaS allowlists require a stable egress IP your home ISP cannot provide.
• You refuse to mix personal Gmail tokens and Early Beta software on your primary daily driver.

A cloud node buys predictable uptime and expandable disk. You SSH for logs, use VNC or screen sharing for OAuth consent dialogs—the same remote-Mac workflow described in the help center. The cost is OpEx instead of “free” laptop cycles, which is why we recommend daily rent first: run real mail and calendar traffic for a week, then switch to monthly if the curve looks stable.

Region choice matters for latency to SaaS APIs and for compliance narratives. US-heavy integrations often fit US East or US West nodes; APAC teams may prefer Singapore, Japan, or Hong Kong—the same regional thinking as our OpenClaw deployment guides. The goal is not novelty; it is removing sleep, disk, and IP churn from the memory pipeline.

4. Sizing M4 RAM and disk before you commit

OpenHuman is not a static app install. Connectors, indexing, and Markdown export all scale with how much of your life you attach. Undersizing shows up as swap, slow auto-fetch, and emergency disk wipes—not as a polite error message.

Current plans and SKUs are on the Mac mini pricing page. Operationally: rent for 48–72 hours, check memory-vault directory size once per day, and only move to monthly if growth and memory pressure stay acceptable. If you are also evaluating desktop AI stacks at the OS level, see our Aluminium OS comparison for a different angle on local vs cloud assistants.

5. First week on a cloud Mac: deployment checklist

Treat the first week as a measured rollout, not a “enable everything” sprint. OAuth tokens and disk growth compound quickly; staged connectors make failures easier to isolate.

1. Confirm macOS version against the GitHub release you pinned; ensure corporate firewalls allow HTTPS and OAuth redirects.
2. Install only official packages; authorize connectors in batches—mail and calendar first, then Notion and GitHub.
3. Put the memory vault on a dedicated path or volume; schedule backups of SQLite plus Markdown exports.
4. Use SSH for daily health checks; use VNC or screen sharing when the UI needs an OAuth consent window.
5. Document which integrations are production vs experimental so you can revoke one without nuking the whole vault.

sw_vers
df -h /
du -sh ~/Documents/* 2>/dev/null | sort -hr | head -5
# Compare the largest folders week over week; vault growth should be predictable

The commands above are not magic—they are a habit. Run them on a schedule until you trust your connector set. If a single directory jumps faster than mail volume explains, disable the newest integration and re-measure before expanding disk.

6. Security: tokens and memory vaults are personality replicas

Once Gmail and Notion are connected, the SQLite database and Markdown tree on that Mac are effectively a professional and personal likeness of you. Minimum bar: FileVault on, SSH key-only login, OAuth scopes limited per app. If corporate mail is under DLP, do not point a personal OpenHuman instance at managed inboxes unless compliance has signed off in writing.

If models route through cloud APIs, store API keys separately from vault backups and rotate them on the same cadence as other secrets. During Beta, subscribe to GitHub Releases and avoid auto-tracking latest on a production memory host. Snapshot before upgrades; verify connectors still fetch after each bump.

Isolation is a feature: running OpenHuman on a cloud Mac you do not use for daily browsing reduces the blast radius if a connector misbehaves or a beta build regresses. That isolation only works if you also resist copying vault files back to an unencrypted USB stick “just to test.”

7. FAQ

Q1: How is this different from uploading PDFs to ChatGPT?
OpenHuman continuously auto-fetches from live integrations; memory evolves as mail and calendars change. It is not a one-time document upload.

Q2: Can OpenHuman replace OpenClaw?
No. OpenHuman aggregates context; OpenClaw executes automation and CI. Run them on separate hosts if both matter.

Q3: Is 16GB enough?
For three to five connectors and no runner on the same machine, 16GB is a reasonable trial. Heavy integrations or shared CI need 24GB.

Q4: Will the memory vault fill my disk?
Yes—and often faster than people expect. Every auto-fetch cycle can add mail bodies, calendar entries, Notion pages, and GitHub metadata into local SQLite and Markdown files. Those files do not shrink when you delete mail in the cloud unless you also prune or disconnect the integration. On your cloud Mac, log in weekly, open Terminal, and run du -sh on the vault directory to see total size in human-readable form (for example, 42G means forty-two gigabytes). If growth spikes after enabling Gmail, you may have synced years of history—reauthorize with a shorter window or archive old threads before expanding disk. Turn off connectors you no longer need instead of letting them accumulate forever.

Q5: Do I have to use a cloud Mac?
No. But for 7×24 auto-fetch, an always-on cloud node is more dependable than a laptop that sleeps when you commute.

Q6: Does this conflict with Copilot or Apple Intelligence?
Different layers: OS assistants serve the desktop; OpenHuman spans SaaS apps into one memory graph. For system-level AI comparisons, see our Aluminium OS article.