Host for friends and family

What multi-user gives you

You run a single Parachute hub on Render, Fly, or your own machine. You create an account per person and assign them one or more vaults. They sign in, change the password you handed them, open Notes against any of their assigned vaults, and they're using their own private knowledge graphs — without anyone else able to read or write them.

The current shape: one admin (you), N users, each with one or more vaults. Phase 2 (shipped 2026-05-27) adds multi-vault membership and admin-initiated password reset. No self-service signup, no invite links, no role granularity below admin/user yet. Those land later as people ask for them. The point is to get you hosting your handful of people without standing up infrastructure per person.

1. Stand up your hub

Your hub is the door everyone walks through. It runs as a single container, supervises vault and scribe as child processes, and issues OAuth tokens for clients. Pick the deploy that fits:

• Render — one-click self-host, persistent disk, $7/month flat.
• Fly — peer to Render, machines + volumes shape, comparable cost.
• Your own machine — a home server, EC2, or any VPS runs the same supervised hub Render does, kept alive by a managed service (systemd / launchd) across reboots.

The wizard at /admin/setup walks you through naming your vault, picking a scribe provider, and exposing your hub. You become the first admin during the wizard — the username and password you pick there are yours.

Verify before inviting anyone: load your hub URL, sign in, and navigate to /admin/vaults, /admin/users, and /admin/permissions. If those load without 401 or 403, you're set up correctly.

2. Provision a vault per friend

Vaults are private per user. The hub mints per-vault scopes, and the OAuth issuer pins each user's tokens to their assigned vaults. There's no path for one user to read another's vault. Friends can have multiple vaults — one personal + one family-shared is a common shape — or just one. Either way, vaults are isolated from each other; only the admin (you) can read all of them.

Provision via /admin/vaults → Add vault. Give it a name your friend will recognize when they sign in — their first name or initials work. maya, jp, dad. Lowercase, alphanumeric, dashes and underscores only.

The vault boots immediately. Check the vault list shows it as running before moving on.

3. Create an account for your friend

Go to /admin/users → Create user. Three fields:

• Username — lowercase, 2–32 characters, alphanumeric + dash + underscore. Your friend will type this every time they sign in; keep it short.
• Default password — at least 12 characters. You pick this. Your friend will be force-redirected to change it the moment they sign in.
• Assigned vaults — pick one or more vaults for them. The multi-select lists every vault on the hub. Most friends want just one vault; pick two or more if the friend will be working across separate contexts (e.g. personal + family-shared). Leaving it empty means "no vaults yet" — they can sign in but can't authorize any vault until you assign one via the Edit Vaults action later.

Submit. The user appears in the table with their assigned vaults shown and Password set: No — the bit that tells the hub to force-redirect them through change-password on first sign-in.

Securely hand off the default password. Signal, an in-person screen-share, a sealed envelope — not plain email, not a chat log that lives forever. The password is one-time use; the moment your friend signs in they'll be told to pick their own. But it still gates access to their vault until they do, so treat it like the first key to a house.

4. Send your friend the sign-in link

What they need from you:

• Your hub's URL — e.g. https://parachute.your-domain.com or whatever you set up at the wizard.
• Their username.
• The default password you set.

A short message that works:

When they sign in, they land at /account/change-password, pick a new password, and then are dropped at /account/ — their personal home page. It shows their assigned vault(s) as cards, each with its own Open Notes button, and a link to change their password later if they want.

5. Connecting a friend's AI client to their vault

Notes (the web app) connects with one click via the popover — nothing to configure. But a friend who wants to drive their vault from Claude Code, Claude.ai, or any MCP-aware client connects to a URL, the same as you would. Two facts to hand them:

• The endpoint is <hub-url>/vault/<their-vault>/mcp — your hub's public URL (the same one they sign in at), their vault name (shown on their /account/ page), and the literal /mcp suffix. The suffix matters: the bare /vault/<name> path is a read-only metadata page, not the MCP endpoint, and an MCP client will fail its connection handshake against it. Use the hub's URL, never the vault's internal port.
• Auth is the hub's standard OAuth. When their client connects, it sends them to your hub to sign in and approve — their token is pinned to their own vault and can't reach anyone else's. No token-pasting for OAuth-capable clients; for clients that need a bearer header instead, they can mint a hub JWT scoped to their vault from their own access (or you mint and hand one off out-of-band).

The literal per-client commands — claude mcp add --transport http <name> <hub-url>/vault/<name>/mcp for Claude Code, the Settings → Connectors flow for Claude.ai, and the generic streamable-HTTP shape for everything else — live in Connecting MCP clients on the install page. Point your friend there; the only substitutions are your hub's URL and their vault name.

The in-product shortcut: in your admin SPA, open the Vaults list and hit the Connect toggle on the friend's vault row. That expands a Connect an MCP client card with the exact <hub-url>/vault/<name>/mcp endpoint and a copy-paste claude mcp add command already filled in for that vault — plus an optional mint-a-token path for headless clients. It's the same surface for every vault, any time; no need to retype the URL by hand.

Onboarding a team member — the short version

The sections above cover each step in depth. Once you've stood up your hub, this is the whole loop per person:

1. Create their account. /admin/users → Create user: username, a temporary password (you pick it), and the vault(s) to assign. (Provision a vault first if they don't have one yet.)
2. Hand them three things, out-of-band. Your hub's <hub-url>/login, their username, and the temporary password. Use Signal, in-person, a sealed envelope — not plain email.
3. They sign in and are force-prompted to set a new password. On first sign-in at /login, the hub redirects them through change-password before anything else; then drops them at /account/, their home page showing their vault(s).
4. They can change it any time from /account/. If they forget it, you reset it from /admin/users → Reset password (which also revokes their existing tokens).
5. To connect their AI client to their vault, open the Vaults list and use the per-row Connect toggle → Connect an MCP client card, or send them step 5 above / Connecting MCP clients. Notes (the web app) needs none of this — it connects with one click.

What your friend can and can't do

Can:

• Open Notes against any of their assigned vaults — web app at notes.parachute.computer, runs on any device. Adds itself as a PWA on iOS and Android. The connect flow lets them switch between vaults they have access to.
• Connect a custom client to their vault — a custom Surface running on their laptop, an MCP-aware AI client, or any tool that speaks OAuth + MCP. The hub issues per-vault tokens through the standard OAuth flow; their token is pinned to their vault, can't reach anything else. (How to connect an AI client →)
• Change their own password from /account/change-password any time.
• Sign out from /account/.

Can't:

• See or read any vault outside their assigned list. The OAuth issuer pins their tokens to their assigned vaults; vault servers enforce scope server-side. Friends with two assigned vaults can authorize into either, but never into a third the admin hasn't granted them.
• Reach /admin/. The admin SPA is gated to the first admin (you); anyone else who navigates there gets redirected to /account/.
• Create users, manage vaults, or mint operator-scope tokens. The token-mint endpoints check that the caller is the first admin before issuing.
• Promote themselves or anyone else.

If a friend wants to build their own Surface

This is where multi-user gets interesting. A friend who codes can build their own UI — a custom Notes-like app, a journaling tool, a research workbench — that talks directly to their vault on your hub.

Hand them the Surface-build starter prompt. It walks an AI client through scaffolding a custom UI that wires into the vault's MCP via the standard OAuth flow. They'll need:

• Your hub's URL (the same one they use to sign in).
• The vault name(s) shown on their /account/ page.

The OAuth flow is standard: their app registers as a client via dynamic client registration (DCR), redirects them to your hub for consent, gets a code, exchanges it for a vault-scoped token. You don't need to pre-register their client. External clients hit a consent screen on first authorize, where your friend approves — once they approve, future authorizes are seamless. If they have multiple assigned vaults, the consent screen shows a picker so they choose which vault to authorize for; the token is pinned to that single choice.

Tokens are pinned to the vault the friend picked. Their custom Surface can never talk to a vault outside their assigned list, even if they wire it wrong.

If something goes wrong

Friend forgot their password. Reset it from /admin/users: click Reset password on their row, pick a new temp password, hand it to them out-of-band. They'll be force-redirected through change-password on next sign-in, exactly like the original default-password flow. All their existing tokens are revoked automatically as part of the reset.

Friend's tokens leaked. Go to /admin/permissions for the per-vault grants view, or /admin/tokens for the per-token registry. Revoke individual tokens or every token for a user. Their OAuth clients will get 401 on next call and re-prompt for consent. The admin password reset above also revokes tokens as a side effect — useful if you want a clean slate.

Wrong vault assigned. Open /admin/users, click Edit Vaults on the friend's row, adjust the multi-select, save. Their notes in any removed vault stay put (vaults and assignments are independent), but they lose access via OAuth on the next token mint. Existing access tokens stay valid until they expire (~15 min); refresh tokens stop minting against the removed vault.

Removing a friend entirely. Delete the user via /admin/users. Their vaults are not deleted by that action — vaults and accounts are independent. If you want the vault gone too, delete it via /admin/vaults after.

What multi-user is not (yet)

Honest about the current limits:

• No self-service signup. You create every account. There's no invite link, no "sign up with email," no SSO. Phase 2 follow-up: invite-link onboarding (alternative to default password).
• No role granularity. Either you're the admin (first user) or you're a regular user with read/write access to your assigned vaults. No "viewer" / "editor" mid-tier. The schema is forward-compatible with per-vault roles (a `role` column is already in place); Phase 3 wires it into scope-narrowing.
• No 2FA. Password-only sign-in. Multi-factor lands later; until then, pick a real password and limit your hub's public exposure if you can.
• No self-service password reset by the user. Friends can change their password any time at /account/change-password, but if they forget it, you (the admin) have to reset it via /admin/users. Self-service email-based reset is Phase 3 work.

The design document for the full plan is at /design/2026-05-20-multi-user-phase-1/ — including what Phase 2 and 3 add. If any of the Phase 1 limits block your use case, open an issue at the hub tracker and we'll prioritize.