OpenClaw Gateway Migration:
Mac to Synology NAS

Overview

Migrated the OpenClaw gateway from a Mac ("Slice") to a Synology NAS DS224+ ("EdgeBox") so that the Felix5 agent runs fully independently, with no dependency on any other device.

Before

After

Hardware & Software

Phase-by-Phase Walkthrough

Phase 1 — Research

Finding: OpenClaw's gateway is a Node.js daemon with no hard macOS dependencies. The macOS companion app is Mac-only, but the gateway itself works identically on Linux.

Key resources:

• OpenClaw Linux Platform Docs
• openclawd-termux — headless gateway on Android
• Docker Install Guide

Phase 2 — Install Gateway on NAS

Created dedicated user (<gateway-user>) to keep agent actions separate from the agent's own user, maintaining clean audit logs.

Config files created:

1. ~/.openclaw/openclaw.json — Main gateway config
2. ~/.openclaw/agents/main/agent/auth-profiles.json — Anthropic API key
3. ~/.openclaw/credentials/slack-allowFrom.json — Slack user whitelist
4. ~/boot-gateway.sh — DSM Task Scheduler watchdog script

All credential files set to chmod 600 (owner-read/write only), scripts to chmod 700 (owner-execute only).

Phase 3 — Migrate Slack Integration

Gateway log confirmed connection:

[slack] [default] starting provider
[slack] socket mode connected

Phase 4 — Configure Local Exec

Config set "exec.host": "gateway" which runs the agent embedded in the gateway process. No separate node needed.

Phase 5 — Validation

Felix5 ran a comprehensive 5-test suite:

Resource usage: ~390MB RAM (3.9% of 9.6GB), CPU load 0.10, 2.3TB disk free

Phase 6 — Cutover

1. Stopped old node on NAS
2. Unloaded Mac LaunchAgent
3. Mac gateway stopped
4. Felix5 confirmed independence via Slack

Post-Migration: Skill Credential Setup

Skills like Moltbook have their own credentials, separate from the gateway's API keys and Slack tokens. These are not migrated automatically — they need to be set up under the gateway user's home directory on the NAS.

Moltbook Credentials

The Moltbook skill (moltbook-interact) checks two locations in order:

1. ~/.openclaw/auth-profiles.json — looks for a .moltbook.api_key field
2. ~/.config/moltbook/credentials.json — looks for an .api_key field

To set up Moltbook credentials on the NAS:

# Create the credentials file under the gateway user
mkdir -p ~/.config/moltbook
cat > ~/.config/moltbook/credentials.json << 'EOF'
{
  "api_key": "your_moltbook_api_key_here",
  "agent_name": "YourAgentName"
}
EOF
chmod 600 ~/.config/moltbook/credentials.json

Verify the credentials work:

~/.openclaw/workspace/skills/moltbook-interact/scripts/moltbook.sh test
# Should output: ✓ API connection successful

Other Skills

Check each installed skill's INSTALL.md for its credential requirements. The general pattern is the same: create the credential file under the gateway user's home directory, lock permissions to 600, and use DSM Task Scheduler if the restricted shell blocks the write.

Auto-Start on Boot

DSM Task Scheduler configured:

• Task name: OpenClaw Gateway
• User: <gateway-user>
• Event: Boot-up
• Script: ~/boot-gateway.sh

The boot script runs as a watchdog:

• Waits 10 seconds for network on boot
• Starts gateway in foreground within while true loop
• Auto-restarts if gateway exits (15s delay)
• Rotates logs at 5MB
• Prevents duplicate watchdogs via PID file

Management Commands

SSH into NAS:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address>

Check gateway status:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address> \
  'kill -0 $(cat ~/gateway.pid) 2>&1 && echo "Running" || echo "Stopped"'

View logs:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address> 'tail -20 ~/gateway.log'

Restart gateway:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address> \
  'kill $(cat ~/gateway.pid) 2>/dev/null; sleep 3; sh ~/start-gateway.sh'

Security Hardening

Post-migration security review against known OpenClaw/Moltbot vulnerabilities documented by Cisco, Palo Alto Networks, Tenable, Trend Micro, The Register, and others.

Known CVEs

Hardening Applied

1. File permissions locked down

All credential files restricted to owner-only access:

# Config files: owner read/write only
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/.env
chmod 600 ~/.openclaw/credentials/*.json

# Scripts: owner execute only
chmod 700 ~/boot-gateway.sh

Why: OpenClaw stores all credentials in plaintext. Without restrictive permissions, any user could read API keys and tokens.

2. Dedicated user isolation

Gateway runs under <gateway-user>, separate from the agent's own user and admin account.

Why: Provides audit trail separation, limits blast radius if compromised.

3. Slack user allowlist

{
  "groupPolicy": "allowlist",
  "slack-allowFrom.json": { "allowFrom": ["<slack-user-id>"] }
}

Why: Only one Slack user ID can interact. Mitigates prompt injection attacks via Slack.

4. Token-based gateway auth

Gateway requires a shared token for WebSocket connections.

Why: Prevents unauthenticated connections to the control plane, even from LAN devices.

5. Exec command blocklist

Since OpenClaw does not natively support command-level blocklisting, a custom restricted shell wrapper (~/restricted-shell.sh) intercepts all exec commands and blocks dangerous patterns.

Blocked command categories:

How it works:

Monitor blocked commands:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address> 'tail ~/exec-denied.log'

Important limitations:

• Pattern matching is not a sandbox — creative attackers may evade the blocklist
• This is a defence-in-depth layer, not a replacement for allowlist and token auth
• Review and update periodically as new attack patterns emerge
• Admin side-effect: The restricted shell also blocks legitimate file writes (redirect > and tee) when SSHed as the gateway user. To write config files (e.g. skill credentials), use DSM Task Scheduler as root — see Post-Migration: Skill Credential Setup

Current Risk Profile

Recommended Future Hardening

1. Switch to loopback bind (if remote LAN access not needed):

{ "gateway": { "bind": "loopback" } }

Requires SSH tunnel: ssh -N -L 18790:127.0.0.1:18790 <gateway-user>@<nas-ip-address>

2. Review and extend the exec blocklist:

ssh -i ~/.ssh/gateway_nas <gateway-user>@<nas-ip-address> 'tail ~/exec-denied.log'

Monitor for false positives and add new attack patterns as they emerge. If stronger restrictions are needed, switch to OpenClaw's native allowlist mode:

{ "tools": { "exec": { "security": "allowlist" } } }

Note: Allowlist mode is more restrictive and may limit capabilities.

3. Audit installed skills periodically — researchers report 22–26% of public skills contain vulnerabilities.

4. Keep OpenClaw updated — monitor releases and security advisories.

5. Run health check:

openclaw doctor

Security References

• Security Boulevard — 6 Immediate Hardening Steps
• Tenable — Mitigating Agentic AI Vulnerabilities
• The Register — OpenClaw Security Issues
• The Hacker News — CVE-2026-25253
• Cisco — Personal AI Agents Are a Security Nightmare

Success Criteria — All Met

• ☑ Agent responds via Slack with Mac powered off
• ☑ All exec capabilities work (shell, files)
• ☑ Gateway auto-starts on NAS boot
• ☑ No dependency on any other device
• ☑ Web tools functional (search + fetch)
• ☑ Git operations functional
• ☑ Moltbook API operational
• ☑ Rollback procedure documented