openclaw devices approve pairing, and state migration with openclaw backup when you move between Singapore, Tokyo, Seoul, Hong Kong, US East, or US West without rebuilding channels from scratch.
Five misread signatures behind 1008 pairing required and broken migrations
Remote Node work stacks three independent proofs: transport reachability, Gateway process health, and device pairing state. When operators collapse those layers, they rotate Tailscale keys while the real blocker remains an unapproved Node fingerprint. The signatures below map symptoms to the smallest next command so you stop treating every WebSocket failure as firewall folklore.
Tailscale ping success equals OpenClaw paired: MagicDNS only proves the mesh path. Until openclaw devices list shows an approved Node, node run can still close with 1008 pairing required.
Public 18789 exposure is a shortcut: opening the Gateway port on a cloud security group without Serve or tunnel discipline invites scanners and hides whether failures are TLS, Upgrade, or pairing policy.
Copying config JSON preserves channels: tokens, pairing queues, and cached sessions live under the state tree. A partial copy yields green UI with silent drops after migration.
Same hostname after region swap: moving Tokyo to Singapore without reconciling gateway.remote URLs and device profiles leaves Nodes pointed at stale WSS endpoints.
Skipping backup verify: tar archives without checksum validation look fine until doctor reports drift and channels probe fails on the first real message.
Label the signature before you touch release channels or model providers. Pairing problems belong on the master host with devices commands; migration problems belong in a maintenance window with gateway stopped and probes replayed. Cross-read the SSH first-hour checklist if the cloud Mac itself is still unstable, because Node pairing on a flaky daemon only multiplies pending device rows.
Single Gateway on cloud Mac versus Gateway plus remote Node: decision matrix
Not every team needs a remote Node. If all tools run on the same bare-metal cloud Mac that hosts Gateway, pairing is unnecessary overhead. The split becomes valuable when operators want a stable always-on control plane in one metro while heavy browser automation runs on a second Mac with a human nearby, or when compliance demands segregated tool hosts. The matrix is coarse on purpose so platform and app owners align in one meeting.
| Dimension | Gateway-only on cloud Mac | Cloud Mac Gateway + remote Node |
|---|---|---|
| Operational complexity | lowest: one daemon, one state dir | higher: devices approve, two PATH contexts |
| Tool latency | local loopback, best for tight loops | adds RTT over Tailscale or tunnel |
| Security posture | pair channels only | device pairing plus channel pairing layers |
| Migration blast radius | one backup bundle | must not merge Node state into Gateway home |
| Best fit in 2026 | unattended agents, six-region day rent smoke | split heavy tools from 24/7 Gateway |
1008 is not a Tailscale bug. It is Gateway refusing an identity that never received devices approve.
When you choose the split topology, document which host owns channel webhooks versus which host only registers as Node. Mixing those roles on one machine during experiments is fine; production should keep webhook entry on the master and restrict Node hosts to tool execution. For remote URL wiring and port isolation when you run staging beside production, read the Gateway hot reload and multi-instance article before you add a second listener on the same cloud Mac.
Economic framing matters for six-region trials. Day-renting a master in Singapore while keeping a Node on a desk Mac in California can be valid for compliance storytelling, but you should measure tool RTT honestly. If browser steps time out, bringing the Node onto a second cloud Mac in the same metro often costs less than week-long pairing firefights. Capture baseline probe timestamps before you declare the split architecture permanent.
Tailscale Serve gates: loopback Gateway, MagicDNS WSS, devices approve
Recommended 2026 topology keeps Gateway bound to loopback on the master cloud Mac while Tailscale Serve publishes HTTPS to the tailnet only. Nodes connect with gateway.remote aimed at the MagicDNS name, not at a raw public IP on 18789. On the master, install Serve forwarding to 127.0.0.1:18789, confirm WebSocket Upgrade through the Serve path, then start pairing from the Node machine with an explicit remote URL in the environment or profile.
tailscale serve --bg --https=443 http://127.0.0.1:18789 openclaw gateway status openclaw devices list openclaw node run --remote wss://cloud-mac.tailnet-name.ts.net openclaw devices approve <device-id> openclaw backup create --verify openclaw doctor openclaw channels status --probe
When node run still closes with 1008 after Serve works, list pending devices on the master and approve the fingerprint shown in the error text. Community reports around explicit --node-id exist when the CLI cached an old profile; clear stale Node config locally before retrying. Never approve unknown device rows left over from abandoned experiments, or you widen tool execution to random tailnet members.
For migration, stop Gateway gracefully, run backup with verify, rsync the archive to the destination cloud Mac, restore into matching home layout, then run doctor before you start channels. If you only need logical config, still include the state directory in the bundle because pairing queues and OAuth refresh material do not live in a single JSON file. Align maintenance windows with the update and rollback runbook so you do not stack pairing resets on top of channel upgrades.
Note: Archive devices list output before and after approve so audits show who authorized each Node.
Six-step runbook from Tailscale bootstrap to verified migration
Freeze topology on the ticket: record master metro, Node host role, Tailscale tailnet name, and whether channels stay on the master only.
Prove master Gateway on loopback: run gateway status and local curl against 18789 before any Serve publish.
Enable Tailscale Serve to WSS: validate Upgrade through MagicDNS from the Node host with a minimal websocket client or openclaw remote probe.
Pair Node identity: trigger node run, capture 1008 if expected, then devices approve on the master and retry with explicit node id if needed.
Migration window on region change: gateway stop, backup create with verify, secure copy to new cloud Mac, restore, doctor green.
Channel smoke on master: channels status and probe, one live inbound message, compare log timestamps; if silent, read connected but no reply before reopening pairing.
Three on-call guardrails plus cloud Mac hosting for split topologies
Pairing queue ceiling: if more than about eight pending device rows accumulate during a single change window, pause new node run attempts, prune abandoned identities, and re-approve only hosts listed on the ticket.
Migration disk budget: verified backup archives plus restored state often need roughly 1.5 times the live state directory size free on both source and destination; stop browser-heavy jobs below roughly fifteen percent free disk.
Post-migrate probe cadence: run channels probe at least three times across ten minutes after restore before you declare success; transient DNS on new cloud IPs can masquerade as pairing failure.
Warning: Numeric thresholds are communication rails for on-call, not provider SLA promises.
Desk Macs as Node hosts reintroduce sleep, roaming Wi-Fi, and accidental upgrades that desynchronize tool binaries from the master Gateway version. Pure Linux VPS pairs cheap compute with weak macOS-native tool paths. A headless bare-metal cloud Mac as master plus an optional second cloud Mac as Node keeps Apple toolchains colocated, Tailscale Serve on loopback, and migration windows predictable across six regions. MESHLAUNCH Mac Mini cloud rental is usually the stronger operational fit when you need always-on Gateway, auditable device pairing, and region moves without gambling on consumer hardware uptime.
Treat day rent in a target metro as a migration rehearsal, not a commitment. Run the six steps, reboot once inside the window, and only then extend to monthly after channels and Nodes both pass probe. Security reviewers should see Tailscale ACLs documented beside OpenClaw device approvals, with rotation notes stored next to backup checksums. Pricing and support paths live on rental pricing and the help center when you need bare-metal capacity for the rehearsal itself.
On the master cloud Mac run openclaw devices list and approve the pending Node. See headless SSH checklist and pricing.
No. Use openclaw backup with verify and include state directories. After restore follow upgrade rollback runbook. Help: help center.
Run channels probe, then read connected but no reply and Gateway remote wiring before re-pairing devices.