"Local first" does not mean nothing ever crosses the network. It means your server stays in charge. It keeps the data that lasts. It keeps the secret keys. It decides what each actor may do. An actor is whoever is asking: you, one of your automations (like a schedule), or an outside AI or customer. And it writes down what happened. Data leaves your server only for things you set up yourself. That means a connection or a call to an AI model. It also means a public web address, or something you chose to publish.
#What lives where
| Surface | What it may hold or receive | What it does not become |
|---|---|---|
| Your server | Warehouse records, account secret keys, installed recipes and packs, grants, the audit diary, memory, and locked backups | An account run by the cloud, or a copy of your data in the cloud |
| Paired webclient | A limited pass you can cancel, plus the data the server sends it to show | The recipe engine, the secret key store, or the keeper of the diary |
| Paired Browser Bridge | A limited pass you can cancel, plus tightly limited browser commands | A general remote control, or a place that keeps your data |
| Recued cloud | Things you publish, your account and billing details if you have them, and help with names and certificates if you want it | A middle-man for your server's normal traffic, or a copy of your warehouse, secret keys, or diary |
| A model or connected provider | The request and the data needed for the call you chose to make | Something with its own Recued power |
Traffic to a provider or an AI model goes straight from your server to them. Their own privacy rules still apply. So do their rules on how long they keep data. Recued's local line cannot take back data you chose to send to another service.
#Encryption and recovery
The first time you pair, your server locks its protected state with a 24-word recovery key. Normally the running server unlocks itself with a key file in its data folder. The recovery key is the other way back into the same protected state. You also need it to open locked Recued backup files.
What protects the key file itself? You choose that once, when the file is
made. The server uses RECUED_IDENTITY_PASSPHRASE if you set it. If not, it
uses a secret store built into the computer. That store keeps the secret
outside the data folder. If neither is there, it uses nothing. That third case
is allowed.
It is not broken. The warehouse is still locked. Stored data is still safe if
someone copies, backs up, or snapshots the database on its own. That is an
unsealed key file. What you give up is this: if someone takes the whole folder, the key is inside it too.
See Install the server to learn how to seal
the key file. It also says what it costs to change your mind later.
Settings → Server → Key Health tells you which protection is in use. So you can always see the answer. You never have to guess.
#Keeping the three pieces apart
Keep the data folder, its key file, and the recovery key apart. Put them in three places, so one bad day cannot take all three:
- only the computer account that runs the server may open the data folder;
- keep the recovery key offline and away from that server;
- keep locked backups somewhere that survives losing the server computer;
- check that you can find the recovery key before you need it.
If someone controls your unlocked server, they can do what the server can do. The same is true if they control the computer it runs on. Locking the data on disk helps when the keys are not there. It does not replace keeping the computer itself safe. Lose both the server's key and the recovery key, and the protected data is gone for good. See Backup and restore for the backup and restore steps that are supported.
#Network boundary
Plain HTTP on the same computer is fine for setup. Use HTTPS whenever a browser connects over your own network or the internet. The webclient and pairing use browser features that only work on a safe connection. HTTPS also protects the direct path from the client to the server.
A public Recued name still points at your server. For the optional Pro path, Recued may help with the DNS name and the certificate. But it never sits in the middle of the traffic and never unlocks it. Opening a public name also makes your server face the internet. So open only the doors and addresses you need. Read Reachability before you open any ports.
#Authority, grants, and revocation
Having a web address is not the same as having power. Every recipe and every schedule goes through the same gate on the server. So does every chat request and every call from an outside AI. The server works out who is asking and which installed capability is being used. A capability is one thing a pack can do. It checks the grant and the risk level. It asks you if it must. Then it writes the diary entry.
Different ways in have different ways to close them:
- take back a paired webclient or Browser Bridge from Devices;
- close an MCP, Reception, or messenger door to take back the access it gave;
- make a pack's grant smaller, or remove it. You do not need to copy or sign in to its account again;
- delete a connection, or sign in to it again, when the account secret itself must change.
Recipes get what a connection returns and its non-secret fields. They never get the raw secret key. When you install a pack, look at the most its recipes could ever ask for. The live call still has to pass the gate. Words in a manifest alone do not give access. See Grants and approvals.
Some of what the gate sees came from outside. A form, an email, or a message another site sent you. That content can never turn itself into an approved action. See Untrusted input.
#What an AI source sees
An AI source sees the prompt and the data sent for that one call. Recued can swap known names, email addresses, phone numbers, and street addresses for stand-ins. Each stand-in is the same kind of thing: a fake name for a name, a fake email for an email. It does this before the request leaves. It puts the real ones back when the answer comes home. That is a targeted swap. It is not a promise that free text or a file has no clue about who someone is.
Pick a local model when the data must stay on your computer. For an outside model, check three things. Does the step ask to read message bodies or attachments? Which source did you pick? What are that provider's own rules? Pause AI stops background AI work. It does not take back a provider key. It does not erase requests already sent. Read AI and models for the routing controls.
#Operator checklist
- Install signed releases or images pinned by digest. Keep the server up to date.
- Keep the data folder and the recovery key safe, in two places.
- Use HTTPS beyond the server computer. Open only the doors you need.
- Sign in to providers with the smallest set of permissions that works.
- Look at a pack's contents, grants, audience, and model access before you install.
- Take back devices and doors you no longer use.
- Keep locked backups. Check that you can restore from them.
- Use Runs and entity timelines to see what really happened.
Safety here is a set of lines you can see, not one switch. The server owns the gate. But the computer, the connections, the models, and the public doors you pick still shape the whole system.