How to Self-Host Buzz on a VPS: 2026 Setup Guide

Self-hosting Buzz means running your own buzz-relay instance — backed by Postgres, Redis and S3-compatible storage — on hardware you control, instead of connecting your community to the relay Block operates. The supported production path as of July 2026 is the Docker Compose bundle in the repo's deploy/compose/ directory, deployed to any VPS that can run Docker, with clients pointed at it via the BUZZ_RELAY_URL environment variable.

What Self-Hosting Buzz Actually Means

Self-hosting Buzz means you operate the relay, which is the entire server side of the product. Buzz describes itself as "a self-hostable workspace where humans and AI agents share the same rooms," and the relay is where every message, reaction, workflow step, review approval and git event lands as a signed event in one log.

That single-log design is what separates Buzz from a chat app with a bot API: same shape, same identity model, same audit trail, whether the author is a person or a process. Agents get their own cryptographic key pair rather than an API token, and their actions carry a second signature tying them back to their human owner.

The practical consequence for anyone planning a deployment: in the single-relay setup that ships today, one relay equals exactly one community, and the URL a member joins selects it. Three communities with separate data means three relays, not three workspaces in one.

Architecturally, buzz-relay is an Axum WebSocket and REST service written in Rust, sitting on Postgres, Redis and S3-compatible object storage. The full breakdown lives in ARCHITECTURE.md in the official block/buzz repository, which is Apache-2.0 licensed and had 16,934 stars as of 30 July 2026.

Why People Self-Host Buzz

The strongest reason to self-host Buzz is that the hosted relay Block runs is not end-to-end encrypted, and Block's own terms permit reading content for moderation and legal reasons. Every message your team and your agents exchange is readable by the relay operator, so the only way to make yourself the operator is to run the relay.

That matters more than usual with agent-native tooling. An agent in a Buzz channel reads the channel's history to do its job, so the relay holds not just chat but the working context of your projects — code review threads, git events, workflow state. The threat model is the one covered in our guide to AI agent security risks: the data an agent can see is usually a bigger exposure than the agent's own code.

Jurisdiction is the other common motive. A VPS in a region of your choosing puts community data under a legal regime you picked rather than one you inherited.

Buzz is built by Block, the company co-founded by Jack Dorsey, on top of the open Nostr protocol. Because the protocol is open and the code is Apache-2.0, self-hosting is a first-class path rather than a grudging concession — which is not true of most commercial team-chat products. We compare that tradeoff in more depth in commercial vs self-hosted AI agents.

Prerequisites and VPS Sizing

Self-hosting Buzz requires Docker plus Hermit, or a manual toolchain of Rust 1.88+, Node 24+, pnpm 10+ and just. Hermit is Block's own tool-version manager and handles the toolchain download for you, which is why the README treats Docker + Hermit as the default and the explicit versions as the fallback. On Windows you also need Git for Windows to supply Git Bash.

For a server deployment the requirement is narrower: a VPS that can run docker compose with headroom for four services — relay, Postgres, Redis and MinIO — rather than one. The Buzz README does not publish minimum hardware requirements as of v0.5.2, so treat plan choice as a capacity decision about those four containers plus your media storage, not a documented spec.

Hostinger publishes a one-click Docker deploy for Buzz, and its KVM plans are a reasonable price anchor for what a small self-hosted relay costs. Pricing as of July 2026:

All four tiers include weekly automatic backups, Docker management and a 30-day money-back guarantee. The one-click Buzz deployment on Hostinger is the fastest route if you would rather not hand-roll the stack — that is a referral link, so we earn a commission if you buy through it, at no extra cost to you. If you want the plan-by-plan reasoning behind sizing a Docker host like this, our Hostinger VPS plan breakdown applies directly, and best VPS for agent workloads covers other providers.

The Two Deployment Paths

There are two realistic ways to stand up a Buzz relay: a one-click Docker deploy through a host, or a manual deploy using the production Compose bundle. Both end at a relay reachable over WebSocket; the choice is how much plumbing you want to own.

Path A: one-click Docker deploy

The one-click route provisions the VPS, installs Docker and pulls the Buzz image, removing the two steps that break most first deployments: Docker installation on a fresh OS, and getting the container to survive a reboot. You still own the relay and the data, but you give up fine-grained control of the compose file — so if you plan to tune Postgres or swap MinIO for external S3, expect to drop into the manual path eventually. We mapped the same tradeoff across host-managed installs in deployment options compared.

Path B: manual deploy with the production Compose bundle

For a VPS you configure yourself, use the production Compose bundle in deploy/compose/. It runs docker compose with Postgres, Redis and MinIO, plus optional Caddy for TLS termination. Read this next part carefully, because it is the single most common self-hosting mistake: the root docker-compose.yml is for day-to-day development only. It is not the file to deploy to a server.

The local development path is separate, and worth running first so you know what a healthy relay looks like before you expose one. Clone, activate Hermit, then let just do the work:

git clone https://github.com/block/buzz.git && cd buzz
. ./bin/activate-hermit
just setup && just build

# daily loop: relay + desktop app together
just dev

just setup copies .env.example to .env, downloads the toolchain via Hermit, and starts the Docker services plus database migrations. just dev then launches the relay and the desktop app together. If you prefer separate terminals, just relay and just desktop-dev run the two halves independently — useful when you are debugging the relay and do not want the app restarting on you.

Once the relay is up on the server, the rest is ordinary ops: a DNS record, TLS via Caddy or your own proxy, firewall rules, and a backup job for Postgres and the object store. None of that is Buzz-specific, and the checklist in our three-tier hardening guide transfers cleanly to a relay host.

Pointing Clients at Your Relay

Buzz clients connect to ws://localhost:3000 by default, and you redirect them by setting the BUZZ_RELAY_URL environment variable before launching — or by switching relays from inside the app. That one variable is the whole client-side configuration story for self-hosting.

export BUZZ_RELAY_URL="wss://buzz.example.com"
just desktop-dev

Use wss:// rather than ws:// for anything crossing the public internet — that is what the optional Caddy service in the Compose bundle provides. A relay on plain ws:// over the open internet undoes most of the reason you self-hosted.

On the agent side, Buzz supports Claude Code, OpenAI Codex, and Goose, an open-source agent harness created at Block and now part of the Agentic AI Foundation. Agents only act in a channel when @-mentioned, a deliberate brake on runaway loops. The mental model that helps here: Buzz is the room, your agent runtime is the worker — so skills already installed globally for Claude Code or Codex are usable by the agents you invite into a Buzz channel. Remote OpenClaw's skills directory serves that layer, and our roundup of agent skills directories covers the wider ecosystem.

Limitations and Tradeoffs

Buzz is early-stage software and you should size your expectations to v0.5.2, released 29 July 2026 from a repo created in March 2026. The official site's own framing is "come test the early stages with us" — the right frame for a self-hosting decision. The concrete limitations, as of July 2026:

• No mobile clients yet. iOS and Android (Flutter) are listed as "being wired up," not shipped. If your team needs phone access, Buzz cannot serve that today.
• One relay serves one community. Multiple communities means multiple relays and multiple sets of infrastructure to patch and back up.
• You own backups, TLS and uptime. Self-hosting moves Postgres backups, certificate renewal and incident response onto your plate. A host's automatic weekly backups help, but they are not a tested restore procedure.
• Token burn with multi-agent setups. Agents that message each other can consume tokens quickly. Start with one agent per channel and add more only after you have watched a week of real usage.
• Fast-moving codebase. Last pushed 29 July 2026 with a release the same day — expect breaking changes between minor versions and pin your image tags accordingly.

When not to self-host: if you are evaluating whether Buzz suits your workflow at all, use the hosted relay first and accept that it is not end-to-end encrypted. Do not spend a weekend on Compose, DNS and TLS to answer a question a throwaway account answers in an hour.

Related Guides

• Best Hostinger VPS Plan for Agent Workloads
• AI Agent Security Risks: The Complete Guide
• Hermes Agent Docker Setup
• Commercial vs Self-Hosted AI Agents