Running your own relay
Self-hosting a Buzz workspace is no longer a build-it-yourself project. The relay is a single Rust binary with three dependencies — PostgreSQL, Redis and an S3-compatible object store — and there are now documented paths for standing the whole stack up. Three are worth knowing, and they answer different questions:
Docker Compose on a machine you control. Block ships the stack in the Buzz repository under deploy/compose: copy .env.example to .env, fill in the secrets, ./run.sh start. On a VPS with a domain, BUZZ_COMPOSE_TLS=true adds a Caddy container that terminates HTTPS with automatic Let's Encrypt certificates. This is the route where the data genuinely sits on hardware you answer for.
The Tailscale template. A community project from Krishna C, ciram-co/selfhost-buzz, runs the same stack on a spare machine — a NUC, a home server, a Mac that stays on — reachable only from devices on your private Tailscale network Tailscale. No port forwarding, no public DNS, no attack surface: to anyone not on your tailnet, the relay does not exist. TLS and a stable name come from Tailscale. The setup script generates the secrets for you.
Railway one-click. Block publishes a Railway template that deploys the stack in minutes. Be precise about what this is: a relay you operate on Railway's cloud. The data does not live on your hardware, so it moves the hosting question rather than answering it — fine for evaluation, not an answer to a residency requirement. One sharp edge: the relay's generated signing key lands in Railway's variable store, not on anything you hold. Copy it out somewhere safe immediately.
Whichever route, two facts shape everything else.
The relay has its own identity, separate from yours. BUZZ_RELAY_PRIVATE_KEY is the relay's signing key — generate it fresh (buzz-admin generate-key, or the setup script does it), never reuse your personal key, and never rotate it casually: clients that pinned the old pubkey will reject the relay's signatures. RELAY_OWNER_PUBKEY is you — the one account a closed relay cannot remove. The relay signs its own events; it should not be doing that as you. Since v0.5.19 the key is required at startup: earlier relays started without one and silently fell back to a shared identity, so misconfigured self-hosted relays looked like the same relay. The software now enforces what this page already asked for.
The address is the community
The relay keys its community on the exact RELAY_URL, byte for byte — scheme, host and port included. Change it later and clients arrive at what looks like a fresh, empty community; the old one is still in the database, filed under the old address. Decide the address before inviting anyone, and use 127.0.0.1 rather than localhost for local testing, because agents canonicalise one to the other.
Why it matters to you
The hosting decision (Decide your data residency and hosting model) has until now had a candid but uncomfortable third option: self-hosting was routine for an infrastructure engineer and a non-starter for everyone else. These paths change that. A competent generalist with an afternoon can now stand up a relay that satisfies "client material stays on our hardware" — which converts self-hosting from an aspiration into a real option your practice can pick.
The other side of the ledger is unchanged: whoever runs the relay is the operator, with everything Sovereignty trade-offs says that implies. You hold the backups, you carry the availability, and you can read everything — which your workspace members are entitled to know.
How to apply it
Match the route to who must reach the workspace. Practice-internal work suits the Tailscale template: private by construction, and the machines are ones you already own. A workspace that clients or guests must reach without installing anything wants the VPS route with a real domain. Railway is for trying Buzz out, and for nothing you would have to defend later.
Treat RELAY_URL as a decision, not a default. It is the community's identity; pick the permanent address first.
Keep the relay's key and your key apart, and back up .env as carefully as the database — the relay's private key is the relay, and regenerating it makes every client see a different relay. ./run.sh backup-hint prints the full list of what to protect: the relay private key, the Postgres data, the object-store bucket, the git volume, and your owner keypair. On the Tailscale template, scripts/backup.sh dumps the database but not the media volume — cover that separately.
Test a restore once before the workspace holds anything you would mind losing. A backup that has never been restored is a hope, not a backup.
Pin your version. On the compose stack, ./run.sh upgrade; on the Tailscale template, pin BUZZ_VERSION to a specific image tag rather than tracking main — the images publish commit tags, not version numbers.
If you ignore this
A relay stood up on defaults and enthusiasm works fine right up to the first incident. Then the failure modes are all of the permanent kind: a changed address that orphans the community, a regenerated relay key that no client recognises, a dead disk with no dump of the database. Relays and communities states the blunt rule — if the relay is lost permanently, so is the workspace, unless someone kept an export. When you self-host, that someone is you, by name.
Examples
Moving from renting an office to owning the building. Nobody else holds keys anymore — and nobody else fixes the roof. The street address is what everyone's keys are cut for; change it and their keys open an empty building.
A two-person practice runs the Tailscale template on a NUC in a cupboard. Laptops and phones reach the workspace from anywhere, the internet at large cannot see it exists, the database is dumped nightly, and the media volume is copied weekly. Client engagements that require it get this relay; everything else stays on hosted infrastructure.
Deploying the Railway template and telling a client their data is now "self-hosted on our own systems". It is self-operated on Railway's cloud — a different claim, and the difference is exactly the one the client's data-protection adviser will ask about.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026