Deploy to Render
+Your own Parachute, your own data, in a browser tab. About five minutes from click to a running URL.
+One click to start
+ +Why this path. Parachute is happiest on your own machine, but a laptop sleeps. Render is the simplest "always-on URL" we've found that still lets you own everything — a single container running your hub, with a persistent disk for your vault, all in your Render account. No tenancy, no shared database, no Parachute-operated cloud sitting between you and your data.
+ +
+
+ 
+
+
Render will ask for a GitHub connection, read render.yaml from parachute-hub, and provision a single web service with a persistent disk attached. The first build takes about two to three minutes.
What you get
+ +One Render web service (Starter plan, $7/month) running hub-as-supervisor — the same architecture you'd run locally, just inside a Render container. One persistent disk mounted at /parachute for module installs and vault data. HTTPS and a *.onrender.com subdomain included; a custom domain attaches in a couple of clicks afterward.
Modules are not pre-installed. The container ships with only the hub. After first boot, the admin UI lets you install Vault, Notes, and Scribe with one click each — they install onto the persistent disk under /parachute/modules, so they survive redeploys.
This is the deploy mirror of the local model: locally, the hub supervises vault, notes, and scribe as child processes sharing ~/.parachute/. On Render, the hub supervises the same children in the same container, sharing the mounted disk. See the v0.6 deploy architecture note for the full shape.
1. Click "Deploy to Render"
+ +Why this step. Render reads the repo's render.yaml, which declares the service shape (web service, Docker, disk at /parachute, env vars) and pre-fills everything on the Render dashboard. You're just confirming.
Sign in or sign up. Accept the GitHub connection if you don't already have one. Render shows the "Apply Blueprint" page with one service (parachute-hub) and one disk. Click Apply.
What you should see. Render kicks off a build. The dashboard lands on the service page with a live deploy log streaming.
+2. Wait ~2–3 minutes
+ +Why this step. First build pulls the Docker image, sets up the persistent disk, and boots the hub. Subsequent redeploys (after you push to the repo, or click "Manual Deploy") are faster — about 30 seconds — because the disk and image layers are cached.
+ +The deploy log shows the build, then the hub start. Look for a line like parachute-hub listening on :1939. When the dashboard banner switches from "Deploying" to Live, you're up.
What you should see. Status: Live. A URL on the service page like https://parachute-hub-abc123.onrender.com.
3. Open the Render URL
+ +Why this step. Hub boots without an admin account on a fresh disk. The first request to any non-public route redirects to the first-boot wizard, which sets your admin credentials and names your first vault.
+ +Click the URL on the Render dashboard. Hub redirects you to /admin/setup.
What you should see. The setup wizard's welcome screen, with five steps in the side rail: Welcome, Account, Vault, Expose, Done.
+4. Walk the first-boot wizard
+ +Why this step. The wizard sets up the things that have to be set up once and can't be defaulted: who you are, what to call your first vault, and how this hub is reachable on the internet.
+ +-
+
- Welcome. One screen of orientation. Continue. +
- Account. Pick a username and password. Stored in the hub's database with argon2 hashing. There's no email-based recovery on the self-hosted path — the hub belongs to you, so write the password down. +
- Vault. Names your first vault (defaults to
default). You can add more vaults later from the admin UI.
+ - Expose. Pick how this hub is reached. For Render: choose Public URL — Render handles TLS termination on the
*.onrender.comsubdomain (or your custom domain). The other options (Tailscale, Cloudflare Tunnel) are for the local-install path; on Render they're not the right fit.
+ - Done. Two tiles: Open the admin UI (lands on
/admin/vaults; from there you can navigate to/admin/modulesto install Notes, Scribe, and any other modules) and Connect Claude Code (MCP) (the install command for the MCP wiring — see step 6).
+
What you should see. The done screen renders the claude mcp add command pre-filled with your hub's URL and vault name. Note: the wizard's command does not include an auth header — you mint a token separately from /admin/tokens and add the header yourself. Step 6 walks the full pattern.
5. Install modules from the admin UI
+ +Why this step. The hub on its own is just the supervisor — useful for OAuth and module lifecycle, but not yet the thing you want to talk to. Modules are where the actual reading, writing, and capturing happens.
+ +From the done screen's Open the admin UI tile (lands on /admin/vaults), navigate to Modules — that's /admin/modules. You'll see Vault, Notes, and Scribe listed as available. Click Install next to each one you want. Install takes about a minute per module — the hub runs bun install against the package and persists it under /parachute/modules/node_modules/, then spawns it as a child process and mounts its routes under /vault, /notes, /scribe.
What you should see. Each installed module switches to a Running badge with its mounted path. Notes is reachable at <your-hub>/notes, vault's REST API at <your-hub>/vault/default, scribe at <your-hub>/scribe.
6. Connect Claude Code
+ +Why this step. The vault is running and reachable, but no client is wired to it yet. Claude Code talks MCP over HTTP — one command registers the server in ~/.claude.json, then it picks it up on the next session.
Connecting is a two-step pattern. First, copy the claude mcp add command from the wizard's done screen into your terminal — it looks like:
claude mcp add --transport http parachute-default https://your-hub.onrender.com/vault/default/mcp
+ Then mint an API token: go to /admin/tokens in the admin UI, create a new token (default scope vault:write is what you want), and copy the pvt_... string. Re-run claude mcp add with the header flag — or edit the entry in ~/.claude.json directly — so the final form is:
claude mcp add --transport http parachute-default https://your-hub.onrender.com/vault/default/mcp --header "Authorization: Bearer pvt_..."
+ Start a new Claude Code session in any project. Run /mcp — parachute-default should appear with its nine tools resolved. Memory now persists across every session, backed by your Render-hosted hub.
What you should see. parachute-default in /mcp's list with status connected. Asking Claude to write a note succeeds and the note appears in the Notes UI on <your-hub>/notes immediately.
Custom domain (optional)
+ +Why this step. The *.onrender.com subdomain works forever, but most people want their own domain — both for memorability and because the OAuth tokens the hub mints are bound to a canonical origin you'd rather control.
-
+
- In Render: Service → Settings → Custom Domains. Add your domain. Render gives you a CNAME target. +
- In your DNS: point a CNAME from your subdomain to that target. Wait for propagation (usually under a minute, sometimes longer). +
- Render automatically provisions a TLS certificate from Let's Encrypt. +
- Back in Render: Service → Environment. Set
PARACHUTE_HUB_ORIGIN=https://your-domain.example.com. The variable's already declared inrender.yamlwithsync: false, so Render's UI is where you fill it in. Save — Render redeploys automatically.
+
Cost
+ +-
+
- Render Starter: $7/month, flat. The web service tier. The free tier doesn't support persistent disks, and the hub needs a disk for module installs and vault data — so Starter is the minimum. +
- Persistent disk: Render charges separately for disk space beyond the included 1GB — see Render's pricing for current rates. Vault databases are tiny; typical single-operator usage stays well under 1GB through the first year, so most people pay nothing extra. +
- Custom domain: free, assuming you already own the domain. TLS via Let's Encrypt is included. +
Expected total: ~$7/month plus disk-overage for hub + vault + notes + scribe running together — most single-operator setups stay at the $7 floor.
+ +Compare locally: the same stack on your own Mac or Linux box is free, but you give up the always-on URL and the "works from my phone, anywhere" property. The Render path is the trade.
+Limitations
+ +-
+
- One container shares 512MB of RAM. Render Starter is enough for hub + vault + notes + scribe at typical sub-1000-note usage. If you hit the ceiling — large vaults, heavy transcription workloads — the path is either upgrade the Render plan (Standard is 2GB) or split a module out to its own service later. We'll document that when someone needs it. +
- No free tier. Free Render web services don't support persistent disks, and a stateful hub needs a disk. Starter ($7) is the floor. +
- Module installs take a minute. Each "Install" click runs a real
bun installon the container against the npm registry. First-time installs of vault or notes take roughly a minute; redeploys re-use the cached disk.
+ - Redeploys are not zero-downtime. When you push to the repo (or Render redeploys for any reason), the container restarts. Expect ~30 seconds where the hub is unreachable. For a single-operator hub this is a non-issue; for teams it's worth knowing. +
What comes next
+ +-
+
- Local install — the same stack on your own machine. Free, but sleeps when your laptop sleeps. +
- v0.6 deploy architecture — the design note explaining why it's one container with hub-as-supervisor. +
- parachute-hub issues — deploy questions, bugs, friction. We read all of them. +
+
+
+
+
Or install locally.
+