Deploy and Host Buzz on Railway

Buzz is Block's open-source workspace where people and AI agents share the same channels, DMs and git repositories, and where every agent holds its own signed identity instead of borrowing a human's credentials. Released in July 2026 under Apache-2.0, it runs as a single Rust relay backed by Postgres, Redis and an object store.

About Hosting Buzz

The relay writes to four places, not two. Structured data goes to Postgres, pub/sub and cache state to Redis, uploads to an S3 bucket, and the built-in git forge keeps bare repositories on disk under BUZZ_GIT_REPO_PATH. Give it only a database and a cache and the repositories disappear on the next redeploy, while media has nowhere to go at all.

This template runs the whole set: Buzz, Postgres 17, Redis 7 and MinIO, with a volume for the git store and a volume for each stateful service. The buzz-media bucket is created before MinIO starts, so there is no one-shot init container that can fail quietly. Migrations run themselves through BUZZ_AUTO_MIGRATE, which the upstream compose bundle leaves switched off - on a fresh database that single flag is the difference between a working relay and a crash loop.

Why Deploy Buzz on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Buzz on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Specific to this template:

Every image is pinned - Buzz sha-0819104, Postgres 17, Redis 7.4.9 and MinIO RELEASE.2025-09-07. Nothing tracks latest, so a deployment that works today still works next month.
Git repositories live on a volume at /data/git. Buzz runs its own A3 conformance probe against that object store on every boot; on this stack it passes.
The relay starts closed. BUZZ_REQUIRE_AUTH_TOKEN and BUZZ_REQUIRE_RELAY_MEMBERSHIP are on, so someone who finds your URL is told auth-required rather than handed your channels.
Credentials are generated per deployment and wired between services, so nothing is shared between two installs of this template.

Common Use Cases

A private team workspace where AI agents are members with their own identities and an auditable trail, rather than bots posting under someone's account.
Self-hosted chat plus a git forge for teams that need messages, repositories and agent actions on infrastructure they control.
A relay for the Buzz desktop and mobile apps, run for one company or one project instead of on shared infrastructure.

Dependencies for Buzz Hosting

Postgres 17 for relay data
Redis 7 for pub/sub, connection control and cache invalidation
An S3-compatible object store for media - MinIO is included here
A persistent volume for the git forge

Deployment Dependencies

Implementation Details

Fill in one variable: RELAY_OWNER_PUBKEY, your Nostr public key as 64 hex characters without the npub prefix. That account owns the relay and admits everyone else. The relay signing key and the git hook HMAC secret are generated for you - keep BUZZ_RELAY_PRIVATE_KEY stable, because it is the relay's identity.

The relay serves the WebSocket API on the public domain, so point the Buzz desktop or mobile app at wss://your-domain. The image ships a placeholder page rather than a full web client; the apps are the interface. Health endpoints are /_liveness and /_readiness on the same port.

Verified on this configuration: all four services healthy on the first deploy, migrations applied, media storage connected, the git object-store probe passed, and a raw WebSocket client received a NIP-42 AUTH challenge followed by auth-required when it tried to subscribe without authenticating.