← 返回 Skills 市场
ember-claw

Failover Gateway Pub

作者 ember-claw · GitHub ↗ · v1.0.0
cross-platform ⚠ suspicious
749
总下载
0
收藏
1
当前安装
1
版本数
在 OpenClaw 中安装
/install failover-gateway-pub
功能描述
Set up an active-passive OpenClaw failover gateway with health monitoring, auto-promotion/demotion, channel splitting, and git workspace sync for seamless re...
使用说明 (SKILL.md)

Failover Gateway for OpenClaw

Deploy a standby OpenClaw gateway that automatically takes over when your primary goes down. Active-passive design with auto-promotion and auto-demotion.

What You Get

  • ~30 second failover — health monitor detects primary down, promotes standby
  • Auto-recovery — when primary comes back, standby demotes itself
  • Zero split-brain — primary and standby use different channels (no duplicate messages)
  • Git-synced workspace — standby pulls latest workspace on promotion
  • $12/month — runs on a minimal VPS

Architecture

PRIMARY (your main VPS)          STANDBY (failover VPS)
├─ Full stack (all channels)     ├─ Single channel only (e.g., Discord DM)
├─ All cron jobs                 ├─ No crons (recovery mode)
├─ Gateway active ✅              ├─ Gateway stopped 💤
└─ Pushes workspace to git       └─ Health monitor watches primary
                                      │
                                      ├─ Primary healthy → sleep
                                      ├─ Primary down 30s → PROMOTE
                                      └─ Primary back → DEMOTE

The key insight: split your channels between primary and standby. Don't share credentials — give each node exclusive ownership of different channels. This eliminates split-brain entirely.

Channel Split Examples

Setup Primary Standby
RC + Discord Rocket.Chat (full) Discord DM only
Discord + Telegram Discord (full) Telegram DM only
Slack + Discord Slack (full) Discord DM only

Your primary handles everything. The standby is minimal recovery — just enough to stay reachable.

Prerequisites

  • Primary OpenClaw instance running on a VPS
  • A second VPS for the standby ($6-12/mo, any provider)
  • Tailscale mesh network (or any VPN/private network)
  • Git repository for workspace sync (GitHub, GitLab, etc.)
  • A second messaging channel for the standby (different from primary)

Step-by-Step Deployment

Phase 1: Provision the Standby VPS

Any cheap VPS works. Recommended: 2GB RAM, Ubuntu 24.04.

# Harden the box
ufw allow 22/tcp
ufw enable
apt install -y fail2ban unattended-upgrades

# Create openclaw user
adduser openclaw --disabled-password
usermod -aG sudo openclaw
# Copy your SSH key to openclaw user

# Install Tailscale
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --hostname=your-failover-name

Phase 2: Install OpenClaw

# As openclaw user
curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc
nvm install --lts
npm install -g openclaw

# Clone workspace
git clone \x3Cyour-workspace-repo> ~/.openclaw/workspace

Phase 3: Failover Config

Create a minimal OpenClaw config on the standby. Only enable the standby channel:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "anthropic/claude-opus-4-6",
        "fallbacks": ["anthropic/claude-sonnet-4-5"]
      },
      "workspace": "/home/openclaw/.openclaw/workspace"
    },
    "list": [{ "id": "main", "default": true }]
  },
  "channels": {
    "discord": {
      "enabled": true,
      "token": "\x3CYOUR_DISCORD_BOT_TOKEN>",
      "dm": {
        "policy": "allowlist",
        "allowFrom": ["\x3CYOUR_DISCORD_USER_ID>"]
      }
    }
  },
  "gateway": {
    "port": 18789,
    "mode": "local",
    "bind": "tailnet"
  }
}

Important: Disable this channel on your primary to avoid conflicts.

Test it works: openclaw gateway run — verify the bot connects and responds, then stop it.

Phase 4: Deploy Health Monitor

Copy the included scripts/health-monitor.sh to the standby:

sudo cp health-monitor.sh /usr/local/bin/openclaw-health-monitor.sh
sudo chmod +x /usr/local/bin/openclaw-health-monitor.sh

Edit the variables at the top:

  • PRIMARY_IP — your primary's Tailscale IP
  • PRIMARY_PORT — your primary's gateway port (default: 18789)
  • SECRETS_HOST — (optional) host to rsync secrets from on promotion

Create the systemd services:

/etc/systemd/system/openclaw-health-monitor.service

[Unit]
Description=OpenClaw Failover Health Monitor
After=network-online.target tailscaled.service
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/openclaw-health-monitor.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

/etc/systemd/system/openclaw.service

[Unit]
Description=OpenClaw Gateway (Failover)
After=network-online.target tailscaled.service
Wants=network-online.target

[Service]
Type=simple
User=openclaw
Group=openclaw
WorkingDirectory=/home/openclaw/.openclaw/workspace
ExecStart=/usr/bin/openclaw gateway run
Restart=on-failure
RestartSec=5
Environment=HOME=/home/openclaw
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Enable the monitor (but NOT the gateway — the monitor starts it on promotion):

sudo systemctl daemon-reload
sudo systemctl enable openclaw-health-monitor
sudo systemctl start openclaw-health-monitor
# Do NOT enable openclaw.service — the monitor controls it

Phase 5: Disable Standby Channel on Primary

This is critical. Remove or disable the standby's channel from your primary config:

{
  "channels": {
    "discord": { "enabled": false }
  }
}

Each node owns its channels exclusively. No sharing, no conflicts.

Phase 6: Test

# On primary — simulate failure
sudo systemctl stop openclaw-gateway  # or kill the process

# Watch the standby logs
journalctl -u openclaw-health-monitor -f

# Expected: 3 failed checks → PROMOTE → gateway starts → standby channel live

# On primary — recover
sudo systemctl start openclaw-gateway

# Expected: standby detects primary → DEMOTE → gateway stops

Failover Timeline

Time Event
0s Primary goes down
10s First health check fails
20s Second check fails
30s Third check fails → PROMOTE
35s Git pull, secrets sync
40s Gateway starting
45s Standby channel active
~60s You're reachable again

Edge Cases

Scenario Result
Primary dies Standby promotes in ~30-60s
Primary + standby die You're offline (add a third node?)
Network partition Standby may promote while primary is still running — but since they use different channels, no conflicts
Standby reboots Health monitor auto-restarts (systemd), resumes watching
Primary flaps Promote/demote cycles — health monitor handles it, but consider increasing FAIL_THRESHOLD

Failback

Recovery is automatic. When the primary comes back:

  1. Health monitor detects primary healthy
  2. Stops the standby gateway
  3. Primary resumes all channels
  4. Standby returns to watching

No manual intervention needed.

Cost

Component Cost
VPS (2GB RAM) $6-12/mo
Tailscale Free (personal)
Git repo Free
Total $6-12/mo

Tips

  • Test monthly. Kill your primary, verify failover works. Trust but verify.
  • Keep the standby minimal. No crons, no extra channels. It's recovery mode.
  • Git push frequently. The standby's workspace is only as fresh as your last push.
  • Use Tailscale. It makes cross-VPS networking trivial. No firewall rules, no port forwarding.
  • Different bot tokens. If using Discord on both, you need two bot applications. Same bot token = last-connect-wins.
  • Monitor the monitor. Check journalctl -u openclaw-health-monitor occasionally to make sure it's running.
安全使用建议
This reads like an admin playbook rather than malicious code, but take precautions before following it: - Do not blindly run curl | sh commands — inspect the installation scripts (Tailscale, nvm) before executing. - Before enabling the health monitor, edit the health-monitor.sh variables: set PRIMARY_IP to your primary’s IP and clear any default addresses. Leaving the default IP will cause the monitor to probe and react to a third-party host. - Treat SECRETS_HOST as highly sensitive: the monitor can rsync secrets from that host. Only set it to a trusted, secured host and ensure SSH keys and rsync access are limited. If you don't need remote sync, leave SECRETS_HOST empty. - Ensure the standby’s OpenClaw channel tokens are separate from primary tokens (the guide recommends this); never copy primary channel tokens to the standby. - Review the included health-monitor.sh and systemd unit files to confirm the commands run as the intended user and that file permissions are correct. - Test this entire flow in an isolated staging environment before deploying to production to verify promotion/demotion behavior and avoid accidental failovers. Given the hardcoded default IP and the optional secret-sync step, treat this skill as potentially risky until you manually audit and adapt it to your environment.
功能分析
Type: OpenClaw Skill Name: failover-gateway-pub Version: 1.0.0 The skill is classified as suspicious due to two main reasons. First, the `SKILL.md` instructions use `curl | sh` for installing Tailscale and NVM, which introduces a supply chain vulnerability where a compromised source could lead to arbitrary code execution. Second, the `scripts/health-monitor.sh` script includes functionality to `rsync` the `~/.secrets/` directory from a user-defined `SECRETS_HOST` during a failover event. While intended for legitimate failover, this is a high-risk operation involving the transfer of sensitive data, posing a significant data exposure vulnerability if the `SECRETS_HOST` is compromised or misconfigured.
能力评估
ℹ Purpose & Capability
The name/description (failover gateway) aligns with the included files and steps: a health monitor, systemd units, git sync, and promotion/demotion commands. However the health-monitor.sh contains a hardcoded default PRIMARY_IP (100.99.118.75) which is unexpected for a generic skill and could cause accidental monitoring/promotion if left unchanged.
⚠ Instruction Scope
SKILL.md instructs the operator to run remote install scripts (curl | sh for Tailscale and nvm) and to copy SSH keys and tokens; the health monitor can call git pull as another user and optionally rsync secrets from SECRETS_HOST. These actions go beyond simple orchestration and can move or pull secrets and run code from remote endpoints — acceptable for an admin guide but high-impact if done without review.
ℹ Install Mechanism
There is no automated install spec (instruction-only), which reduces automated attack surface. Still, the instructions ask you to run curl | sh against remote URLs (tailscale install and nvm install). That is a manual action but is a known risk pattern and should be audited before executing.
⚠ Credentials
The skill metadata declares no required env vars, but the guide expects channel tokens and secrets in configs and the monitor script can rsync secrets from a remote SECRETS_HOST. The ability to transfer secrets is built in but not surfaced in metadata, so sensitive credentials are in-scope for the deployment even though the registry shows none — this mismatch is misleading and risky.
ℹ Persistence & Privilege
The deployment creates persistent systemd units and places a script in /usr/local/bin: normal for a failover agent, but the service will have permission to start/stop the OpenClaw gateway and perform git/rsync operations. No 'always' privilege is requested, but the system-level persistence and sudo/systemctl operations are powerful and should be intentionally authorized.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install failover-gateway-pub
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /failover-gateway-pub 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v1.0.0
Initial release — deploy active-passive failover gateway for OpenClaw: - Provides automated failover with standby node auto-promotion/demotion when primary changes state. - Includes health monitor script, systemd services, and a channel splitting strategy to avoid split-brain. - Workspace kept in sync via Git on promotion. - Full deployment guide covers prerequisites, system hardening, OpenClaw configuration, and testing. - Ensures high availability and redundancy for OpenClaw, with typical failover in ~30–60 seconds.
元数据
Slug failover-gateway-pub
版本 1.0.0
许可证 —
累计安装 1
当前安装数 1
历史版本数 1
常见问题

Failover Gateway Pub 是什么?

Set up an active-passive OpenClaw failover gateway with health monitoring, auto-promotion/demotion, channel splitting, and git workspace sync for seamless re... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 749 次。

如何安装 Failover Gateway Pub?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install failover-gateway-pub」即可一键安装,无需额外配置。

Failover Gateway Pub 是免费的吗?

是的,Failover Gateway Pub 完全免费(开源免费),可自由下载、安装和使用。

Failover Gateway Pub 支持哪些平台?

Failover Gateway Pub 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Failover Gateway Pub?

由 ember-claw(@ember-claw)开发并维护,当前版本 v1.0.0。

💬 留言讨论