OpenClaw 2.0 cloud sessions and nodes: do you still need a server?
Sessions can now run on the Gateway, your own paired hardware, or throwaway cloud workers leased through Crabbox. What each piece does, and why the always-on Gateway didn't go anywhere.
OpenClaw 2.0 lets a session’s work run in three places: on the Gateway host itself (the default), on your own paired hardware (“nodes”, connected once with openclaw connect), or on throwaway cloud machines (“cloud workers”) leased on demand through a bundled tool called Crabbox. None of that replaces the server. The Gateway remains the owner of the conversation, the workspace, the model credentials, and your channels, and it still has to be running somewhere all the time. Cloud workers move the compute; they are not a home. If you were hoping 2.0 means your agent no longer needs an always-on machine, the opposite is true: it needs one Gateway, and everything else has become optional muscle around it.
Three places a session can run
Before 2.0, a session ran where the Gateway ran, full stop. The cloud-sessions machinery keeps the same chat interface and adds placement:
The Gateway host is still the default: the machine running openclaw gateway does the work for everyday sessions, exactly as before.
Paired devices are your own spare hardware: a desktop, a second laptop, a home server, connected once with openclaw connect. In the protocol a paired device is a node. Nodes advertise worker slots (one per CPU core by default), can optionally run sessions inside containers, and can host tools: plugins and MCP servers that live on the node get discovered and invoked from the Gateway without duplicating their configuration there.
Cloud workers are machines that did not exist a minute ago: leased from a cloud provider for one session or one burst of parallel work, then destroyed.
Cloud workers and Crabbox, concretely
The lifecycle is configured under cloudWorkers.profiles, and the docs describe it in one sentence: “the bundled Crabbox plugin provisions machines on demand across cloud backends (AWS, Hetzner, and others), runs your setup command, enrolls the box as a temporary node, and tears everything down when the session stops.” Idle workers suspend after a configured interval, and the next message provisions a replacement, “preserving the session and reconciled workspace”: the machine is disposable by design and the session is built to survive its loss.
Whose cloud account do those machines run on? Crabbox has two answers. In direct mode you bring your own credentials (the AWS SDK chain, a Hetzner token) and the machines are yours, billed to you. In brokered mode a coordinator service holds the provider secrets and does the leasing, with managed support for Hetzner, AWS, Azure, GCP, and Daytona; leased machines are vanilla runners that hold no broker secrets, and the broker tracks estimated and reserved spend per lease with configurable cost caps. Either way this is real cloud compute someone is paying for, priced by the machine and the minutes, on top of whatever your models cost.
What never leaves the Gateway
The docs are unambiguous about the anchor: “the Gateway stays the owner of the conversation, the reconciled workspace, model credentials, and placement records.” Transcripts and session history live in the Gateway’s store. Your channels (Telegram, WhatsApp, Discord, the Control UI) connect to the Gateway. Memory lives with the Gateway’s workspace. A cloud worker that dies mid-task costs you the machine, not the conversation.
Which settles the question this feature raises for most people. The announcement energy around 2.0 (infinite compute, sessions anywhere) can read as “the local install is obsolete, and so is the server.” The architecture says otherwise: every placement option assumes a Gateway that is up when a message arrives, holds the state worth keeping, and orchestrates the machines that come and go. The always-on requirement did not go away in 2.0; it got a sharper shape. One durable home for the Gateway, plus as much disposable compute as a task deserves.
What to do with that, practically
Running OpenClaw on your laptop: nothing changed about the trade-off. The Gateway stops when the lid closes, and the local-vs-server question has the same answer it had before 2.0.
Running on a server already: cloud sessions are additive. Your Gateway keeps doing what it does, and heavy or risky work (a big parallel refactor, code you want executed on a machine you can burn afterwards) can move to workers without touching the machine your agent actually lives on. Isolation is a legitimate reason on its own: a task on a throwaway box cannot wreck the home.
Spare hardware at home: pairing it as a node is the cheapest way into this: no cloud account, no lease pricing, your own idle cores doing the burst work while the Gateway coordinates.