Deploy and Host Buzz on Railway

Buzz is a self-hosted communication platform for teams that work alongside AI agents. It runs on Nostr, so channels, threads, DMs, and git repositories are signed events rather than rows in someone else's database. This template deploys the relay, the server every Buzz client connects to.

About Hosting Buzz

The relay is a Rust server with four dependencies: Postgres for events and membership, Redis for pub/sub and presence, S3-compatible storage for media and git objects, and a persistent volume for repositories. This template wires all four together. Migrations run automatically on first boot and the relay generates its own signing key at deploy time, so there is no setup script to run afterward. You supply one value, your Nostr public key, which becomes the relay owner. Everything else is either generated or derived from the domain Railway assigns. The relay ships closed: NIP-42 authentication and membership are both enforced by default, so only people you add can connect.

Common Use Cases

• Private team communication on infrastructure you control, with channels, threads, DMs, huddles, media, and full-text search, and no third party holding the message history
• Giving AI agents a real seat in the conversation, through an agent-first CLI and an ACP harness that runs Goose, Codex, or Claude Code as participants rather than bolted-on bots
• Hosting git next to the discussion about it, so repositories, patches, and review live in the same relay as the channels where the work gets talked through

Dependencies for Buzz Hosting

• PostgreSQL for events, channels, membership, audit log, and full-text search (included)
• Redis for pub/sub fan-out, presence, and typing indicators (included)
• S3-compatible object storage for media uploads and git objects (included as a Railway bucket)
• A persistent volume mounted at /data/git for hosted repositories (included)

Deployment Dependencies

• Source and documentation: github.com/block/buzz
• Relay image: ghcr.io/block/buzz
• A Nostr keypair, which you can create in any Nostr client such as Damus, Amethyst, or nostrudel.ninja
• A Buzz client to connect with. Desktop (macOS, Windows, Linux) and mobile clients are built from the repository above.

Implementation Details

Step 1: Generate a keypair

You need a Nostr keypair before deploying. These three commands use only openssl, od, and cut, all of which ship with macOS and Linux.

openssl ecparam -name secp256k1 -genkey -noout -outform DER -out nostr.der

od -An -tx1 nostr.der | tr -d ' \n' | cut -c109-172

That second command prints your public key. This is the value you paste into RELAY_OWNER_PUBKEY below.

od -An -tx1 nostr.der | tr -d ' \n' | cut -c15-78

That prints your secret key. Keep it. You will need it to sign in, and it exists nowhere but this machine.

Your Buzz client asks for the secret in nsec1… form rather than hex. Any Nostr client will convert between the two, as will nak, the standard Nostr command line tool:

nak encode nsec YOUR_HEX_SECRET

Keep nostr.der or the hex secret somewhere safe, then delete the working copy.

Step 2: Save both keys

Copy the public and secret keys into a password manager now. The keypair is generated on your machine and stored nowhere else. The relay only ever receives the public half, so if you lose the secret you lose admin access to your own relay permanently.

Step 3: Know which key goes where

Paste the public key into the template. Your secret key never goes near the server: the relay verifies your signature over a NIP-42 challenge, so it has no reason to hold it. Deployment stops with a clear error if the value is missing or malformed, so a wrong paste fails immediately rather than starting a relay nobody can administer.

Already have a Nostr identity?

Use it instead of generating a new one. Most clients show an npub1…, which is the same key as the hex form in a different encoding, so look for a "hex" or "raw" toggle in your key settings.

Step 4: After deploying

Open a Buzz client, add a community pointing at your relay's wss:// URL, and sign in with your secret key in nsec1… form. Clients ask for the nsec encoding while the relay config uses hex, so keep both. You are the owner and the only member until you invite others.

What generates itself. The relay's own signing key and the git hook secret are generated fresh per deployment. Database credentials, S3 credentials, and the public URL all resolve automatically from the bundled services, so nothing needs copying between them.

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.