Deploy to Render | Parachute Computer

One click to start

Why this path. Parachute is happiest on your own machine, but a laptop sleeps. Render is one of two "always-on URL" paths we support that still let 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. (See Deploy to Fly.io for the peer path.)

Same setup as every install. A Render deploy isn't a different onboarding — it's the same unified flow. Locally you'd run parachute init to get a hub and land in the setup wizard; here, Render gives you a running, already-exposed hub at a public URL, and you land in the identical wizard at /admin/setup. You'll walk the same Account → Vault steps an operator on a laptop or an EC2 box walks; the wizard's Expose step auto-skips on Render (the platform already owns the public URL), so you go straight to Done. The only Render-specific bit is grabbing a one-time bootstrap token from the logs to claim admin (step 3).

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 one to two 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, Surface (the UI host module, with Notes auto-bootstrapped as the first hosted surface), 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, app, 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, plus an env-var section.

Apply with defaults. The blueprint's defaults are sensible — you don't need to fill anything in. Just click Apply. Hub will print a one-time bootstrap token in its startup logs on first boot; you'll grab that and create your admin account through the setup wizard in step 3.

Optional env vars you might want to set:

PARACHUTE_HUB_ORIGIN — only set this if you're attaching a custom domain at deploy time. See the Custom domain section below for what this does and why. Leaving it blank is the right answer for the Render-assigned *.onrender.com URL — hub will use whatever URL the request came in on as the OAuth issuer, which just works.
PARACHUTE_INSTALL_CHANNEL — pre-set to latest by the blueprint. Modules you install via the admin SPA (vault, app, scribe, runner) pull stable releases. Flip to rc if you want pre-release modules (dev/testing against the rc release line). Per-install --channel / --tag always override.

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 serve: listening on http://localhost: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. Grab the bootstrap token and open setup

Why this step. Hub generates a one-time bootstrap token on first boot and prints it in the startup logs. You'll copy it from Render's logs panel and paste it into the setup wizard to claim admin.

Open Render Logs. Your Render service dashboard → Logs tab. Watch for hub's startup banner. It looks like:

[wizard] ════════════════════════════════════════════════════════════════
[wizard]   PARACHUTE BOOTSTRAP TOKEN
[wizard] ════════════════════════════════════════════════════════════════
[wizard]
[wizard]   parachute-bootstrap-XXXXXXXXXXXXX
[wizard]
[wizard]   → Visit https://YOUR-URL/admin/setup ...

Copy the parachute-bootstrap-XXXXXXXXXXXXX line (prefix + 43-char body). That's your token.

Visit your hub's URL (from the Render service page). You'll land at /admin/setup. Paste the token, choose your admin username + password, click Create Admin. You're in.

The token expires when admin is created OR when hub restarts — so don't navigate away mid-setup. If you do lose it, trigger a redeploy from Render and grab the fresh token from the new boot's logs.

What you should see. The setup wizard, now past the Account step (your admin's been created) and ready to walk you through the rest: Vault, Expose, Done. Step 4 covers the remaining wizard screens.

4. Walk the first-boot wizard

Why this step. Your admin account was created in step 3 via the bootstrap-token form. From here it's the same wizard every Parachute install uses — the one a laptop operator reaches via parachute init, just pre-advanced past the account step. It walks through what still needs to be set up once and can't be defaulted: your first vault and how this hub is reached.

Vault. Create a fresh vault (defaults to default — any short name of lowercase letters, numbers, hyphens, or underscores works: notes, journal, work-2026, …), import one from a git repo (a previously-exported Parachute vault on any HTTPS / SSH remote; PAT optional for private repos), or skip and create one later from the admin UI. You can add more vaults later either way; the name shows up in the URL for that vault's API + MCP endpoints (e.g. /vault/notes/mcp).
Expose. Hub auto-skips this step on Render — the platform already owns the public URL via your *.onrender.com subdomain (or custom domain), so the three radio choices (localhost, tailnet, public-with-custom-domain) don't speak to your setup. You'll move straight to Done.
Done. Two tiles: Open the admin UI (lands on /admin/vaults; from there you can navigate to /admin/modules to 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, vault name, and the auth header — the wizard auto-mints a fresh hub token scoped to your vault and drops it into the Authorization: Bearer flag for you. Copy-run it as-is. Step 6 walks the command and the fallback if you need to mint a token by hand.

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, Surface, and Scribe listed as available (three modules, not four — Notes ships bundled inside Surface). 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, /surface, /scribe. Installing Surface auto-bootstraps the Notes UI as its first hosted surface.

What you should see. Each installed module switches to a Running badge with its mounted path. Notes is reachable at <your-hub>/surface/notes/ (the legacy <your-hub>/notes/ URL still resolves via hub's redirect), 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.

The simplest path: copy the claude mcp add command straight off the wizard's done screen and run it. The wizard already auto-minted a hub token scoped to your vault and pre-filled the Authorization: Bearer header — the command is complete as shown. On a hosted deploy there's no local browser for the OAuth redirect, so you attach the token explicitly here (unlike a laptop install, where Claude Code completes the browser sign-in for you):

claude mcp add --transport http parachute-default https://your-hub.onrender.com/vault/default/mcp --header "Authorization: Bearer <hub-JWT>"

If you closed the done screen or want to mint your own token, either source works — both return a hub JWT (not a legacy pvt_ string; vault no longer issues those):

Admin UI → Tokens — go to /admin/tokens, create a token scoped to your vault (default vault:default:write — replace default with your vault name if you chose a different one), and copy the JWT it returns.
On the hub host: parachute auth mint-token --scope vault:default:write (replace default with your vault name if you chose a different one) prints a JWT to stdout (default 90-day lifetime).

Then re-run claude mcp add with that JWT in the header flag (or edit the entry in ~/.claude.json directly). 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>/surface/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 in render.yaml with sync: false, so Render's UI is where you fill it in. Save — Render redeploys automatically.

Why PARACHUTE_HUB_ORIGIN matters (and why you can ignore it without one).

Hub stamps an "issuer" URL into every OAuth token it mints. By default (variable unset), the issuer is whatever URL the request came in on — so on a vanilla Render deploy, tokens are minted against your https://parachute-hub-abc123.onrender.com URL and everything works. The variable only exists for the custom-domain case. Pinning it to your canonical domain at deploy time means tokens are bound to that domain from day one; if you flip the issuer later (e.g. you set a custom domain post-deploy — adding or changing PARACHUTE_HUB_ORIGIN both switch the issuer from the request URL to your pinned value), every token minted before the switch becomes invalid and every connected client (Claude Code, Notes PWA, anything else holding a token) has to reconnect through the OAuth flow. Pick the domain you want before you wire up clients, then set the var once and don't churn.

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 + app (with notes-ui auto-bootstrapped) + 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 + app + 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 install on the container against the npm registry. First-time installs of vault or app 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.
Edge cold-start can briefly 502. Right after a deploy goes Live, Render's edge router takes another ~10–30 seconds to settle routes to the new container. Probes during that window may return 502. Once warm, the hub is stable (this is platform-level behavior, not a hub bug).

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.