Why DeepClaw Uses a Push Model

Most monitoring dashboards start with a pull model: the dashboard connects to your server, asks for metrics, and repeats that forever. That can work when you already run private networking, VPNs, firewall rules, service discovery, and a security team that enjoys debugging tunnels.

DeepClaw is built for a different reality: small teams running OpenClaw on VPS machines, shipping fast, and trying not to create a new attack surface just to understand what their AI gateway is doing.

For that environment, push-based monitoring is the safer default.

Pull monitoring adds operational risk

A pull-based dashboard needs some path into the machine it observes. That usually means one of three things:

exposing a public metrics endpoint,
maintaining a VPN, tunnel, or reverse proxy,
or giving a third-party service credentials that can reach internal infrastructure.

Each option can be made safe, but none of them are free. They add setup work, failure modes, and another thing to rotate when access changes.

For AI gateway monitoring, that tradeoff is often unnecessary. The data DeepClaw needs is already known locally: sessions, models, token counts, cron status, cost estimates, and basic health signals. The gateway can summarize that state and send it out.

Push keeps the VPS private

DeepClaw uses a push model. A small sync agent runs on the VPS and periodically sends a snapshot to the DeepClaw API over HTTPS.

export DEEPCLAW_API_URL="https://app.deep-claw.com"
export DEEPCLAW_SYNC_TOKEN="***"
python3 sync-to-deepclaw.py

The dashboard never opens a connection back into the VPS. There are no inbound firewall changes. If the agent stops, DeepClaw marks the instance stale instead of trying to reach into your machine.

That makes the security boundary easier to reason about:

the VPS initiates outbound HTTPS only,
the token is scoped to one instance,
revoking the token cuts off future syncs,
DeepClaw receives operational snapshots, not raw shell access,
and DeepClaw cannot execute commands on the gateway.

Outbound-only is easier to adopt

Security is not the only reason push works well for OpenClaw operators. It also reduces setup friction.

A pull-based monitoring setup often turns into infrastructure work before it delivers value: open a port, configure TLS, add firewall rules, set up a tunnel, test connectivity from the monitoring service, then keep the path alive.

A push agent has a simpler contract:

install the sync script,
add the instance token,
run it on a schedule,
watch the dashboard update.

That matters for self-hosted AI operations. The first useful visibility should not require redesigning the network.

What gets synced

The sync payload is intentionally operational, not omniscient. DeepClaw focuses on the questions an operator asks every day:

Is the gateway alive?
Which models are being used?
Are sessions growing, failing, or becoming more expensive?
Are costs moving in the wrong direction?
Did scheduled jobs run recently?
Are there suspicious surface-level security signals?

That gives you the dashboard view without turning monitoring into remote administration.

The model is also privacy-conscious by default. DeepClaw does not need raw prompts or provider secrets to show whether the gateway is healthy, stale, expensive, or drifting away from baseline.

Failure modes are clearer

Push monitoring has simple failure semantics. If the VPS cannot reach the internet, sync stops. If the token is wrong, sync fails. If the cron job stops running, the instance becomes stale.

Those are operationally understandable states. The dashboard can show the last successful sync, expected interval, and stale status without needing privileged access back into the server.

A pull setup can fail in more confusing ways: DNS, firewall rules, tunnels, TLS certificates, network ACLs, endpoint auth, and monitoring service reachability can all become part of the debugging path.

The tradeoff

Push monitoring is not magic. If the VPS has no outbound network, DeepClaw cannot see new data. If the sync token is revoked or wrong, the dashboard goes stale. If you need second-by-second metrics, a five-minute cron interval is the wrong tool.

But for most OpenClaw deployments, the tradeoff is right: simple install, low privilege, no inbound ports, and enough observability to catch problems before users notice.

The principle

DeepClaw should make AI operations clearer without making infrastructure more fragile. Push-based monitoring is one of the ways we keep that promise.

Your OpenClaw gateway stays private. DeepClaw gets the operational signal it needs. And the first step toward visibility remains a safe outbound sync, not a new inbound attack surface.