Getting started — Recued Docs

The setup path establishes your own server first, then pairs a thin client to it. Your server remains the authority after setup; the webclient never becomes a hosted copy of your data. Budget about 15 minutes once the server is running.

#Before you begin

You need:

a Mac, Windows, or Linux machine you control that can keep the server running — a laptop, home server, or VPS is fine;
a modern browser for the webclient;
enough persistent storage for the mail, files, CRM snapshots, and audit history you choose to keep.

Public reachability is optional for local use. Start on the same machine or network; add a public name only when a feature needs inbound traffic.

#1. Install the server

Open Install the server and choose the binary, container, one-click VPS, or source path. Use the signed artifact or digest-anchored image supplied for the current release; do not copy an old version or mutable container tag from a guide.

When the process is up, check its local health endpoint:

curl --fail http://127.0.0.1:7717/health

The response should have HTTP status 200 and contain "status":"ok". Use the host and port printed in the boot banner if they differ from the example. If this check fails, fix the server before moving on; pairing also uses this listener.

#2. Pair a client

The server's first boot prints its reachable URL and a single-use pairing code. Open the bundled webclient URL from that banner, or use app.recued.com/pair, then:

Enter the server URL and pairing code.
Compare the server identity shown on both sides.
On the first pair, generate or enter the 24-word recovery key that enrolls at-rest encryption.
Store the recovery key offline, separately from the server.

The pairing code expires after 15 minutes and belongs to the active server process. If it has expired, restart that process with the same database and configuration, then use the new code from its boot log. Do not generate a code from a second standalone process: that code is not active in the running server. Pairing grants the client a narrow, revocable token; it does not move your warehouse or provider credentials into the cloud.

Plain HTTP on a LAN address is not a browser secure context. Use localhost when the browser is on the server machine, or HTTPS when pairing from another device. See Pairing and devices for the Browser Bridge, recovery-key responsibilities, and device management.

#3. Connect a provider

Open Connections, choose a provider, and complete its enrollment flow. Give the connection a name you will recognize later, such as github-work or salesforce-personal; the name, not the secret, is what recipes bind to.

Stop if enrollment reports a missing scope or inaccessible resource. A ready connection has a verified identity and capability summary. It is reusable: packs request the operations they need without copying the credential into each recipe. See Connections for OAuth, API keys, vendor-owned apps, and reconnecting an expired grant.

#4. Install a pack

Open Discover and choose a recipe or pack. If you start from a recipe that belongs to a pack, Recued opens the owning pack's setup flow. Before installation, review:

every recipe the pack will install;
the connection it will use, if any;
the access tier — read, write, or all — and the audience allowed to use it;
approvals, webhook slots, body-content visibility, or local-tool access.

Install only after those choices match your intent. You can revise grants later without reinstalling the recipe definitions.

#5. Run it once

Open one of the installed recipes and choose Run. Supply any values the recipe asks for, then follow the execution feed. A consequential step may pause on an approval card; inspect its resolved target and editable arguments before approving it.

The run is complete when the feed shows a result and Audit contains the actor, inputs, reads, writes, approvals, and outcome. That audit entry is the best end-to-end proof that the server, connection, grants, and recipe are all wired correctly.

#Setup checklist

/health returns 200 with status: ok.
The webclient shows the server as connected and unlocked.
The recovery key is stored somewhere other than the server machine.
The connection reports ready for the operations the pack needs.
The pack appears under installed packs with the expected access and audience.
A first run completes or pauses at the expected approval, and appears in Audit.

#Next

Read How Recued works for the trust boundaries behind this flow, or go to Troubleshooting if one of the checks above fails.