PAN — Personal Area Network
Bootstraps a heterogeneous home mesh (Fire Stick, Android, Mac) from one command — NATS messaging, WASM plugins, Syncthing sync, no cloud.
The Home Cluster Fragmentation Problem
Managing a heterogeneous home cluster — Fire Stick (ARM32 Linux), Android phone, MacBook — means SSHing into each device, manually installing services, and checking health separately. When a device crashes, you do not know until something breaks. Home networks today include streaming dongles, phones, NAS appliances, and development machines — each a different architecture, OS, and software stack.
Keeping a Syncthing data sync layer, a SilverBullet notes server, a go-git HTTP host, and a NATS messaging bus running across all of them is a parade of manual steps. Each device needs its own binary variant, its own package manager, its own dependency resolution. The Fire Stick runs ARM32 Linux with no package manager to speak of; the Android phone runs a Linux userland through Termux; the MacBook is x86_64 (or Apple Silicon) with Homebrew. There is no common substrate.
Existing solutions — Ansible, Chef, Puppet — assume homogeneous targets, SSH accessibility, and server-grade uptime. They do not handle set-top boxes that sleep, phones that roam networks, or ARM32 devices without a compiler toolchain. Docker assumes a common kernel; not every device runs one.
Pan replaces the checklist with: pan deploy firestick. One command discovers the target, pushes the right binary for its architecture, bootstraps the NATS leaf node, installs Syncthing, and registers the device in the mesh. From there, all control flows through NATS topics; no more SSH session roulette.
Multi-Binary Mesh with NATS Leaf Topology
Pan is a multi-binary Go system: pan CLI, pan-agent (device daemon with WASM plugin host), pan-server (web dashboard), pan-gitd (pure-Go git HTTP server). Orchestration is built on NATS with leaf node topology — each device runs a NATS leaf node connecting outbound to the Mac hub (no inbound ports required). Control flows through NATS pub/sub; data sync through Syncthing P2P. Device behaviour is hot-extensible via WASM plugins pushed through Syncthing.
# Deploy to a new device
pan deploy firestick
# Subscribe to device health on NATS
nats sub "pan.health.>" --server nats://macbook.local:4222
[12:34:01] pan.health.firestick → {"cpu":12,"mem":64,"uptime":"3d"}
[12:34:02] pan.health.galaxy → {"cpu":8,"mem":128,"uptime":"12h"}Device Mesh Topology
Device Bootstrap Sequence
Languages, Transport & Runtime
Key Design Records
.wasm into the plugins directory and the agent picks it up. Typed dispatch via Extism eliminates the string-parsing fragility of shell-based extension.
pan deploy SSHs into the target, scp-s the correct binary, and starts pan-agent as a system service. No chicken-and-egg problem of deploying an agent to bootstrap agent connectivity. Agent-initiated reverse tunnels (e.g. frp/ngrok) would require a public relay and add latency to every control message.
go-git is a pure-Go git implementation with years of production use, complete refspec negotiation, and packfile support. WASM-based git runtimes (wasm-git) are promising but lack smart HTTP protocol support, have larger binary sizes due to the WASM runtime overhead, and introduce another failure domain at home scale where performance is irrelevant.
Development Journey
Results & Industry Alignment
- Active development with production deployment on home infrastructure — Fire Stick, Galaxy Note 9, and MacBook running in sync
- Industry alignment: Google BeyondCorp zero-trust principles — every device authenticates individually and connects outbound; no assumed network trust
- Industry alignment: Apple ecosystem orchestration — device mesh, continuity, and handoff concepts applied to a heterogeneous (non-Apple) fleet
- Industry alignment: AWS Lambda/Envoy WASM runtime — WASM plugin sandbox for hot-reloadable device behaviour, analogous to Lambda@Edge and Envoy filters