Getting started

First you set up your own server. The server is the Recued program you run on your own computer. It does all the real work. Then you pair a thin client to it. A client is an app that shows you things and takes your clicks. After setup, your server is still in charge. The webclient never becomes a copy of your data in the cloud. Plan for about 15 minutes once the server is running.

#Before you begin

You need:

• a Mac, Windows, or Linux computer that you control and that can keep the server running. A laptop, a home server, or a VPS is fine;
• a modern web browser for the webclient;
• enough disk space for the mail, files, CRM snapshots, and audit history you choose to keep.

Your server does not need to be reachable from the internet to work on your own network. Start on the same computer or the same network. Add a public name only when a feature needs messages coming in from outside.

#1. Install the server

The normal way is one command. On Linux or macOS, open a terminal and run:

curl -fsSL https://recued.com/install.sh | sh

On Windows, open PowerShell first. Press Start, type PowerShell, and open it. Then paste:

irm https://recued.com/install.ps1 | iex

The script fetches the signed binary for your computer. It checks the signature. It puts recued on your path. It starts the server, and sets it to start again each time you log in. So when the script is done, the server is already running. If recued is not found in that same terminal, open a new one.

Other ways to install are on Install the server: building from source, or downloading the binary by hand. Whatever path you pick, use the signed file given for the current release. Do not copy an old version from a guide.

Check its local health address:

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

The answer should have HTTP status 200 and contain "status":"ok". If recued pair (step 2) names a different host or port, use that instead. If this check fails, fix the server before you go on. Pairing uses this same address.

#2. Pair a client

Run recued pair on the server machine. It prints a pairing code, the server's addresses, and the pairing link. After a sudo install on Linux, run it with sudo too; the script printed the exact command. Open the link, or the built-in webclient's address it names, or use app.recued.com/pair↗. Then:

1. Type in the server address and the pairing code.
2. Check that both sides show the same server identity.
3. On the first pair, make or type in the 24-word recovery key. This turns on encryption for the data on disk.
4. Keep the recovery key offline, away from the server.

The pairing code works once, for 15 minutes. Did it run out? Run recued pair again for a fresh one. Need a longer window? Run recued pair --pair-code-ttl 24h. Pairing gives the client a limited pass. You can cancel that pass any time. Pairing does not move your data or your secret keys to the cloud.

Browsers do not treat plain HTTP on an address on your own network as safe. So use localhost when the browser is on the server computer. Use HTTPS when you pair from another device. See Pairing and devices to learn about the Browser Bridge. It also covers what the recovery key is for, and how to manage devices.

#3. Connect a provider

Open Connections and choose a provider. A provider is an outside service, like your email or your CRM. Finish its sign-in steps. Give the connection a name you will know later, like github-work or salesforce-personal. Recipes use that name. They never use the secret itself.

Stop if the sign-in says a permission is missing or something cannot be reached. A ready connection shows who you are and what it can do. You can use it again and again. Packs ask for the actions they need. The secret is never copied into each recipe. See Connections for OAuth, API keys, and apps you make at the vendor. It also shows how to fix a connection that ran out.

#4. Install a pack

Open Discover and choose a recipe or a pack. A pack is a box that holds recipes and ingredients. You install the whole box at once. If you start from a recipe that lives in a pack, Recued opens that pack's setup. Before you install, look at:

• every recipe the pack will install;
• the connection it will use, if any;
• the access level (read, write, or all) and who may use it;
• approvals, webhook slots, whether it may see message bodies, and whether it may use local tools.

Install only when those choices match what you want. You can change the grants later. You do not need to install the recipes again.

#5. Run it once

Open one of the installed recipes and choose Run. Fill in any values the recipe asks for. Then watch the run feed. A big step may pause on an approval card. Look at what it will touch and the values you can edit. Then decide whether to approve it.

The run is done when the feed shows a result. Audit should also show the run. It lists who asked and the inputs. It lists the reads, the writes, the approvals, and how it ended. That diary entry is the best proof that the server, the connection, the grants, and the recipe all work together.

#Setup checklist

• /health answers 200 with status: ok.
• The webclient shows the server as connected and unlocked.
• The recovery key is kept somewhere other than the server computer.
• The connection says it is ready for the actions the pack needs.
• The pack shows under installed packs with the access and audience you expect.
• A first run finishes, or pauses at the approval you expect, and shows up in Audit.

#Next

Read How Recued works to learn the trust lines behind these steps. Or go to Troubleshooting if one of the checks above fails.