OpenClaw without the terminal: setup, hosting, and everything you skip

What a raw setup actually involves

Every agent reads from its own workspace directory:

• SOUL.md for identity

• AGENTS.md for operating procedures

• TOOLS.md and HEARTBEAT.md for environment notes and scheduled tasks

• A skills/ folder for whatever it's been taught to use

You write these by hand, or generate a first pass and fix what it got wrong. The team's shared config lives in openclaw.json, and every tool credential your agents use sits in there too, under skills.entries, which means API keys in a file you now have to secure yourself.

The Gateway needs a specific network mode to work inside a container at all, plus a persistent volume, or your agents forget everything the moment it restarts. You get two health endpoints, one for "is the process alive" and one for "are the channels connected," and nothing checks either unless you build something that does. No public OpenClaw image ships with channel support baked in, because no such image exists. You're building your own from the OpenClaw Dockerfile and adding whatever channels your team needs.

WhatsApp is the annoying one: you pair a phone number by scanning a QR code, and if that session ever drops, you're the one re-scanning it, usually mid-workday. Slack's the easy one by comparison, register an OAuth app, request the scopes, done in ten minutes. Doing either once is a weekend project. Doing it for every channel you support, and doing it again every time OpenClaw changes, is the actual job.

The part that doesn't end when setup does

Nobody puts this part in a setup guide: watching it run.

• No dashboard, just raw container logs. Any history beyond what's sitting on disk means shipping those logs somewhere yourself.

• Spend per agent isn't broken out anywhere. Want to know what a specific agent is actually spending? That's parsing it out of raw output by hand.

• Nothing pages you. The container can go down and sit there until you notice, unless you've built something that pings the health endpoints on a schedule, a client finds out before you do.
  
  

A restart policy you configure and hope catches the right failures. Auth tokens you generate and store somewhere that isn't a plaintext file, ideally.

Then OpenClaw itself keeps moving. Runtime updates, security patches, occasional changes to how agents behave, each one a decision you make alone, tested against your own workspace before you roll it forward. There's no changelog written for your specific setup and no button that reverts you if something breaks on a Friday evening. The setup is a project with an end date. Keeping it running doesn't have one.

What each path actually costs

Claws will run a flat $79 a month per running Claw, covering hosting, monitoring, every channel, and every update, in one number you can plan around.

Self-hosting doesn't have one number. Compute to run the container somewhere is the easy part to price. The harder part is everything measured in your own time instead of dollars:

• Building the monitoring and alerting that don't exist out of the box

• Wiring every channel by hand

• Staying on top of every OpenClaw update from here forward, for as long as the team runs
  
  

We won't invent an hours-saved figure for that, because it depends entirely on your team and we don't have real data to back one up. But the shape of it is the point: one side is a fixed number. The other is open-ended labor that shows up bill by bill, weekend by weekend.

Self-hosting isn't wrong. Teams that genuinely want that level of control over the container and the config should build it themselves. Most of what's above is just plumbing, though, the same plumbing every team ends up rebuilding, with no prize for having done it yourself. Claws exists so you decide that once, instead of finding out the hard way three weekends in.