Getting started

A four-part onboarding path that takes you from a 5-file local Pear chat to the full hello-pear-electron production scaffold to a live OTA cycle and a multisig release.

Build a peer-to-peer desktop chat app with Pear, then evolve it into the same shape as the official hello-pear-electron template, and finally release it over the air.

There are two ways in. Start from the finished template and learn your way around it, or build the same app up from scratch across a four-part path.

Start from the template

The fastest way to a production-shaped app: clone the official boilerplate and learn where each piece lives.

Start from the hello-pear-electron template

Clone the boilerplate, map renderer ↔ main ↔ worker, and add a feature end to end.

Build it up from scratch

Prefer to learn the moving parts by building them? Take the four-part path. Each part is a single sitting. Read them in order — every part starts from the previous part's code.

Build a peer-to-peer chat

Five files, ~15 minutes. Static PearRuntime.run, Hyperswarm, no persistence.

Reshape part 1 into the hello-pear-electron scaffold: a Bare chat worker, an Autobase room with blind-pairing invites, on-disk persistence, a separate OTA updater worker, and a polished Tailwind UI with a copy-invite button.

Ship your app

pear touch + upgrade link, electron-forge make, pear build, and pear stage to publish your first version.

Deploy over-the-air updates

Run the installed app, ship a second version, watch the OTA cycle, and preview multisig.

What you'll build

A small Electron window with a message list, an input, and a peer counter. Two instances on the same machine — or on different machines anywhere on the public internet — discover each other through the DHT and stream messages directly.

Each part adds one layer to that picture:

Part 1 wires the renderer ↔ main ↔ worker ↔ peers path with the smallest amount of code.
Part 2 reshapes that into the full hello-pear-electron production scaffold: a dedicated Bare chat worker, an Autobase-backed room with blind-pairing invites, a HyperDB schema, on-disk persistence, a separate OTA updater worker, and a polished Tailwind UI — the vanilla renderer that every peer-to-peer how-to extends.
Part 3 turns the project into a release pipeline: signed distributables, a pear:// upgrade link, and the first published version on a Hypercore.
Part 4 puts that release pipeline in motion: run the installed app, ship a second version, watch OTA fire end-to-end, and preview the production stage → provision → multisig flow from the release pipeline.

Before you start

Node.js v22.17 or newer and npm v10.9 or newer
A POSIX-style terminal (macOS, Linux, or Windows with WSL)
An IDE or text editor
The pear CLI (npx pear) — only required for parts 3 and 4 (shipping and updating)

Each part lists any extra npm packages it adds.

Where to go next

Pear desktop application architecture — why Bare workers, the preload bridge, and the OTA updater look the way they do.
Storage and distribution — where pear.storage lives in development versus production.
Release pipeline — the stage → provision → multisig flow parts 3 and 4 walk through.
Release pipeline glossary — terms used across the desktop release docs.
The upstream template: holepunchto/hello-pear-electron.