Self-hosting an AI agent on your own box is a great weekend project and a genuinely educational one. But once the agent stops being a toy and starts doing daily work — running a real shell, cloning repos, driving a browser, surviving reboots — the box becomes a second job. A lot of us are moving the runtime to a cloud agent workspace and keeping the control on our laptop. This is a field report on why, what actually breaks, and what you trade away.
The setup that everyone starts with
You've seen this story because you've lived it. You spin up a self-hosted agent — let's call the archetype OpenClaw, the kind of local-first setup people run on a spare Mac Mini or a Linux box in the closet. You give it shell access, a workspace folder, an API key, and a system prompt. The first week is magic. It writes a script, runs it, reads the error, fixes the script. You feel like you've cheated the universe.
I ran exactly this for months and I still think it's one of the best ways to actually understand how agents behave. You see every tool call. The data never leaves your hardware. You can patch the agent loop live because it's right there in your editor. For a single developer who likes control, local-hosted agents are legitimately good, and I'm not going to pretend otherwise.
The trouble starts when the agent gets useful enough that you want it running all the time, doing work you actually depend on. That's when "my agent lives on a machine in my apartment" stops being a feature.
Where the self-hosted dream starts leaking
None of these are dealbreakers in isolation. Together they're a slow tax on your attention.
Your laptop is now infrastructure
The moment an agent needs a real shell, a persistent filesystem, and a browser, it needs a machine that's up. Self-hosting means that machine is yours. You close the lid, the long-running task dies. You reboot for an OS update, the agent's half-finished npm install is gone. You travel and your home IP changes, and now the webhook you set up for a chat integration silently stops firing.
I started keeping a literal checklist of "things that must be running for my agent to work": the agent process, a reverse tunnel so I could reach it from my phone, a headless browser with the right Chromium flags, a cron job to restart everything when it OOM'd. That checklist is the smell. When the supporting cast outgrows the actor, something is wrong.
Dependency hell, but for the agent
A capable agent needs to do capable things: run Playwright, build a Docker image, install system packages, manage a Python virtualenv that doesn't collide with the three other ones on your machine. So your agent's environment starts colliding with your environment. I bricked my local Node version once because the agent "helpfully" ran a global install. The agent and the host fighting over the same /usr/local is a special kind of frustrating, because now you're debugging two things that both think they're in charge.
Browser automation on a personal machine is jank
If the agent needs to browse — fill a form, scrape a dashboard, click through an OAuth flow — you're running a headless or headful browser on your laptop. It steals focus. It pops windows. It needs a display server you don't have on a remote box. You end up babysitting Chromium flags and xvfb instead of doing the actual work the agent was supposed to free you up for.
"Memory" that isn't memory
Most DIY setups treat the chat log as the agent's memory. It is not. Restart the process and the agent forgets the architecture decision you made on Tuesday. You can bolt on a vector store, sure, but now you're operating a database too. The thing you wanted was an employee with a filing cabinet. What you built was a goldfish with a transcript.
Security is entirely your problem
An agent with shell access is, by design, a remote-code-execution machine you invited in. On your own hardware that blast radius includes your SSH keys, your ~/.aws/credentials, your browser cookies. Sandboxing it properly — separate user, container, network egress rules — is real work, and most weekend setups skip it. I know mine did for far too long.
What "cloud workspace" actually means (and what it doesn't)
When I say cloud workspace I do not mean "a chatbot in a browser tab." That's the thing people assume and it's the wrong mental model. A chatbot answers; a workspace works.
The shape that's winning is closer to this: a cloud-hosted, isolated runtime where the agent gets a real terminal, a real git surface with diffs and branches and rollback, an AI-controlled browser that runs server-side, and a persistent file drive that survives every restart — all behind a UI you watch from your laptop without hosting any of it. You keep the steering wheel; the engine moves off your hardware.
The platform I've been using for this, Buda, frames it with a company analogy that finally made the architecture click for me. An Agent is an employee. Its Drive is the filing cabinet — durable, the actual long-term memory, not a chat scrollback. A Session is a meeting room: isolated short-term context you can spin up and throw away. And a Space is the office: the org boundary where billing, members, and shared storage live. Under the hood, the compute layer (they call it Claw Computer) hands each agent an isolated, durable runtime, and a scheduling layer decides what runs when. The point of naming all that isn't branding — it's that the runtime is a real system, not a wrapper around a model API.
That last distinction is the whole migration in one sentence. Self-hosted setups are usually a model wrapper plus your hardware. A workspace is a runtime plus a filesystem plus tools, and the hardware is somebody else's problem.
The day-to-day wins, concretely
Let me skip the brochure language and tell you what actually changed in my week.
Long-running tasks just keep running
I kick off a task — "clone this repo, run the test suite across these three branches, summarize the failures into a Drive file" — and then I close my laptop and get on a train. The agent's runtime is in the cloud, so the work doesn't care that my client went to sleep. I reconnect later and read the diff. With my self-hosted version, that exact workflow required my machine to stay awake, plugged in, and online for the duration. Now it's just... a thing that happened while I was away.
The terminal and git are first-class, not bolted on
The single feature I underrated was a visual git tab sitting on top of the agent's real working directory. The agent makes changes, I see the commits and diffs, I can branch or roll back. It turns "trust the agent's edits" into "review the agent's PR," which is the same instinct I'd apply to a human teammate. Pair that with a live shell I can drop into mid-task, and the workspace stops being a black box.
A rough sketch of how a session feels:
# In the agent's cloud terminal — same shell the agent uses
$ git clone https://github.com/acme/api.git && cd api
$ npm ci && npm test # agent runs this, I watch it stream
# ...agent reads failures, edits files, commits...
$ git log --oneline -3
a1c2e4f fix: handle null token in auth middleware
9f3b1d0 test: add regression case for expired session
3e8a0c2 chore: bump supertest to 7.x
I didn't install Node. I didn't manage the virtualenv. The node_modules and the repo live on a high-performance volume in the workspace, not eating my laptop's SSD.
Browser work moves off my screen
The agent's browser runs server-side, streamed back to a tab I can watch. No focus-stealing, no xvfb, no Chromium flag archaeology. When I need to see what it's doing — say, debugging a flaky scrape — I watch the AI browser live instead of fighting a headless instance on my own machine.
Memory that's actually a filesystem
Because the Drive is the durable layer, "remember our deployment runbook" means the agent writes a file, and that file is there next week, next session, and for any teammate in the same Space. I stopped pasting the same context into every conversation. The habit that matters: if it should survive the session, it goes to Drive. Chat is the meeting; Drive is the cabinet.
It's a team thing, not a single-player thing
This is the part self-hosting structurally can't match without you becoming an ops team. A workspace lives in a Space with members, shared storage, and shared credentials. When a coworker needs the same agent, I add them to the Space — I don't ship them a Docker image and a setup README and then spend an afternoon on a debugging call. And the same agent can answer from a web widget, Slack, Telegram, Discord, or an OpenAPI endpoint without me standing up a server for each one.
The honest trade-offs
I'd be lying if I said this is a free lunch. A migration piece that only lists wins is marketing, so here's the other column.
- You give up some control. It's not your kernel. If you're the kind of developer who wants to patch the agent loop or run a fully air-gapped model, a managed workspace will feel like a cage. (Enterprise/self-host options exist for the data-residency crowd, but that's a different conversation than "my Mac Mini.")
- Data leaves your hardware. For a lot of work that's fine — encrypted in transit and at rest, not shared with third parties — but if your threat model says "nothing leaves the building," local-first still wins. Be honest about which camp you're in.
- It costs money. Self-hosting feels free because you already own the laptop and you're not pricing your own time. A cloud workspace has a line item. Most platforms — Buda included — have a free tier to kick the tires, with paid plans unlocking the heavier tools and storage; check the live pricing page before you budget, because tiers move.
- Cold-start learning. The mental model (Spaces, Agents, Drives, Sessions, Channels) is a small upfront tax. It paid off for me within a day, but it's not zero.
How to decide, without overthinking it
A quick gut check I'd give a friend:
- Stay self-hosted if: it's a single-user hobby, the data genuinely cannot leave your machine, you enjoy the tinkering as an end in itself, or you need to hack the agent internals.
- Move to a cloud workspace if: the agent is doing work you depend on daily, tasks run longer than your laptop stays awake, more than one person needs it, or you've caught yourself maintaining infrastructure that exists only to keep the agent alive.
That last bullet is the real signal. The day I realized I was spending more time keeping the agent's home alive than getting value out of the agent, the decision made itself.
A pragmatic migration path
You don't have to rip anything out on day one. What worked for me:
- Pick one annoying recurring task — the one whose failures you're tired of. Mine was "run the integration suite and triage failures."
- Recreate just that workflow in a cloud workspace. One agent, the files it needs in its Drive, the repo cloned into the workspace.
- Run both in parallel for a week. Let the self-hosted version and the cloud one do the same job. You'll feel the difference in maintenance overhead immediately.
- Move the durable knowledge to Drive — runbooks, SOPs, the context you were re-pasting every time. This is the step that makes the agent feel like it has continuity.
- Connect a channel last. Once the agent is solid, expose it where your team already is (Slack, a web widget, whatever) instead of building a delivery mechanism yourself.
Keep your self-hosted rig around. It's a great lab, and you'll want it the next time you're learning how some new agent capability actually works under the hood. The migration isn't "local is bad." It's "stop making your laptop the production environment for something that's become production."
The bottom line
The shift isn't really about cloud versus local as an ideology. It's about where the runtime should live once an agent crosses the line from experiment to dependency. Self-hosting keeps that runtime — and all of its babysitting — on you. A cloud workspace moves the terminal, the git surface, the browser, and the persistent memory off your hardware, and hands you a window to watch and steer through.
I still love the self-hosted version for what it taught me. I just don't want it to be the thing standing between me and shipping. If your agent has graduated from "cool demo" to "I rely on this," it's probably time to let something else keep the machine alive while you go do the work.
Top comments (0)