Pairing links a client to your server. A client is a device or app that shows you things and does what your server tells it. Clients never run recipes. They never hold your warehouse or your account secret keys. Pairing goes straight from the client to your server. The cloud is not part of it.
#Pair the webclient
The webclient is a thin app at app.recued.com. Your server also serves
its own copy at http://127.0.0.1:<port>/webclient/. That is the address
the start-up log prints. On the server machine, that copy pairs with no
certificate and no internet. To reach it from another device on your
network, see Reachability. To pair:
- Read the address and the single-use code from the running server's start-up log.
- Open the webclient. Enter the server address. On a fresh server, also enter the pairing code.
- Complete the recovery-key steps.
- Compare the server identity shown on both sides. If they match, accept.
The first pairing code stops working after 15 minutes. Did it run out? Run
recued pair on the server machine. It prints a fresh code, the server's
addresses, and the pairing link. The running server accepts that code.
Need a longer window? Run recued pair --pair-code-ttl 24h. Restarting the
server with the same database and settings also prints a new code in its
start-up log.
Pairing gives the client a limited pass. You can cancel that pass any time. Pairing does not move your data.
#The recovery key
The recovery key is 24 secret words. It does two jobs. First, it lets you link clients to your server. Second, from the first pairing on, it can restore the data your server encrypts. Here is why. The first pairing turns on encryption for data at rest. After that, the server unlocks itself at each start from its own key file. The recovery key is the only other thing that can unwrap the same master key.
Store the recovery key offline. Do not keep it only on the machine it protects. Anyone who has it can pair a client. If you lose both it and the server's key file, the encrypted data cannot be recovered. The same 24 words open your backup archives. See Backup and restore.
#Pair the Browser Bridge
The Browser Bridge is a browser extension. Its job is small on purpose. It watches for page triggers a recipe declared. It reads pages and does actions on live websites. And it shows operating-system notifications. It does all of this for your server. It runs only signed commands from your server. It holds no engine state.
Install the extension. Pair it the same way as the webclient. You only need a Bridge for two kinds of recipe. One kind watches or acts on a live web page. The other sends an operating-system notification through the Bridge. Everything else runs without one. A recipe that needs a Bridge says so before it runs. It does not fail halfway.
#What paired clients receive
Every paired client listens to the server's live broadcast. That carries run progress, approvals, warehouse changes, and schedule state. The client shows it as it happens. The broadcast carries state to the client's screen. The server stays in charge of that state.
#Manage devices
The Devices page lists every paired client. Revoke any entry to cancel that client's pass right away. Pair again later and it gets a fresh pass. Revoke a Bridge, and recipes that need it stop doing page actions until a Bridge is paired again.
#Next
Decide whether your server needs a public name in Reachability.