Setup

Pairing and devices

Attach the webclient and Browser Bridge to your server, verify identity, and manage paired devices.

Pairing attaches a client to your server. Clients render and actuate; they never run recipes and never hold your warehouse or your account credentials. Pairing is server-direct — the cloud is not on the pairing path.

#Pair the webclient

The webclient is a thin app at app.recued.com; your server also serves a bundled copy at http://127.0.0.1:<port>/webclient/, which is the address the boot log prints. On the server machine that copy pairs with no certificate and no internet connection. To reach it from another device on your network, see Reachability. To pair:

  1. Read the address and single-use code from the active server's boot log.
  2. Open the webclient and enter the server address and, on a fresh server, the pairing code.
  3. Complete the recovery-key flow.
  4. Compare the server identity shown on both sides before accepting.

The first-run pairing code belongs to the active server process and expires after 15 minutes. If it expires, restart that process with the same database and configuration and use the new boot-log code. A code printed by a separate standalone process is not active in the running server.

Pairing grants the client a narrow, revocable token. It does not move your data.

The recovery key does two jobs. It authorizes attaching clients to your server, and from the first pairing onward it restores the data your server encrypts: that first pairing turns on at-rest encryption, the server unlocks itself at each boot from its own key file, and the recovery key is the only other thing that can unwrap the same master key. Store it offline, and not only on the machine it protects — anyone who has it can pair a client, and losing it together with the server's key file makes encrypted data unrecoverable. The same code opens your backup archives — see Backup and restore.

#Pair the Browser Bridge

The Browser Bridge is a browser extension with a deliberately narrow job: it observes declared DOM triggers, performs page reads and actions on live sites, and raises operating-system notifications — all on the server's behalf. It executes only signed commands from your server and holds no engine state.

Install the extension and pair it the same way as the webclient. A Bridge is required only for recipes that watch or act on a live browser page, or send an operating-system notification through the Bridge. Everything else runs without one, and a recipe that needs a Bridge says so before it runs rather than failing midway.

#What paired clients receive

Every paired client subscribes to the server's realtime broadcast — execution progress, approvals, warehouse changes, schedule state — and renders it live. The broadcast carries state to the client's screen; the authority over that state stays on the server.

#Manage devices

The Devices page lists every paired client. Revoke any entry to invalidate that client's token immediately; re-pairing later issues a fresh one. Revoking a Bridge also stops recipes that depend on it from performing page actions until a Bridge is paired again.

#Next

Decide whether your server needs a public name in Reachability.

Recued is local first; your server remains the authority.

Recued Docs

Search documentation

Start typing to search the documentation.