Install CrashPilotX

Create an API key

On the Systems page, create an API key. It is shown once, with your endpoint and public key filled in:

export CRASHPILOT_URL='https://<project>.supabase.co'
export CRASHPILOT_ANON_KEY='<public anon key>'
export CRASHPILOT_API_KEY='cpk_...'

When you create a key, choose what it may do: add and retire systems, read fleet health, or both. A key made only to read health, for a status page or a monitoring check, cannot change anything. A key that adds systems receives the agent credentials of every system it adds, which is enough to report as that system, so keep it in a secret store. No key can read reports, alert text, or settings. What a key may do is fixed when it is created; to change it, revoke the key and create another. Revoking stops it at once.

Add a system

jq -n \
  '{p_api_key: env.CRASHPILOT_API_KEY, p_name: "web-7", p_external_id: "i-0abc123", p_labels: ["web", "prod"]}' |
  curl --fail-with-body -sS "$CRASHPILOT_URL/rest/v1/rpc/api_create_system" \
    -H "apikey: $CRASHPILOT_ANON_KEY" -H "Content-Type: application/json" -d @- > system.json

The response carries the new system's credentials, with HTTP 201:

{
  "system_id": "6f1c0d9e-...",
  "agent_token": "...",
  "name": "web-7",
  "created": true,
  "restored": false
}

Only p_name is required. Pass p_external_id, such as an instance ID, to make the call safe to retry: the same identity always gets the same system back with fresh credentials and HTTP 200, and a retired one returns with "restored": true. The name and up to 12 labels apply only when the system is first created.

Connect the machine

CONN="cpilot_$(jq -c --arg url "$CRASHPILOT_URL" --arg key "$CRASHPILOT_ANON_KEY" \
  '{url: $url, key: $key, system_id: .system_id, token: .agent_token}' system.json | base64 -w0)"

# Hand $CONN to the machine, for example in its cloud-init user-data, and run
# there as root. Through the environment it stays out of process arguments.
curl -fsSL https://crashpilotx.com/install.sh | CRASHPILOT_CONNECT="$CONN" bash

Retire it when it goes away

jq -n '{p_api_key: env.CRASHPILOT_API_KEY, p_external_id: "i-0abc123"}' |
  curl --fail-with-body -sS "$CRASHPILOT_URL/rest/v1/rpc/api_retire_system" \
    -H "apikey: $CRASHPILOT_ANON_KEY" -H "Content-Type: application/json" -d @-

Pass p_external_id or p_system_id. It works like Retire on the Systems page: the system leaves the fleet, its credentials stop working, and its history is kept until retention ends. It also retires machines that enrolled themselves, by the identity they enrolled under, such as aws:i-0abc123 or k8s:node-name, so a termination hook can retire an instance the moment it goes. Retiring twice is not an error.

Read fleet health, for a status page or a monitoring check

jq -n '{p_api_key: env.CRASHPILOT_API_KEY}' |
  curl --fail-with-body -sS "$CRASHPILOT_URL/rest/v1/rpc/api_system_health" \
    -H "apikey: $CRASHPILOT_ANON_KEY" -H "Content-Type: application/json" -d @-

# One system, by the identity it enrolled or was added under:
jq -n '{p_api_key: env.CRASHPILOT_API_KEY, p_external_id: "i-0abc123"}' |
  curl --fail-with-body -sS "$CRASHPILOT_URL/rest/v1/rpc/api_system_health" \
    -H "apikey: $CRASHPILOT_ANON_KEY" -H "Content-Type: application/json" -d @-

It answers with the whole fleet, or the one system you asked for:

{
  "fleet": { "total": 3, "online": 2, "offline": 1, "signed_off": 0, "retired": 0 },
  "systems": [
    {
      "system_id": "6f1c0d9e-...",
      "name": "web-7",
      "external_id": "i-0abc123",
      "labels": ["web", "prod"],
      "ephemeral": false,
      "status": "online",
      "last_heartbeat": "2026-09-12T12:30:30Z",
      "seconds_since_heartbeat": 42,
      "hostname": "web-7",
      "agent_version": "0.2.0",
      "maintenance_until": null,
      "signed_off_at": null,
      "retired_at": null,
      "retired_reason": null,
      "open_alerts": { "warning": 1 },
      "last_crash_at": "2026-09-01T03:12:00Z"
    }
  ]
}

Only a key created with health reads may call this; any other gets 403 scope_required, just as a key made only to read health gets it from the add and retire calls. status is one of online, signed_off (shut down cleanly), offline and retired, worked out the same way the dashboard does. Retired systems are left out unless you pass p_include_retired or ask for one by name.