Before You Start¶

Last updated: 2026-04-13 · Reading time: ~15 min · Difficulty: easy

TL;DR

The decisions in this chapter determine whether your first agent is live in 2 days or 2 weeks. Most of them are one-way doors, and they're all cheap to get right if you make them here.
Budget ~$50/month to run Clawford (VPS + LLM subscription), plus $8-30/month in residential proxy fees later if you deploy the shopping agent, Hilda Hippo. Budget 2-3 days to your first working agent and 2-4 weeks of evenings to a full fleet. Don't lowball either number.
Run Clawford on a dedicated VPS, not your daily driver. Use Telegram, not WhatsApp. Deploy Mr Fixit first. Those three are the cheapest "listen to me" decisions in the whole guide.
The per-agent config files ship as *.example templates in git; on first setup you scaffold the unsuffixed siblings via python3 agents/shared/deploy.py <agent> --bootstrap-configs, edit your real values into them, and the siblings stay .gitignored. That pattern is the seam that makes sharing this repo possible.
Plan for rebuilds, not stability. Every service that touches the real world breaks eventually. The question isn't whether, it's how fast you notice and recover.

What you need before Ch 03¶

You don't need everything below paid for and activated by the end of this chapter — just know what's coming, and have the free items in hand before you try to provision anything.

Accounts (required):

A Hetzner Cloud account. Ch 03 leans on the OpenClaw Hetzner install guide plus the community openclaw-terraform-hetzner module that wraps it. Other providers (DigitalOcean, Linode, Vultr, OVH, AWS Lightsail) will also work, but swapping providers is a Ch 03 problem.
A Dropbox account with ~10 GB free. The shared brain and agent backups sync through Dropbox — a dedicated account for this fleet is cleaner than co-mingling with your personal files.
A Telegram account. You'll create one bot per agent via @BotFather.
A GitHub account (or equivalent git host) for your canonical remote. The checkout on your local box is the source of truth; the remote is backup plus a place to review diffs.

Dev environment (required):

Git locally.
Claude Code or the Codex CLI — or an LLM pair-programming environment you already trust. Much of this guide assumes you'll be driving the tooling with an LLM copilot, not against a blank terminal. See Ch 01's "Who this guide is for" for the framing.
Docker Desktop (or rootless Docker) locally, if you want to smoke-test container changes before pushing. Optional — most real work happens on the VPS.

What you should already be comfortable with:

Shell and git, run and read. Python familiarity is welcome but not required — Claude Code eventually figures out a broken scraper if you give it enough room. Docker familiarity is also welcome but not required; you'll pick up what you need from Ch 03. Zero OpenClaw experience is assumed; this whole guide is the on-ramp.

LLM provider (required, pick one):

Either a ChatGPT Plus / Codex subscription (~$20/month, what I use) or a pay-per-token API key for OpenAI or Anthropic. The tradeoff is covered in "Picking your LLM provider" below — worth reading before you commit.

Optional — deferred until Ch 07-6:

A residential proxy subscription (IPRoyal, Bright Data, or similar). Only matters once you deploy Hilda Hippo for purchasing — Amazon and Costco detect datacenter IPs and will block you — so you'll need a sticky residential egress to reach them. Don't buy this until you're actually ready to deploy her. Budget $8-30/month when you do.

What it'll cost you¶

Rough monthly numbers from my own setup. Your mileage will vary with region and currency.

Line item	Cost	Kicks in	Notes
Hetzner VPS (cpx31)	~$30/month	Ch 03	4 vCPU / 8 GB RAM / 160 GB SSD. Availability varies by region — I picked cpx31 partly because the slightly larger cpx32 wasn't available in mine. Smaller SKUs are fine for small fleets.
LLM subscription	~$20/month	Ch 02	ChatGPT Plus / Codex. Flat rate is why I picked it.
Dropbox	free or ~$12/month	Ch 05	Free tier fits the shared brain; paid only if you archive a lot of brain snapshots.
Residential proxy	$8-30/month	Ch 07-6	Only if you deploy the shopping agent, Hilda Hippo. Skippable until then.
Baseline (no proxy)	~$50/month
Full fleet with proxy	~$60-80/month

None of this includes your time, which is the expensive part.

How long it'll actually take¶

I've been doing this for a while and my calibration is still usually off. Assume:

First working agent (Mr Fixit) end-to-end: 1 full day if absolutely nothing goes wrong. 2-3 days realistic. The first deploy of any new agent is a minefield — see Ch 07-1 for the list of silent failures I hit on Mr Fixit and how to avoid each one.
Full six-agent fleet: 2-4 weeks of evenings, depending on which services you're integrating and how much scar tissue you inherit from this guide.
Ongoing operations after the fleet is stable: a few hours per week of "something broke and I need to look at it," front-loaded after each new deploy and after each OpenClaw upgrade.

Don't bundle this onto a hard work deadline. You will spend more time in a browser inspector chasing a cookie than you expect to.

Three decisions to make right now¶

These three are cheap to get right up-front and expensive to reverse later.

Run it on a dedicated VPS — and don't run as root¶

OpenClaw runs with broad filesystem and shell access on its host. That's how the agents do their work. Pointing it at your work laptop means accidental file modifications, runaway processes during debugging, and a security posture you did not consent to.

Use a dedicated VPS. Ch 03 walks Hetzner cpx31 (~$30/month, 4 vCPU, 8 GB RAM, 160 GB SSD), which is comfortable for all six agents with headroom. Availability varies by region — I picked cpx31 partly because the slightly larger cpx32 wasn't available in mine. If your region offers a different set of SKUs, pick one step above what you think you need. A Raspberry Pi or old Mac mini can work if you already have one and don't mind the tradeoffs in Ch 01's VPS-vs-Mac-mini section — but the whole guide is written against a VPS.

On whichever host you pick, do not run OpenClaw as root. You'll hit package-manager permission errors, lose the ability to run systemd user services cleanly, and expand the blast radius of anything that goes wrong. The Terraform in Ch 03 creates a non-root openclaw user for you. If you're setting up manually instead, create one before you install anything:

adduser openclaw
usermod -aG sudo openclaw
usermod -aG docker openclaw

Everything in the rest of the guide assumes you SSH in as that user.

Telegram, not WhatsApp¶

OpenClaw technically supports both. Use Telegram anyway.

WhatsApp agent support rides on Baileys, an unofficial library that reverse-engineers WhatsApp Web. It brings three problems you will eventually hit:

Account bans. Operators who lean on it report being banned within days.
24-hour messaging window. WhatsApp blocks proactive bot messages after 24 hours of silence, which is exactly when you'd want an overnight cron to page you.
Silent session expiration. The web session dies without an error, and your agents go quietly dark.

Telegram uses the official Bot API. No ban risk, unlimited proactive messages, and each bot gets its own name and avatar so you can tell who's talking to you at a glance.

⚠️ Warning. Install Telegram on your phone before Ch 05. Bot creation via @BotFather runs through a real Telegram client, not a CLI.

Deploy Mr Fixit first¶

Mr Fixit is the infrastructure fox: he monitors every other agent's health, validates the shared brain, runs fleet-health probes, and escalates to you when something is broken. Deploy him first for three reasons:

He teaches you the deployment workflow with the lowest stakes in the fleet. If Mr Fixit breaks, nothing downstream has been built yet.
Once he's running, he monitors everything you deploy afterward. Your second agent inherits a canary for free.
The first deploy of any new agent is a minefield of silent failures. Better to eat those failures on the infra fox than on the agent that's wired to your calendar, your inbox, or your credit card.

The `*.example` template pattern¶

Before you clone anything, know that the repo has a strict shape that keeps PII out of git:

Every per-agent config file ships as <file>.example — e.g., agents/fix-it/IDENTITY.md.example, agents/shopping/manifest.json.example, agents/connector/scripts/mine/family_map.py.example.
The unsuffixed siblings (IDENTITY.md, manifest.json, family_map.py) are .gitignored. They exist only on your working machine.
First-time setup for each agent you plan to deploy is: python3 agents/shared/deploy.py <agent-id> --bootstrap-configs to scaffold every unsuffixed sibling from its .example template, then edit each one with your real values (names, IDs, preferences) and delete the  sentinel comment from the top of every .md file. The bootstrap tool refuses to overwrite anything that already exists, so re-running it after you add a new agent is safe. Never commit the unsuffixed files.

The README's "First-time setup" section has the full bootstrap flow. The short version: the templates ship populated with a fake placeholder family — Sam Smith (operator), Alex Rivera (partner), and kids Avery and Jordan — so the checked-in state is self-consistent and runnable without being anyone's actual life. When you personalize, you replace those values with your own in the unsuffixed copies. The sentinel rail is what stops you from accidentally shipping the placeholder cast into a live workspace if you forget to edit a file: deploy.py's Safeguard 10 (Ch 05) refuses any deploy that still carries it.

🔦 Tip. If you ever see real names or identifiers drift into a .example file, treat it as a PII leak and fix it before pushing. The .example files are what I expect to be in public git; the unsuffixed copies are what I expect to be in yours only. Running git status before every commit and watching for tracked unsuffixed agent configs is a cheap habit that catches this before it matters.

Picking your LLM provider¶

OpenClaw supports multiple providers through OAuth or API keys. The main options:

Option	Cost	Setup	Notes
ChatGPT Plus / Codex subscription	~$20/month flat	OAuth during onboarding	What I use. Flat rate, predictable bill, GPT-5.4 is strong on the agent workloads I care about.
OpenAI API key	~$0.01-0.10 per agent turn	`OPENAI_API_KEY` in `.env`	Pay-per-token. Best if your usage is very low or very bursty.
Anthropic API key	Pay-per-use	`ANTHROPIC_API_KEY` in `.env`	Claude Sonnet / Opus via API. Rate-limit behavior differs from OpenAI.
Claude Pro / Max subscription	~$20/month flat	(not via OpenClaw)	May violate Anthropic's ToS for automated / agentic use — use API keys instead if you want Claude models.

🔦 Spicy take — I don't use raw API keys. I pay for a flat-rate ChatGPT / Codex subscription and route LLM calls through that instead of wiring an OPENAI_API_KEY into the fleet. My reasoning: I like the predictable monthly bill, I like that a leaked subscription isn't a runaway per-token bleed, and I like that the scope is tied to an account I already audit. The cost is some ergonomic friction (session management, periodic re-auth). The benefit is I've never once been surprised by an LLM invoice. This is a personal choice, not a universal rule — if pay-per-token suits your usage pattern better, take it.

Every service with multi-factor authentication (MFA) — Google, Costco, Amazon, LinkedIn, and so on — eventually logs the agent out. The default answer in a lot of agent frameworks is "the operator hand-types a code whenever it breaks." I refused to accept that as a stable state and ended up building a fair amount of Camoufox plumbing plus little scrapers that pull login codes out of my authenticator app and my SMS inbox, so the fleet can re-auth itself without me in the loop.

The cost is real: that plumbing is fragile, it takes debugging when a service changes its login flow, and every auth vector is a potential security issue you are choosing to automate instead of interactive-prompt. The benefit is that my overnight crons actually run overnight.

This is another personal choice. Reasonable operators land on the other side and prefer a manual re-auth step with a Telegram nudge — it's simpler, it's arguably safer, and it works if you're at a keyboard often enough. The guide covers the automated path in Ch 07-7, but if you'd rather not maintain it, that's a defensible call. Know which side you want to be on before you start Ch 03.

Pick one thing to prioritize¶

These trade off against each other. Decide which matters most before you design anything:

If you care most about…	Prioritize…	At the cost of…
Privacy	Self-hosted LLM, hardened VPS, minimal third-party services	Agent capability ceiling drops noticeably
Cost	API-key-only billing, free Dropbox tier, skip the proxy	Surprise bills are possible; Hilda Hippo doesn't work without a proxy
Unattended reliability	Auto-MFA everything, Mr Fixit first, fleet-health probe on the host	Highest maintenance burden; most surface area to debug
Breadth of agents	Deploy all six, integrate broadly	Each additional agent is its own rabbit hole
Speed to first win	Deploy Mr Fixit only, skip proxies and Hilda	A smaller surface until you add the next agent — though a single-agent setup doesn't even need the shared brain, so it's lean rather than crippled

There's no wrong answer. There is, however, a wrong answer in pretending you'll prioritize all five and ending up with half of each.

The meta-lesson — plan for rebuilds, not stability¶

If there's one idea to carry from this chapter into every other one, it's this: everything in this fleet will break eventually, and the measure of a good setup is how fast you notice and recover, not how long you go between failures. Services change their HTML, cookies expire, session tokens rotate during a rebuild, Dropbox conflicts pile up, Docker images drift, residential proxies rotate out of a good neighborhood. The stability narrative — "once it's set up it just runs" — is a story I told myself early on and paid for later in long debugging sessions.

Every design choice in this guide is downstream of that assumption. Mr Fixit as the canary. The *.example template pattern. The fleet-health.json probe. Red-green TDD for infra code. Committing everything to git. They only cohere as a system if you start from "this will break, how do I recover fast." Start from "this should be stable," and half of the guide reads like over-engineering until the morning you page yourself trying to figure out which three things broke at once.

Pitfalls you'll hit¶

🧨 Pitfall. Committing real credentials, names, or IDs into an agent config that isn't a .example file. Why: the repo's PII hygiene assumes every unsuffixed agent config is gitignored; one sloppy git add -A and you've leaked a chat ID or a family email into history. I had to rewrite 285 commits of history with git-filter-repo the first time I shared this repo, and I do not recommend it as a reusable fix. How to avoid: stage files by name, not with -A or .. Run git status before every commit and look for tracked unsuffixed agent configs — they should never appear.

🧨 Pitfall. Picking WhatsApp "just to try it" because your family already uses it. Why: Baileys-based WhatsApp bindings ban within days, and the 24-hour inactivity window silently drops the exact overnight alerts you'd want most. How to avoid: stand the fleet up on Telegram first, always. If you later need WhatsApp for human reachability (I do, for Mistress Mouse), wire it as a delivery target an agent hands off to, not as the agent's primary channel.

🧨 Pitfall. Underestimating time-to-first-agent and booking real deadlines against it. Why: first deploy of a new agent hits silent failures (Ch 07-1). A "should be an afternoon" plan routinely turns into three evenings of debugging the OpenClaw CLI, BotFather, and a Dropbox conflict from a file you didn't know was open. How to avoid: plan 2-3 days to Mr Fixit and 2-4 weeks of evenings to a full fleet. Tell the people waiting on you something generous.