Understanding the differences between HAPI and Happy
Happy is an excellent project. So why build HAPI?The short answer: Happy uses a centralized server that stores your encrypted data. HAPI is decentralized — each user runs their own hub, and the relay server only forwards encrypted traffic without storing anything. These different goals lead to fundamentally different architectures.
Application-layer E2EE (client encrypts before sending)
WireGuard + TLS via relay; or none needed if self-hosted
Deployment
Multiple services (PostgreSQL, Redis, app server)
Single binary
Complexity
High (E2EE, key management, scaling)
Low (one command)
Choose HAPI if: You want data sovereignty, self-hosting, and minimal setup.Choose Happy if: You need a managed cloud service with multi-user collaboration.
Self-hosted: Run on your own server or use Cloudflare Tunnel / Tailscale — no E2EE needed since you control the full pathPublic relay: Use hapi hub --relay for E2E encrypted access via WireGuard + TLS — the relay only forwards opaque packets
Goal: Multi-user cloud platform │ ├──► Server stores user data │ └──► Must encrypt everything (application-layer E2EE) │ ├──► Many concurrent users on one server │ └──► Must scale horizontally (PostgreSQL, Redis) │ └──► Multiple devices per user └──► Must sync encrypted state across devices
Result: Sophisticated infrastructure with zero-knowledge server
Goal: Self-hosted tool — each user runs their own hub │ ├──► Data never leaves your machine │ └──► No application-layer E2EE needed │ ├──► Each user has their own hub │ └──► No horizontal scaling needed; unlimited users in aggregate │ ├──► Self-hosted access (own server/tunnel) │ └──► You control the full path — HTTPS sufficient │ └──► Public relay access └──► WireGuard + TLS (tunwg) — relay forwards only
The architectural differences stem from a centralized vs decentralized design:Happy: Centralized cloud server that stores your encrypted data. The server never sees plaintext (zero-knowledge), but it does hold your data. This requires application-layer E2EE, key management, and distributed infrastructure (PostgreSQL, Redis, scaling).HAPI: Decentralized — each user runs their own hub. Your data stays on your machine. For remote access, you can self-host (own server or tunnel — no E2EE needed since you control the path) or use the public relay (WireGuard + TLS via tunwg — the relay only forwards encrypted packets it cannot read). This achieves one-command deployment with zero external dependencies.
The core tradeoff: Happy solves the “untrusted server” problem with sophisticated encryption. HAPI avoids the problem entirely by keeping your data on your own machine.