Files

T

hanzo-dev 0fa6a33a93 Eradicate OpenClaw — resolve merge conflicts and finish the rebrand

Three coordinated things:

1. Resolve the committed upstream/main merge conflicts. 94 files were
   sitting with raw <<<<<<< HEAD ... >>>>>>> upstream/main blocks. Every
   conflict had HanzoBot/Bot on HEAD and OpenClaw on upstream. Resolved
   by keeping HEAD everywhere — 540 conflict blocks.

2. Rewrite remaining OpenClaw text refs.
     OPENCLAW   → HANZO_BOT
     OpenClaw   → HanzoBot          (PascalCase type identifiers)
     openclaw   → bot               (codebase convention — botToken,
                                    botUsername etc.; avoids invalid
                                    hyphenated JS identifiers)
     openclaw[_]/openclaw[A-Z] → bot[_]/bot[A-Z]   (compound)
     ai.openclaw.x → ai.hanzo.bot.x  (JVM package path)

3. Delete or rename openclaw-named file paths (116 of them). Dead
   duplicates with a Bot-named canonical from the partial migration:
   deleted. Otherwise renamed.
     ai/openclaw/**           → deleted (ai/hanzo/bot/** canonical)
     Sources/OpenClaw*/       → deleted (Sources/Bot* canonical)
     Tests/OpenClawIPCTests/  → deleted (Tests/BotIPCTests canonical)
     OpenClawKit/             → deleted (BotKit canonical)
     openclaw-tools.*.ts      → deleted (bot-tools.*.ts canonical)
     openclaw-root.ts etc.    → deleted (bot-root.ts canonical)
     types.openclaw.ts        → deleted (types.bot.ts canonical)
     extensions/*/openclaw.plugin.json → renamed hanzo-bot.plugin.json
     docs/start/openclaw.md   → renamed hanzo-bot.md (+ zh-CN)
     docs/assets/openclaw-*.png, whatsapp-openclaw*.jpg → deleted
     scripts/.../openclaw-*   → deleted (bot/hanzo-bot parallels)
     openclaw.mjs             → deleted (hanzo-bot.mjs is package.bin)

Then patched 65 broken JS/TS import strings where hanzo-bot had ended
up inside an import path ('./types.hanzo-bot.js' → './types.bot.js'
etc., since the on-disk filename uses the brand-neutral bot- prefix).

Pre-existing lint debt cleaned up to get oxlint --type-aware to 0/0:
removed the dead i18n test that referenced a path no longer existing;
defined the missing DIDConfig and WalletConfig types in types.base.ts
(they were imported but never declared); dropped unused imports;
collapsed redundant type assertion and a tautological meta.bot lookup
that the openclaw→bot rename made redundant.

The a2ui.bundle.js generated artifact is kept at its pre-rebrand
contents — it gets regenerated by 'pnpm canvas:a2ui:bundle' from
sources I cannot rebuild in this commit; the source side is clean.

Verified: 0 occurrences of openclaw (case-insensitive) in tree source
content, 0 file or directory paths with openclaw in the name; oxlint
--type-aware src test reports 0/0.

2026-05-11 17:56:29 -07:00

3.7 KiB

Raw Permalink Blame History

summary, read_when, title

summary

read_when

title

VPS hosting hub for HanzoBot (Oracle/Fly/Hetzner/GCP/exe.dev)

You want to run the Gateway in the cloud

You need a quick map of VPS/hosting guides

VPS Hosting

VPS hosting

This hub links to the supported VPS/hosting guides and explains how cloud deployments work at a high level.

Pick a provider

Railway (one‑click + browser setup): Railway
Northflank (one‑click + browser setup): Northflank
Oracle Cloud (Always Free): Oracle — $0/month (Always Free, ARM; capacity/signup can be finicky)
Fly.io: Fly.io
Hetzner (Docker): Hetzner
GCP (Compute Engine): GCP
exe.dev (VM + HTTPS proxy): exe.dev
AWS (EC2/Lightsail/free tier): works well too. Video guide: https://x.com/techfrenAJ/status/2014934471095812547

How cloud setups work

The Gateway runs on the VPS and owns state + workspace.
You connect from your laptop/phone via the Control UI or Tailscale/SSH.
Treat the VPS as the source of truth and back up the state + workspace.
Secure default: keep the Gateway on loopback and access it via SSH tunnel or Tailscale Serve. If you bind to lan/tailnet, require gateway.auth.token or gateway.auth.password.

Remote access: Gateway remote
Platforms hub: Platforms

Shared company agent on a VPS

This is a valid setup when the users are in one trust boundary (for example one company team), and the agent is business-only.

Keep it on a dedicated runtime (VPS/VM/container + dedicated OS user/accounts).
Do not sign that runtime into personal Apple/Google accounts or personal browser/password-manager profiles.
If users are adversarial to each other, split by gateway/host/OS user.

Security model details: Security

Using nodes with a VPS

You can keep the Gateway in the cloud and pair nodes on your local devices (Mac/iOS/Android/headless). Nodes provide local screen/camera/canvas and system.run capabilities while the Gateway stays in the cloud.

Docs: Nodes, Nodes CLI

Startup tuning for small VMs and ARM hosts

If CLI commands feel slow on low-power VMs (or ARM hosts), enable Node's module compile cache:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/hanzo-bot-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/hanzo-bot-compile-cache
mkdir -p /var/tmp/hanzo-bot-compile-cache
export BOT_NO_RESPAWN=1
EOF
source ~/.bashrc

NODE_COMPILE_CACHE improves repeated command startup times.
BOT_NO_RESPAWN=1 avoids extra startup overhead from a self-respawn path.
First command run warms cache; subsequent runs are faster.
For Raspberry Pi specifics, see Raspberry Pi.

systemd tuning checklist (optional)

For VM hosts using systemd, consider:

Add service env for stable startup path:
- BOT_NO_RESPAWN=1
- NODE_COMPILE_CACHE=/var/tmp/hanzo-bot-compile-cache
Keep restart behavior explicit:
- Restart=always
- RestartSec=2
- TimeoutStartSec=90
Prefer SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties.

Example:

sudo systemctl edit hanzo-bot

[Service]
Environment=BOT_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/hanzo-bot-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90

How Restart= policies help automated recovery: systemd can automate service recovery.

3.7 KiB Raw Permalink Blame History Unescape Escape