A hands-on guide to running Block's open-source human+agent workspace on your own infrastructure.

Most teams juggling AI coding agents right now are living with a quiet kind of friction: Claude Code lives in one terminal, Codex in another, and whatever your team actually decided ends up buried three Slack threads deep, disconnected from the code review that prompted it. Everyone's context is scattered across tools that don't talk to each other.

Buzz, released by Block (the company behind Square and Cash App) in July 2026, takes a different approach. Instead of bolting a chatbot onto Slack, it puts humans and AI agents in the same workspace — same channels, same threads, same audit trail — with agents joining as full members, each with their own cryptographic identity rather than a shared bot token.

It's fully open source (Apache 2.0), and — this is the interesting part for anyone who cares about owning their own infrastructure — genuinely self-hostable. Here's how to stand up your own instance.

What makes Buzz different

Buzz is built on Nostr, the decentralized messaging protocol. That choice matters more than it might sound like at first:

  • Every agent gets its own identity. Not a shared API key everyone half-trusts, but an actual keypair — the same kind of cryptographic identity a human member has. A second signature ties that agent back to the human who owns it, so every action has a traceable chain of custody.
  • Channels, threads, DMs, voice, and git events are all the same kind of object — a signed event in one log. A code review, a chat message, and a CI result all show up searchable in the same place, because structurally, they are the same thing.
  • Agents can actually do things, not just talk. Open a repo, submit a patch, review code, run a workflow, join a voice huddle — the same affordances a human teammate has.

It works with Claude Code, Codex, and Goose (Block's own coding agent) out of the box, via a shared bridge called buzz-acp that translates between the Agent Client Protocol these tools speak and Buzz's own event model.

Before you start

You'll need:

  • A Linux server (a modest VPS is plenty — this isn't a resource-hungry stack)
  • Docker and Docker Compose v2.24.4 or newer
  • A domain name you can point at your server, with a reverse proxy capable of TLS (Caddy, Nginx, Traefik — whatever you're already comfortable with)
  • About 30–45 minutes, most of it waiting on Docker pulls

Buzz ships two different Compose setups, and picking the right one matters: the repository's root docker-compose.yml is for local development only. The one you actually want lives at deploy/compose/ — a proper single-node production bundle with Postgres, Redis, MinIO for media storage, and an optional bundled Caddy for automatic HTTPS.

Step 1 — Clone and configure

git clone https://github.com/block/buzz.git
cd buzz/deploy/compose
cp .env.example .env

Open .env and you'll find a block of CHANGE_ME placeholders. A few are worth understanding rather than just filling blindly:

  • BUZZ_DOMAIN, RELAY_URL, BUZZ_MEDIA_BASE_URL — your actual domain, in the appropriate https:// / wss:// forms.
  • POSTGRES_PASSWORD, REDIS_PASSWORD, BUZZ_S3_ACCESS_KEY, BUZZ_S3_SECRET_KEY, BUZZ_GIT_HOOK_HMAC_SECRET — five independent secrets. Generate each one separately:
head -c 32 /dev/urandom | base64 | tr -d "+/=" | head -c 48

Run that five separate times, once per secret. It's tempting to generate one value and paste it everywhere — resist that. If any single one of these ever leaks, you want the blast radius contained to just that one system, not your database, cache, and object storage simultaneously.

Step 2 — The one value that isn't just a random string

Here's the detail that trips people up: BUZZ_RELAY_PRIVATE_KEY and RELAY_OWNER_PUBKEY are not two independent secrets. They're a real Nostr keypair — the public key is mathematically derived from the private one. Generating them separately with a random-string command produces two values that don't correspond to each other, which will quietly break your relay's entire auth model.

The image ships a proper tool for this. Generate a real, matching pair:

docker run --rm --entrypoint sh ghcr.io/block/buzz:main -c "buzz-admin generate-key"

This prints a public key and a secret key. Put the secret key in BUZZ_RELAY_PRIVATE_KEY, and the public key in RELAY_OWNER_PUBKEY. Treat this pair with real care — it's the root identity of your relay, not something you want to regenerate casually later.

Step 3 — Start it up

./run.sh config    # validates everything without starting anything
./run.sh start

run.sh is a genuinely well-built wrapper — start runs docker compose up -d --wait, meaning it blocks until every service (Postgres, Redis, MinIO, and the relay itself) reports healthy, or tells you clearly which one didn't. Check status any time with:

./run.sh status

If you'd rather let Buzz's bundled Caddy handle TLS automatically instead of fronting it with your own reverse proxy:

BUZZ_COMPOSE_TLS=true ./run.sh start

(If you already run your own reverse proxy for other services on the same box, skip this flag and point your existing proxy at the relay's internal port instead — no need to run two things fighting over ports 80/443.)

Step 4 — Connect the desktop app

Grab a packaged build from the latest release — .dmg for macOS, .AppImage/.deb for Linux, .exe for Windows. On first launch:

  1. Create a new identity key — this is your personal identity, separate from the relay owner key you generated on the server. Back up the private key it shows you immediately; it's stored in your system keychain but isn't recoverable from Buzz itself if you lose it.
  2. It'll detect Claude Code, Codex, and Goose automatically if they're installed, and offer to link them.
  3. Pick a default agent harness (Claude Code is a sensible default if that's your daily driver).
  4. Choose "I already have a community" → "I own the community", and enter your relay's address (wss://your-domain.com).

Step 5 — The membership gate

By default, Buzz's production .env sets BUZZ_REQUIRE_RELAY_MEMBERSHIP=true — meaning your identity can connect to the relay, but can't actually do anything (post, upload an avatar, join channels) until it's on the membership list. You'll hit a 403 Forbidden: relay membership required the first time you try to do something that writes data — and helpfully, the app will show you your own public key (npub format) right there so you can add yourself:

./run.sh add-member npub1yourpublickeyhere --role admin

Back in the app, retry whatever failed, and you're in.

What you actually get

Once it's running, the shift is less about features and more about where work happens. Mention an agent in a channel the way you'd mention a teammate, and it responds in the room — not in a side panel, not in a separate tool. Open a feature branch and a channel appears around it; patches land as signed git events, CI posts results, an agent runs a first-pass review, and the merge decision lives in the same thread as the code that prompted it. Ask "have we seen this error before" at 2am and an agent watching the channel can search months of history and cite the actual threads, not vibes.

The project's own README is refreshingly candid about what's still rough: mobile clients, huddle lifecycle events, and workflow approval gates are all listed as "being wired up," not finished. It's young — launched July 2026 — and self-hosting it means accepting some of that rough-edge risk in exchange for owning your own data and identity model outright.

For a team already deep into agentic workflows and tired of stitching together five different tools to get a coherent picture of what happened and why, that trade is worth taking seriously.

Buzz is Apache 2.0 licensed. Source, docs, and the project's vision documents are at github.com/block/buzz.