I can log in but cannot reach my self-hosted vault

This means Cloud identity is working, but the self-hosted daemon data path is not ready or not reachable.

Check the local daemon

On the daemon machine:

curl http://127.0.0.1:7382/api/health
curl http://127.0.0.1:7382/api/vaults

If health fails, fix the daemon before debugging Cloud. If the vault list does not include the vault slug in the Cloud URL, you are connected to the wrong KB1_HOME or the vault has not been created/imported on this daemon.

Check relay status

curl http://127.0.0.1:7382/api/relay/status

A healthy relay should include:

{
  "ok": true,
  "relay": {
    "configured": true,
    "started": true,
    "controlConnected": true,
    "reconnectScheduled": false
  }
}

If relay.configured is false, start the daemon with both KB1_RELAY_URL and KB1_RELAY_TOKEN. If relay.started is false, restart the daemon. If relay.controlConnected is false, continue below.

Check Cloud registration

The org must have been born self_hosted.
A cloud-hosted org is not silently flipped into self-hosted mode.
KB1_RELAY_URL must point at the same org id the Cloud URL uses.
KB1_RELAY_TOKEN must be the daemon-scoped key returned for that org.

If the plaintext token was lost, mint a fresh key through the authenticated relay registration path and restart the daemon with the new token.

Check network and process logs

Confirm the daemon machine can reach the API origin in KB1_RELAY_URL.
Look for [relay] lines in daemon logs.
In local dev, rerun pnpm --filter @kb-1-cloud/api seed:dev and then pm2 restart kb1-cloud-dev-daemon.

Done looks like

Local /api/health is green.
Local /api/vaults lists the vault slug.
Local /api/relay/status reports relay.controlConnected: true.
Reopening the Cloud vault URL loads the editor instead of an offline or retry state.