BunnyMeshDB syncs structured data across your laptops, servers, and LXCs — TLS everywhere, offline-friendly, and small enough for Alpine. No cloud in the middle. No lock-in. Just your machines, talking.
One static binary. Zero runtime dependencies. A mesh that keeps working when the internet — or your VPN — doesn't.
Federated sync over libp2p with noise-authenticated peers and TOFU key pinning. Any node can sync; no central server, no account, no cloud dependency.
rustls HTTPS and noise-encrypted p2p channels by default. Capability-scoped admin (L1–L3) with key rotation, per-peer namespace allow-lists.
FUSE overlay filesystem: read and write mesh data from any program that speaks files. TTL-aware, expiring entries honored, safe for daemon ownership.
ql language with JSON-Schema-typed buckets and secondary indexes. Range scans, TTLs, and change feeds over SSE — built in, not bolted on.
One static binary — no deps to install. ~8 MB RAM idle, ~0.4 ms per authenticated request, both measured. Ubuntu, Debian, Fedora, Alpine, LXC, Docker, NAS, Raspberry Pi — x86_64 and aarch64 builds.
HLC timestamps, merkle-batched records, deterministic conflict handling, backups and key rotation built in. 129 automated tests green on every release.
A full audit of the mesh, HTTP, and filesystem surfaces found 26 issues — including 2 critical. Every one is fixed and regression-tested. The threat model, trust boundaries, and audit trail live in SECURITY.md in the repo.
BunnyMeshDB is opinionated: edge-first, mesh-native, LAN-trusting. Here's exactly where that wins and where it doesn't.
| BunnyMeshDB | SQLite / Postgres | etcd / Redis | CRDT libraries | |
|---|---|---|---|---|
| Sync model | Native mesh — no hub, peers sync directly | Replication add-ons, leader-centric | Raft cluster, needs ≥3 nodes | You implement it |
| Offline / edge-first | First-class: batch sync + FUSE mount | Poor — server is the source of truth | No | Yes, but it's a library, not a database |
| TLS & auth | Baked in: noise + rustls, capability caps, peer ACLs | App-level or VPN | mTLS config, complex at edge | Up to you |
| Footprint | 1 static musl binary, zero deps | Service + deps + config | Cluster of 3 processes | Linked into your app |
| RAM per instance | ~8 MB — measured, one daemon | SQLite in-process, few MB | ~50–100 MB × 3 nodes | Borrows your app's heap |
| Read latency | ~0.4 ms — measured, loopback | ~0.5–2 ms | ~1–5 ms | n/a |
| Query & schema | ql + JSON-Schema types + secondary indexes | Full SQL | KV operations only | n/a |
| Conflicts | HLC + merkle batches, deterministic merge | Last-writer-wins, silently | Linearizable, but no offline writes | Depends on the library |
| Maturity | Audited, pre-1.0, 129 tests | Decades, battle-tested | Mature | Varies |
| License | AGPL-3.0 | MIT / BSD-ish | Apache-2.0 | Varies |
Your data lives on machines you control and should stay there. You want every node usable offline, syncing peer-to-peer without a hub. You're tired of standing up replicas, VPNs, or clusters for a handful of hosts. You love Alpine and one-binary deploys.
You need strong multi-region HA or quorum consensus — BunnyMeshDB is single-writer-per-bucket, not a consensus cluster. You need the full SQL surface or decades of ecosystem tooling. You're building a public SaaS where AGPL-3.0 is a problem. Pre-1.0: expect API polish as it matures.
Static, self-contained, no package manager gymnastics. One binary for Ubuntu, Debian, Fedora, Alpine, LXC, Docker, or bare metal.
# on Ubuntu, Debian, Alpine, or any Linux — grab the static build from bunnymesh.com
$ curl -LO https://bunnymesh.com/downloads/bunnymeshdb-x86_64-unknown-linux-musl.tgz
$ tar xzf bunnymeshdb-*.tgz
# start the daemon — default 127.0.0.1:9100
$ ./bunnymeshdbd
# write and query with the client
$ ./bunnymeshdb put users -- "{\"name\":\"hopper\",\"role\":\"admin\"}"
$ ./bunnymeshdb ql 'SELECT * FROM users WHERE role = "admin";'
ok · 1 row · 12ms
# peer two machines and sync — that's the whole mesh
$ ./bunnymeshdb peer add --name alpine --addr bunnymesh.com:9100 --pin auto
peer added · pinned · namespaces: all shared
# it just works — from here the mesh replicates by itselfEvery release ships one static musl binary for x86_64 and aarch64 — Ubuntu, Debian, Alpine, LXC, Docker, bare metal. Files below list live from the server.
A federated mesh database written in Rust. Each node runs a small daemon (bunnymeshdbd) and keeps its own copy of the data; nodes sync peer-to-peer over authenticated, encrypted channels — no central server, no cloud account, no third party. A client CLI/SDK (bunnymeshdb) offers a ql query language, JSON-Schema-typed buckets, secondary indexes, TTLs, change feeds, and a FUSE overlay that mounts your mesh data as a folder.
Writes carry HLC timestamps and replicate in merkle-batched records so divergence is detected cryptographically. Resolution is deterministic and server-authoritative per bucket — no silent last-writer-wins ambiguity, and batch writes are atomic per record set. If two humans edit the same key, the mesh converges to a defined winner you can audit.
No. Sync happens directly between peers you pin (TOFU key pinning + noise-authenticated identity, so no MITM can impersonate a peer). The mesh works fully offline and exchanges batches when machines meet — over your LAN, Tailscale, or any path you choose.
Yes — that's the point. Releases are statically linked musl binaries with zero runtime dependencies, so the same file runs on glibc distros (Ubuntu, Debian, Fedora) and musl distros (Alpine) alike — plus LXC containers, Docker, NAS boxes, and bare metal. x86_64 and aarch64 builds ship for every release. This site itself is served from an Alpine LXC.
Transit is always encrypted (noise on the mesh, rustls for HTTPS). Admin access is capability-scoped (L1–L3) with key rotation; peers are pinned and can be restricted to specific namespaces so a compromised node can only reach what you grant it. The full threat model, trust boundaries, and the closed audit trail are in SECURITY.md. At rest, the daemon honors filesystem permissions — pair it with disk encryption for the media you care about.
AGPL-3.0. You can run, modify, and self-host it freely; if you make networked modifications and offer them to users, the network-use provision requires sharing those changes under the same license.
It's audited (26/26 findings fixed, including 2 critical, all regression-tested) with 129 automated tests green. Measured on a laptop-class dev box, single node: ~0.4 ms per authenticated request, ~155k requests/s engine throughput, ~17M ops/s through the batch endpoint, and ~8 MB RAM idle. A stock install's built-in rate limiter caps aggregate traffic at ~4,200 req/s by default — a safety rail you tune in node.ratelimit, not a ceiling. It is pre-1.0, so the API may still shift as it matures — pin versions for anything you depend on, and read the changelog. If you need quorum consensus or multi-region HA today, this isn't that tool (yet).