Docs
Reference material for the Parachute ecosystem
Parachute is open source. The most direct way to read about how it works is in the code itself — start with each repo's README.md. Below are the operator guides, starter prompts, and design notes that anchor day-to-day use and architectural direction.
Starter prompts
Paste these into any MCP-connected AI client (Claude.ai, Claude Code, Codex, Goose, Cursor…) to get going fast.
-
Set up your vault
The AI inspects what's already in your vault, interviews you about how you think, and proposes a tag/schema structure — so you start with opinions that fit you, not a blank graph. The first thing to run after connecting MCP.
-
Build a custom UI over your vault
A prompt that walks the AI through scaffolding a custom SPA on the surface SDK (
@openparachute/surface-client+surface-render) and deploying it to GitHub Pages (or any static host) — OAuth sign-in, typed vault client, note rendering all imported, a front-end shaped for your brain. No Parachute install needed.
Operator guides
Walk-throughs for running Parachute day-to-day.
-
Scripting your vault — automate from bash, Python, or JS
Your vault is an HTTP API. Mint a scoped, short-lived token with
parachute auth mint-token --ephemeral, then read, write, and query it from any script — cron, CI, a quick Python one-liner. Plus how to think about tags, schemas, and paths so an agent (or future you) can find things later. -
Multi-user — host your hub for friends and family
One hub, many vaults. How to provision an account per person, hand them a default password, and let them connect their own clients — without giving out admin access. The operator-facing companion to the multi-user Phase 1 design note.
-
Git backup — back your vault up to a git repository
Every change you save lands as a commit. Push to GitHub for off-machine backup, open the folder in Obsidian, or just keep a local audit trail. Configure end-to-end from the admin UI — no shell required. Operator companion to the vault-as-git-projection design note.
Architecture design notes
Capturing the shape Parachute is evolving toward.
-
Hub-as-supervisor unification — serve under a process manager everywhere
2026-06-01Parachute runs one way everywhere:
parachute serve— the hub in the foreground supervising every module as a child — kept alive by the platform's process manager (systemd on a Linux VM, launchd on a Mac, the container runtime on Render / Fly). A self-hosted EC2 or Hetzner box now gets the same always-on, reboot-surviving, manage-from-the-admin-UI behavior the hosted deploys do;parachute migrate --to-supervisedmoves a legacy detached install over. Retires the older detached-daemon model. -
Vault as git-canonical — a thought experiment (Architecture C)
2026-05-20Thought experiment, not a roadmap commitment. Explores the radical alternative to A/B from the vault-as-git-projection design: what if git IS the canonical store and SQLite is a runtime cache rebuilt from a git checkout? Maps the trade-offs (cold-start cost, conflict model, attachment wart, schema-history compat, MCP latency) and names the conditions under which we'd revisit. Paired companion to the vault-as-git-projection doc.
-
Vault as git projection — v0.7+ architecture
2026-05-20The v0.7+ arc that makes vault tightly integrated with its git mirror: vault stays the runtime (live SQLite + MCP), the git mirror becomes the canonical at-rest store + audit trail + portability surface. Builds on the lossless portable-markdown export. Three options laid out (sidecar projection, bidirectional sync, vault-as-thick-UI-over-git) with a recommended path.
-
Multi-user Phase 1 — admin-creates-user, force-password-change, per-user vault assignment
2026-05-20Phase 1 multi-user for parachute-hub: admin creates accounts with a default password, users force-change on first login, and each account is pinned to a single assigned vault. Enables one hub to serve N vaults for N people without per-user hosting. Companion to hub#252.
-
v0.6 deploy architecture — single Render container, hub-as-supervisor
2026-05-18The self-host deploy shape locked in for v0.6: one container running hub-as-supervisor, vault / notes / scribe as child processes sharing a single persistent disk, modules installed at runtime via the admin SPA. The deploy mirror of the local model. Surfaced at /deploy/render/ and /deploy/fly/ as peer paths.
-
Module architecture
2026-04-20The canonical module protocol:
info,config,services.json,.well-known/parachute.json. How Vault, Notes, Scribe, and third-party modules plug into a single ecosystem under one HTTPS URL. -
Hub as portal — OAuth and the service catalog
2026-04-20OAuth architecture with the hub as issuer. One ecosystem sign-in, tokens carrying a service catalog, scopes that constrain what a client can reach.
-
Parachute Cloud — architecture sketch
2026-04-20Cloud deployment shape: tenant-per-subdomain, Postgres-backed, CDN-hosted Notes, pooled Scribe. A plausible north star we refine when a first cloud user materializes. Note: this is the long-horizon hosted offering; v0.6 self-host (above) is the path shipping today.
Per-repo READMEs
- parachute-hub — the coordinator:
install,start,stop,expose, and lifecycle for every module. OAuth issuer. - parachute-vault — the knowledge graph. REST + MCP, SQLite-backed. Portable-markdown export/import.
- parachute-surface — the UI host module. Bundles Notes (an installable multi-vault PWA) as its first canonical surface; hosts additional custom SPAs under the same supervisor.
- parachute-scribe — Whisper-compatible transcription API.
- parachute-runner — vault-as-job-substrate. Spawns
claude -pagainsttag:jobnotes for owner-operated automation. (exploration — shipped, not committed-core.) - parachute-patterns — cross-repo conventions (naming, schemas, OAuth scopes, ports) and the cookbook of worked patterns.
Want to follow along?
Read the blogOr see what's next.