Your OpenClaw's entire memory lives in one fragile directory.°
Sessions, agent memory, channel config, the SQLite state — all of it is ~/.openclaw on one machine. Back it up into your own always-on VM with one command; it comes back up running, minus your secrets, which never leave your laptop.
See exactly what would move — free, nothing uploads
$ curl -fsSL https://jurniti.com/install.sh | sh$ jurniti transfer --harness openclaw --dry-runThe dry run prints the full manifest — what travels, what gets redacted, and what never leaves your machine — then exits. Prefer to start with the VM? Get your VM first.
What an OpenClaw backup has to include
OpenClaw's own migration doc gives the correct advice: copy the ENTIRE state directory, not pieces of it. The state dir (~/.openclaw, or wherever OPENCLAW_STATE_DIR points) is one interdependent unit:
| Path | What it holds | In the transfer |
|---|---|---|
~/.openclaw/sessions/ | Conversation sessions — the agent's working memory of every chat | Travels |
~/.openclaw/state/ | openclaw.sqlite + session state — the durable brain | Travels |
~/.openclaw/openclaw.json | Gateway + channel + model config | Travels — API keys, bot tokens and gateway auth stripped first |
~/.openclaw/credentials/ | Channel pairing credentials (WhatsApp, Discord, Signal, Telegram) | Never uploaded — you re-link channels in the VM |
~/.openclaw/.env · secrets.json · agents/*/agent/auth-profiles.json | Provider keys and per-agent auth | Never uploaded — you re-enter keys in the VM |
Relocated your state dir? The transfer honours OPENCLAW_STATE_DIR the same way the agent does.
Why a tarball on the same laptop isn't a backup
The common failure isn't losing the tarball — it's what the tarball contains and where it sits. A cron job that tars ~/.openclaw while the gateway is running can catch openclaw.sqlite mid-write; the archive looks fine until the day you restore it. A backup that includes credentials/ and .env is a full set of bot tokens and API keys sitting in cold storage, on the same disk whose failure you're insuring against.
And even a perfect archive restores to... another machine you have to keep online. OpenClaw is an always-on agent — it bridges your chats around the clock. A laptop that sleeps is the reason to back up and the reason a laptop restore doesn't fix anything.
The restore target that actually matches the workload is an always-on server. Which turns "openclaw backup" into the adjacent question the official doc already answers: migrating is copying the entire state dir to the new machine.
The DIY routes: cron + tar, backup scripts, object storage
All of these are legitimate — here's what each covers and what it leaves on your plate:
Correct scope by definition: the whole ~/.openclaw, exactly what the migration doc prescribes.
Stop the gateway first (mid-write SQLite), keep secrets out of the archive yourself, store it somewhere that isn't the same disk — and restoring still needs a machine that stays on.
Scheduling and packaging, so backups actually happen.
Same secret-handling and restore-target questions; you're now also trusting the tool's scope to stay in sync with OpenClaw's layout.
Off-machine durability — the real point of a backup.
Credentials sync to the bucket unless you exclude them; a live directory syncs mid-write; and a bucket restore is still a manual rebuild of the runtime around the data.
Backup and restore OpenClaw to a cloud VM — one command
`jurniti transfer` implements the official advice — the entire state dir moves as one unit — with the sharp edges handled: secrets are excluded on your machine before packing, and the destination is a dedicated Firecracker microVM with OpenClaw already installed and running. The dry run is free and shows you the exact manifest first:
$ jurniti transfer --harness openclaw --dry-run
Found local OpenClaw state (2298 files, 391.2 MiB).
Transfer manifest — OpenClaw
keep .openclaw/ 2296 file(s) 390.9 MiB
total 2296 file(s), 390.9 MiB
never uploaded (credentials — you'll re-enter keys in the VM):
.openclaw/.env
.openclaw/secrets.json
redacted 5 secret-bearing field(s) in: .openclaw/openclaw.json
sessions: 143 session file(s) travel with you
Dry run — nothing was uploaded. Re-run without --dry-run to transfer.On a real machine everything under credentials/ and any per-agent auth-profiles.json joins the never-uploaded list automatically. Re-run without --dry-run and the CLI confirms, streams the archive straight into your VM (never stored on our servers), applies it, restarts the gateway, and prompts you to re-enter keys. No VM yet? The same command opens checkout and continues after payment.
$ jurniti transfer --harness openclawYour bot tokens and API keys never leave your machine
Everything credential-shaped is excluded client-side, before upload: the credentials/ directory, .env, secrets.json, per-agent auth profiles — and secret fields inside openclaw.json (provider API keys, channel bot tokens, gateway auth) are redacted from the copy that travels. The dry-run manifest lists every exclusion so you can verify before confirming, and an advisory scan flags anything in the remaining files that still looks like a secret.
Inside the VM you re-enter model keys (BYOK — your key lives in your VM, and model traffic never touches jurniti) and re-link chat channels fresh. Fresh pairing on the VM also means your laptop's session can't fight the VM's over the same channel identity.
What $25/mo buys that a $10 VPS doesn't
A $10 VPS plus the official migrate doc genuinely works — that's the honest baseline. The Starter plan buys the parts around the copy: a dedicated Firecracker microVM (hardware isolation, not a shared container — this thing holds your chat history), OpenClaw installed and kept running for you, and the backup-restore itself as one verified command with the secret-scrubbing already done, instead of a checklist you re-execute at midnight when the laptop dies.
Flat monthly, no metering, and a 30-day money-back guarantee on your first purchase — if it isn't worth it, email us and we refund you.
Your own Firecracker microVM with OpenClaw installed, provisioned ~3 minutes after payment — then one command moves your state in. Not worth it within 30 days? Email us and we refund you.
OpenClaw backup — questions
How do I back up OpenClaw?
Copy the entire state directory (~/.openclaw, or $OPENCLAW_STATE_DIR) — that's the official guidance, and partial copies are how restores break. `jurniti transfer` does exactly that, minus credentials, into a VM where OpenClaw is already running.
What does an OpenClaw backup need to include?
All of it: sessions/, state/ (including openclaw.sqlite), openclaw.json, and the workspace. The interdependence is the point — the config references the state, the state references the sessions.
How do I migrate OpenClaw to another server?
Same mechanism as backup: move the whole state dir to the new machine and start the gateway there. The transfer command streams it into a jurniti VM in one step and restarts the gateway for you.
Do my bot tokens and API keys move with the backup?
No — never. credentials/, .env, secrets.json and per-agent auth profiles are excluded before packing, and key fields inside openclaw.json are redacted. You re-enter keys inside the VM.
Will my WhatsApp / Discord / Telegram pairing survive the move?
Channel pairing credentials deliberately don't travel (they're secrets). After the restore you re-link each channel from the VM — a few minutes per channel, and it guarantees your laptop and VM never contend for the same pairing.
What happens if the transfer fails halfway?
Your laptop's state is never modified — the CLI works on a temp copy. On the VM the apply is staged: if a step fails, your VM's previous state is restored from backup and the CLI tells you exactly what to re-run.
Does the dry run upload anything?
Nothing. --dry-run detects your local state, prints the manifest (kept, redacted, never-uploaded), and exits. It doesn't even require an account.