Get started | Parachute Computer

1 · Run one command

You'll need Bun 1.3 or later.

On Bun 1.2.x / checking your version

Check it. bun --version — if it's below 1.3, run bun upgrade.
Stuck on 1.2.x? You may see a cosmetic InvalidPackageResolution or FileNotFound warning during install — the package installs anyway. Upgrading to Bun 1.3 clears it.

bun add -g @openparachute/hub && parachute init

parachute init starts your hub, installs your vault — the place all your notes live — and opens a browser setup wizard: Account → Vault → Expose → Done.

Where should it live? A laptop is perfect for trying it out — but Parachute is happiest on a machine that stays awake, so your vault is reachable from your phone and your AIs even when your laptop is closed. The ideal home is a small always-on box (a ~$5–12/mo VPS, or a Mac you leave on) — start on your laptop and move over anytime.

Ports, exposing it, tokens, and re-running

Ports. The hub answers on 1939; the vault runs on 1940 behind it.
Going beyond your laptop. init offers to expose your hub publicly (a Cloudflare Tunnel is the default on a server — it'll offer to install cloudflared for you on macOS and Linux). If an expose attempt fails, init keeps going on the local URL and prints a retry hint: parachute expose public --cloudflare.
Bootstrap token. When the hub is exposed publicly and no admin exists yet, init prints a one-time bootstrap token; the wizard asks for it before it lets you create the first admin (local-only installs skip this).
Safe to re-run. init is idempotent. Check the stack any time with parachute status.

2 · Finish the wizard

Account → Vault → Expose → Done

Account. Create your admin login.
Vault. Create your first vault — or import one from a git repo, or skip for now.
Expose. Choose how (or whether) to reach your hub from outside. This step auto-skips on a local laptop, and pre-selects public on an SSH'd server so the wizard URL is reachable.
Done. The wizard hands you everything you need to connect your AI.

3 · Connect your AI

Connecting any AI — Claude.ai on the web, ChatGPT, Claude Code, Cursor, Zed, your own agent — comes down to one URL: your vault's MCP endpoint. Point your client at it (web UIs call this a connector):

<hub-origin>/vault/<name>/mcp

<hub-origin> is the address your hub answers on — the same URL you sign in at, not the vault's own port 1940. <name> is your vault name (default unless you changed it). The /mcp suffix is required — the bare path is a metadata page, not the endpoint. OAuth-capable clients send you through hub sign-in automatically.

Pick your client:

Claude.ai, ChatGPT & other web AIs

In your AI's settings, add a new connector (custom MCP server) pointing at <hub-origin>/vault/<name>/mcp. You'll be sent to your hub to sign in and approve — then the AI can read and write your vault. Nothing to install; the easiest path for most people.

Claude Code & other CLI / MCP clients

Register the server once with claude mcp add — the wizard's done screen gives you a ready-to-paste command. The first time it connects, it sends you through your hub's sign-in in the browser (OAuth); after that, start a new session (MCP config loads at session start) and run /mcp — the vault's tools are there. Codex, Goose, Cursor, and Zed take the same <hub-origin>/vault/<name>/mcp URL. (Headless box that can't do the browser flow? Mint a token on the vault's Tokens page and append --header "Authorization: Bearer <token>".)

Clients that need a bearer token

Some clients can't do OAuth and want a static token instead. Mint one from the vault admin SPA's Tokens page, then give it to the client alongside the same <hub-origin>/vault/<name>/mcp URL.

★ 4 · See your first note

Here's the payoff. Ask your AI to jot a quick note (“jot down that I'm trying Parachute today”), then open it in a browser — two ways:

Fastest — nothing to install. Open notes.parachute.computer, the hosted Notes app. Enter your hub's vault URL (<hub-origin>/vault/<name>) and sign in. The app runs in your browser; your notes never leave your hub. There's the note you just made.

Host it on your own hub. Install Surface — the module that serves your UIs from your own hub — and it brings up Notes automatically:

parachute install surface

Open localhost:1939/surface/notes/, click the vault popover, and hit Connect. The same Notes, now served from your own hub — plus search, tag views, a visual map of how your notes link together, voice capture, and a markdown editor. One install covers every vault on your hub. Notes is the first surface; you can also build your own (below).

Two prompts, paste-and-go — fill your vault, then shape your view

1. Fill your vault. Your vault starts mostly empty. This prompt interviews you about how you think, proposes a tag and folder structure, and imports what you already have — built on your say-so.

Open the fill-your-vault prompt →

2. Shape your view. This prompt interviews you, then builds a custom UI over your vault — a static SPA on the surface SDK, hosted on your own hub or GitHub Pages.

Open the shape-your-view prompt →

Do them in order: structure what's in the vault first, then build how you see it. (Power users: you can also script your vault from bash, Python, or JS for imports, cron jobs, and CI.)

Make it yours — build a custom surface

Notes is just the first surface. Everything lives in an open vault your AI can read and write, so you can build a UI shaped to your brain — a dashboard, a daily journal, a garden — and host it on the same hub. @openparachute/surface-client gives you auth + the vault API, and surface-render renders your notes — a working surface in a few lines.

A custom Parachute surface over a personal vault, with the quick-capture panel open and the background dimmed behind it — My personal surface — “a quiet garden for the mind”: a custom surface built on top of my own vault.

The shape-your-view prompt above walks your AI through this end to end — give it your hub URL and a description of what you look at most.

Going further (optional)

The four steps above are the whole first run. Everything here is for later.

Run it always-on. Your laptop sleeps; a server doesn't. Deploy to a VPS → (Hetzner, DigitalOcean, or any Linux box) runs the same bun add -g @openparachute/hub && parachute init flow on a box that never sleeps — or use a Mac you leave on (e.g. a Mac mini). On an SSH'd server init pre-selects public exposure so the wizard URL is reachable.
Reach it from other devices. A Tailnet (tailscale serve) is the smooth private path — your hub, visible only to your own Tailscale devices. For public HTTPS that claude.ai can reach, a Cloudflare Tunnel gives you a clean public URL; see Deploy to a VPS for the full walkthrough.
Back it up & script it. Export your whole vault to portable, git-trackable markdown with parachute-vault export <dir> (and import back). Driving the vault from a script, cron job, or importer is covered in Scripting your vault; hosting for friends and family is in the multi-user operator guide.
Stay current. parachute upgrade sweeps the hub and every installed service to the latest release. Add --channel rc to track release candidates. Vault migrations run automatically on first post-upgrade boot.

Want Parachute Cloud? A hosted version — no server to run — is on the roadmap. Subscribe for updates.

Troubleshooting

Something not working?

Claude Code doesn't see the vault. Start a new session (MCP config loads at session start) and run /mcp. Still missing? Re-run parachute-vault mcp-install on the hub machine.
Port 1940 already in use. Run lsof -i :1940 to see what's there; change ports in ~/.parachute/vault/.env.
A client can't reach the MCP endpoint. Confirm the URL ends in /mcp and points at the hub origin (the address you sign in at), not the vault's own port 1940.
Stuck on Bun 1.2.x? You may see a cosmetic InvalidPackageResolution or FileNotFound warning — the package installs anyway. Upgrading to Bun 1.3 clears it.
Claude connector fails right after consent over a Cloudflare tunnel

You exposed your hub publicly with a Cloudflare Tunnel (parachute expose public --cloudflare) and tried to add your vault to the Claude Desktop / claude.ai / mobile MCP connector. OAuth consent succeeds, then Claude reports “the integration rejected the credentials” or “the connection was reverted” and never reaches the vault — while Notes and Claude Code (which use a static token) keep working fine, so it looks like an OAuth bug.

Cause — this is a Cloudflare edge setting, not a Parachute bug. Consent runs in your browser, so it passes Cloudflare. But the token exchange (POST /oauth/token) and the MCP calls are server-to-server requests from Anthropic's servers — and Cloudflare's Bot Fight Mode / Super Bot Fight Mode / Browser Integrity Check (or a Cloudflare Access policy) challenges them with a 403 “Access denied” page. Claude gets the 403 instead of a token.

Fix — in your Cloudflare dashboard for the exposed zone:
- Turn off Bot Fight Mode / Super Bot Fight Mode (Security → Bots), or add a WAF Skip rule scoped to your exposed hostname (or the API paths /oauth/*, /.well-known/*, /vault/*) that skips Bot Fight Mode, Managed Rules, and the Browser Integrity Check.
- If Browser Integrity Check is on, disable it (or skip it for those paths).
- If you put the hostname behind Cloudflare Access (Zero Trust), remove that policy — the hub does its own OAuth, and an outer Access gate blocks the API.
Confirm it's this. From any non-browser tool, hit your public origin with a non-browser user-agent — e.g. curl -A python-requests https://<your-host>/.well-known/oauth-authorization-server. If Cloudflare's 403 “Access denied” HTML page comes back (rather than a hub response) while a normal browser loads the same URL fine, that's the cause. The failed token exchange also won't appear in ~/.parachute/hub/logs/hub.log — Cloudflare blocked it before it ever reached the hub.

Found something we missed? Open an issue.