---
title: What the cloud adds
description: What connecting a node to ClawMetry Cloud gives you — a dashboard from anywhere, multi-node fleet, phone approvals, the device display — and what it does not.
keywords: ClawMetry cloud, agent dashboard remote, multi node agent fleet, phone approvals
eyebrow: Cloud & fleet
---

# What the cloud adds

Compute stays local. The daemon still reads every runtime, computes every
rollup and runs every detector on your machine. Connecting adds one thing: an
encrypted snapshot is pushed so you can look at it from somewhere else.

```bash
clawmetry connect --key cm_xxx
```

## What you get

**A dashboard from anywhere.** The same views, on a device that is not the one
running the agents.

**Multi-node fleet.** Every connected node in one place — the roster, the spend,
the health, the incidents. On more than one machine this is the whole reason to
connect. → [Nodes and fleet](/docs/cloud/nodes/)

**Phone approvals.** A pending approval reaches your phone as a push and can be
decided from the lock screen. The relay is a long poll, so the decision reaches
the waiting agent in seconds. → [Approvals](/docs/guard/approvals/)

**The device display.** A small always-on display showing live agent status, fed
by the plaintext counters.

**Alerts that leave the machine.** A webhook from a laptop that is asleep does
not fire. A cloud-side alert does.

## What it does not change

- **Detection and enforcement stay local.** Guard runs in the daemon on your
  machine. The cloud does not decide to pause your agent.
- **Your store stays local.** The DuckDB file is unchanged. Disconnecting leaves
  your entire history where it is.
- **The runtimes are unaffected.** Nothing about connecting changes what is read
  or how.
- **The server cannot read your sessions.** Content is encrypted before it
  leaves. → [End-to-end encryption](/docs/cloud/encryption/)

## The two kinds of data

| Kind | Examples | On the wire |
|---|---|---|
| Aggregate counters | cost totals, session counts, health status, node liveness | Plaintext, so a summary and the device can render without your key |
| Content | transcripts, events, tool arguments, spans, search text | AES-256-GCM ciphertext the server cannot read |

Which shapes are which is declared in the [query contract](/docs/data/query-api/)
as a trust class, not decided per push — so a content-bearing shape cannot
accidentally end up on a plaintext list.

## Turning it off

```bash
clawmetry disconnect
```

Stops sync and removes the key. Your local store is untouched and the dashboard
keeps working.

To make a node permanently local:

```bash
clawmetry onboard --local
```

That writes a marker a later `connect` will refuse to override without
`--force` — so a provisioning script cannot quietly opt a machine back in.

## Self-hosting the endpoint

You can run the ingest endpoint yourself and have nodes push to it instead.

```bash
CLAWMETRY_ENDPOINT=https://clawmetry.internal.example.com clawmetry connect --key ...
```

→ [Self-hosted ingest](/docs/cloud/self-hosted/)

## Checking the connection

```bash
clawmetry status --json | jq '{cloud, node_id, endpoint, last_push}'
curl -s localhost:8900/api/cloud-status | jq
curl -s localhost:8900/api/sync-progress | jq
```

The first sync of a long history takes a while; `sync-progress` is what tells
you how far it has got rather than leaving you guessing.

## Tier

`cloud_sync` and `fleet` are Starter-and-above features.