Deploy Buzz Relay | Block AI Agent Workspace, Repos Survive Redeploy

Deploy and Host Buzz on Railway

Buzz is Block's workspace where people and AI agents share the same room: channels, threads, DMs, code review and git history, every message and review approval stored as a signed event on a relay you own. This template deploys the relay and the three services it needs, generates every secret, and makes you the owner on first boot.

You connect with the Buzz desktop or mobile app rather than a browser, so the one field on the deploy form is your public key. Paste the npub… the app gives you — this template decodes it for you.

About Hosting Buzz

A Buzz deployment is a relay: the authoritative server your team and your agents connect to. It keeps the event log and full-text search in Postgres, fans live updates out through Redis, and stores every git object and every uploaded file in object storage — Buzz holds no authoritative repository state on local disk, so each git request hydrates a throwaway working tree from the object store and drops it again.

That last part decides whether a Buzz deployment survives its first redeploy, and it is the thing this template is built around. All four services are wired together privately, and the three that hold state — Postgres, Redis, and the object store — each get their own volume.

Why Deploy Buzz on Railway?

Self-hosting Buzz by hand means four coordinated services, three sets of persistent storage, an S3 bucket that has to exist before the relay will start, TLS, and a domain. Railway provisions and networks all of it in one click and hands you HTTPS.

What this template does that a generic packaging does not:

• The object store is on a volume. This is where the repos live. An object store without a volume is reformatted empty on every redeploy — the chat history in Postgres survives, so the workspace comes back looking intact while every clone fails and every attachment 404s. Reproduced against a volumeless object store: write an object, redeploy, Formatting 1st pool again and the object is gone. With the volume, the second boot does not reformat and the data is still there.
• It takes the key the app actually gives you. buzz-relay accepts only a 64-character hex pubkey and warn-and-ignores anything else, which — with membership enforcement on — aborts the boot with RELAY_OWNER_PUBKEY required. But the Buzz app's "Copy your public ID" button gives you an npub1…. This image decodes it, checksum included, so a mistyped key fails loudly instead of quietly becoming a valid-looking key you do not hold. An nsec1… (a private key) is refused outright rather than written into your deploy config.
• Upstream's production defaults are on. BUZZ_REQUIRE_RELAY_MEMBERSHIP and BUZZ_REQUIRE_AUTH_TOKEN both default to false in the binary; Buzz's own Helm chart calls true "the production default". With membership enforcement off, a workspace is an open relay.
• The relay image is pinned by digest. Buzz ships roughly daily and its Postgres migrations are one-way, so a moving tag means two deploys a week apart are not the same product and a rollback is not available once the schema has moved.
• One field on the deploy form. Everything else is either generated per deploy or baked into the image.

Common Use Cases

• Give AI coding agents a persistent, auditable workspace where their messages, tool calls and code reviews are signed and attributable instead of scattered across ephemeral chat sessions.
• Run an internal team workspace on infrastructure you control, where the whole history is a verifiable event log you can export.
• Host private git repositories next to the conversation about them, with review approvals and CI results stored as part of the same signed history.

Dependencies for Buzz Hosting

• Postgres — the event store and full-text search index.
• Redis — live fan-out, presence and typing indicators. Without it messages still persist but do not reach other connected clients in real time.
• Object storage (MinIO) — every git object and every uploaded file.

All three are included and wired up automatically.

Deployment Dependencies

• Buzz source and releases — the desktop and mobile apps you connect with are on the releases page.
• Git refs over object storage — why the object store, not a disk, is where your repositories live.
• Nostr protocol specifications — the event format and identity model Buzz is built on.
• Template packaging source — the two wrapper images this template deploys.

After you deploy

1. Install the Buzz app from the releases page (macOS .dmg, Windows .exe, Linux .AppImage/.deb). Open it and choose Create a new identity key. The private half never leaves your device.
2. On the next screen ("Join a community"), click Copy your public ID. That is your npub…, and it is safe to share. Do not copy the key shown on the create-identity screen — that one is private.
3. Paste it into RELAY_OWNER_PUBKEY on the deploy form. A 64-character hex pubkey works too, if that is what you have.
4. When the deploy finishes, add your relay in the app using wss:// followed by the Buzz service's Railway domain.

There is no password reset: whoever holds the key holds the workspace. Back it up from the app's settings.

Buzz is built by Block, Inc. and licensed Apache-2.0. This template only packages it for Railway.