Deploy to a VPS

Why this path

A laptop sleeps; a sleeping hub can't answer your phone or your AI's connector. A small always-on Linux box fixes that without handing your data to anyone — you rent the box, you own everything on it.

This is the bun-native happy path. The exact same install flow you'd run locally — bun add -g @openparachute/hub && parachute init — on a server that never sleeps. No Dockerfile to maintain, no container build to keep in sync with releases. The hub installs itself as a systemd unit (survives reboots and crashes), supervises every module as a child, and parachute upgrade keeps the stack current.

Hetzner and DigitalOcean are worked through below, but any Ubuntu VPS — EC2, Linode, Vultr, a box in your closet — walks the identical steps.

The flow

Six steps from a fresh box to a hub your AI can reach. The provider-specific bit is just step 1 (provision); everything from step 2 on is identical regardless of where the box lives.

1. Provision a small Ubuntu box

Smallest shared-CPU instance with ~2GB RAM (1GB works for hub + vault alone; 2GB is comfortable for vault + surface + scribe). Image Ubuntu 24.04 LTS. Add your SSH public key at creation. Note the public IPv4. The Hetzner and DigitalOcean worked examples below cover the click-path on each.

2. SSH in

Or your non-root user, if you created one.

3. Install Bun 1.3+

Then open a fresh shell and confirm bun --version is 1.3 or newer (a fresh shell puts ~/.bun/bin on your PATH).

4. Install + init

This installs the parachute binary, installs and starts the hub as a systemd unit on :1939 (survives reboots), installs the vault, and — because you're on an SSH session — pre-selects public exposure so the wizard URL is reachable from your laptop.

5. Finish the wizard

Two ways, your choice:

• Headless — parachute init --cli-wizard walks Account → Vault → Expose right there in the terminal.
• Browser — open the /admin/setup URL that init prints, in your laptop browser. Paste the one-time bootstrap token init shows (it prints the token when it exposes publicly).

6. Clean public HTTPS URL

A Cloudflare Tunnel on a domain you own — this is what claude.ai's connector needs. The done screen hands you a copy-paste claude mcp add command with a fresh token; point any other client at <hub-origin>/vault/<name>/mcp.

Hetzner — worked example

Hetzner Cloud (console.hetzner.cloud) is the cheapest of the two and a great default if you're in Europe or don't mind a EU/US-East region.

• Server type: CX22 — 2 vCPU shared, 4GB RAM, 40GB disk, ~4–5 EUR/month (~$5, including the IPv4 surcharge; approximate — check current pricing). The CAX (ARM) line is cheaper still, and Bun runs natively on arm64.
• Location: nearest region — Falkenstein / Nuremberg (DE), Helsinki (FI), Ashburn VA / Hillsboro OR (US).
• Image: Ubuntu 24.04. Add your SSH key.

Create → wait ~30 seconds → ssh root@<ip> → continue from step 3 above.

DigitalOcean — worked example

DigitalOcean (cloud.digitalocean.com) is the most GUI-friendly option, US-centric, and slightly pricier.

• Droplet: Basic / Regular shared CPU. 2GB / 1 vCPU / 50GB at ~$12/month is the comfortable floor (1GB at ~$6/month runs hub + vault but is tight with surface + scribe). Approximate.
• Region: nearest you.
• Image: Ubuntu 24.04 x64.
• Authentication: SSH Key.

Create → ssh root@<ip> → continue from step 3 above.

Expose to the internet

On an SSH'd server, parachute init pre-selects public exposure for you. For a clean public HTTPS URL — the kind the claude.ai connector wants:

The apex (example.com) must already be a Cloudflare zone (the free tier is fine). Expose creates the tunnel — don't pre-create it. Each machine gets its own per-hostname tunnel name (no account-wide collision); override with --tunnel-name only to deliberately reuse one. Run the command interactively to be prompted for the hostname.

The cloudflared connector installs as its own managed unit, so the tunnel returns automatically after a reboot.

Pitfalls

Most of these you'll never hit. A few are common enough — the Cloudflare bot-protection one especially — to be worth reading before you wire up the Claude connector.

• Bun 1.3+ required. 1.2.x produces a cosmetic InvalidPackageResolution warning. Run in a fresh shell so ~/.bun/bin is on your PATH.
• Non-root reboot survival needs linger. If you installed as a non-root user, run sudo loginctl enable-linger $USER so the user unit starts at boot. A root install is a system unit and sidesteps this.
• Ports 1939 (hub) / 1940 (vault behind it). Don't expose 1940 — clients use the hub origin + /mcp. With a Cloudflare Tunnel you don't open 1939 or 1940 publicly at all.
• RAM headroom. ~512MB fits the stack at sub-1000 notes; 2GB is comfortable with surface + scribe.
• Keep current. parachute upgrade (add --channel rc for release candidates). DB migrations run on the first post-upgrade boot.

What you get

One systemd unit running the hub on :1939 — with reboot survival and admin-UI module management. The hub supervises vault, surface (with Notes auto-bootstrapped as its first hosted surface), and Scribe as child processes. Everything lives under ~/.parachute/ on the box's own disk — you fully own it. See the v0.6 deploy architecture note for the full shape.

Cost

All figures approximate — check current provider pricing.

• Hetzner CX22: ~4–5 EUR/month (~$5), including IPv4. The ARM CAX line is cheaper.
• DigitalOcean: ~$12/month for the comfortable 2GB droplet (~$6/month for 1GB, tighter).
• Domain + Cloudflare: the Cloudflare zone is free; you only pay for the domain you already own. TLS is included via the tunnel.

Expected total: roughly $5–12/month for hub + vault + surface (with notes-ui auto-bootstrapped) + scribe running together, depending on provider and instance size.

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 VPS path is the trade.

Why a VPS over a container PaaS

The bun-native path is our tested, exercised happy path — the same commands we run on laptops, in CI, and in every install doc.

A container PaaS (Render's render.yaml, Fly's Dockerfile) is a genuinely supported peer, and great for one-click GUI ops or portable volume snapshots. But its build diverges from that happy path — image CMD boot, modules onto a mounted disk, disk-vs-image upgrade semantics — code the laptop and VPS paths don't exercise.

On a VPS you get the exact architecture that runs on a laptop (hub-as-supervisor under systemd, modules as children sharing ~/.parachute/) with reboot survival and admin-UI module management, on a box that never sleeps and that you fully own. If you'd rather click than SSH, Deploy to Render and Deploy to Fly.io are the container alternative.

What comes next

• Local install — the same stack on your own machine. Free, but sleeps when your laptop sleeps.
• Deploy to Render and Deploy to Fly.io — the container PaaS paths, if you'd rather click than SSH.
• v0.6 deploy architecture — the design note explaining why it's hub-as-supervisor.
• parachute-hub issues — deploy questions, bugs, friction. We read all of them.