How I self-hosted Buzz for AI agents — and fixed what broke
A firsthand Buzz setup guide covering Docker Compose, private Tailscale access, Nostr identity, ACP agents, failures, fixes, and current limits.
Buzz can become a private Slack-like workspace for humans and AI agents, but the setup is still operator-grade. I ran the Buzz relay on a VPS with Postgres, Redis, and MinIO, then connected the macOS desktop app over an encrypted private Tailscale route. The relay stayed loopback-only; I did not open a public relay port or change public DNS. Nostr keypairs identified the owner and each agent; private key material never belonged in chat, logs, screenshots, or shell history. J.A.R.V.I.S. and F.R.I.D.A.Y. required real ACP/runtime adapters, service supervision, membership, and response policies. Visible agent cards alone were not enough. The complete path worked at a verified checkpoint, but a later live audit found the private-network login had expired and duplicate Desktop-managed workers had appeared. Deployment success is not the same as permanent operational health.
Buzz is a self-hostable workspace built by Block where humans and AI agents can share the same rooms, identities, workflows, repositories, and audit trail. I tested it as an open-source Slack alternative for agents: a private relay on a VPS, Buzz Desktop on my Mac, and two existing assistants connected through agent adapters.
This guide is the version I wish I had before starting. It combines the public architecture with the actual deployment, the mistakes caught on video, the later recovery work, and a fresh health check. Exact secrets, private hostnames, addresses, identities, tokens, and account details are intentionally omitted.
Verified historically; partially degraded in the live check On August 3, the relay, desktop connection, owner identity, channel messaging, and custom agent paths were verified end to end. On August 4, the container stack was still healthy and the relay remained private, but the server's Tailscale node reported that it needed login. The private route therefore required repair before another end-to-end claim could be made. The live audit also found four buzz-acp processes: the two intended persistent launch services plus two workers started by Buzz Desktop for the same J.A.R.V.I.S. and F.R.I.D.A.Y. definitions. The present runtime is therefore not duplicate-free and needs one ownership model per identity.
What is Buzz, exactly?
Buzz looks like team chat, but its architectural bet is different. A relay is the source of truth. Messages, reactions, workflow steps, approvals, media, and Git activity are represented as signed events. A human and an agent use the same identity model: each controls a Nostr keypair and signs its own actions.
Nostr is not a blockchain. There is no mining, token, or gas fee. In this design, a client signs an event, the relay authenticates and verifies it, stores durable state, distributes matching events to subscribers, indexes content for search, and triggers supporting services.
Signed does not automatically mean end-to-end encrypted Signatures prove authorship and integrity. They do not by themselves hide content from the relay or turn the whole workspace into end-to-end encrypted chat. In this deployment, Tailscale protected traffic across the private network path; that is a transport property, not a claim of workspace-wide E2EE.
The public Buzz architecture, simplified for operators Buzz Desktop Human workspace client Ran on Apple Silicon macOS and connected to a Mac loopback endpoint forwarded through an encrypted Tailscale route. buzz-relay WebSocket/REST source of truth Ran on the VPS and stayed bound to loopback instead of a public interface. PostgreSQL Events, channels, search, memberships, workflows, audit data Part of the official single-node Compose stack and included in health checks. Redis Pub/sub, presence, typing, multi-instance coordination Ran inside the private stack; not exposed as an external service. MinIO / S3 Media and object storage Required by the Compose deployment and kept stable across restarts. Nostr keypairs Identity and event signatures Separate identities for the owner and agents; private material was handled as a secret. buzz-cli Agent-oriented JSON input/output Used for bounded verification and messaging without relying on slow UI automation. buzz-acp Relay mentions to ACP agent runtime The bridge layer for Codex/Claude-compatible agents and custom remote runtimes.
Buzz vs Slack: where the comparison holds
Calling Buzz a Slack killer makes a good thumbnail. Calling it a mature Slack replacement would be inaccurate. The useful comparison is about the default operating model: Slack is a mature hosted collaboration product with bots added through an app platform; Buzz is an early self-hostable event workspace where agents are intended to be members from the beginning.
Practical comparison as of August 2026 Primary model Signed-event workspace for humans, agents, workflows, and code Hosted business communication and collaboration suite Hosting Self-hostable; you operate the relay and dependencies Managed SaaS operated by Salesforce Agent identity Separate cryptographic identity and audit trail per agent Apps and bots use Slack's platform permissions and tokens Extensibility Apache-2.0 source, CLI, workflows, ACP, event kinds Mature APIs, marketplace, Workflow Builder, enterprise integrations Operational effort High today: networking, secrets, upgrades, runtime supervision Low for normal use; administration is productized Mobile and ecosystem Early and still being wired up Mature clients, notifications, integrations, support Best fit Builders exploring private agent-native workspaces Teams needing dependable collaboration now
The system I built
My target was intentionally split across two machines. The server already hosted my long-running Hermes/J.A.R.V.I.S. environment. I wanted the Buzz data plane beside that environment while keeping the human client native on my Mac.
Server A pinned Buzz relay deployment using the official single-node Compose shape: relay, PostgreSQL, Redis, and MinIO. Network boundary The relay listened only on server loopback. A private Tailscale path carried desktop traffic; no public relay port or DNS record was created. Desktop The official Apple Silicon Buzz Desktop build was downloaded from Block's GitHub release, checked against release provenance, code-signing, Gatekeeper, and notarization evidence, then installed on macOS. Owner identity Identity material moved through a protected file path and landed in macOS Keychain without being printed or copied through normal clipboard history. Agents J.A.R.V.I.S. used a custom remote ACP adapter; F.R.I.D.A.Y. used a Claude/Bedrock path. Each needed its own identity, runtime, channel access, and response policy. Supervision Persistent services kept the real agent runtimes alive. Buzz management cards were treated as definitions, not duplicate live identities.
Prerequisites before you self-host Buzz
A Linux VPS or server Enough capacity for the relay plus Postgres, Redis, MinIO, migrations, logs, and any colocated agent runtimes. Docker Compose v2.24.4 or newer The official TLS override relies on Compose behavior documented by the project. A client machine For this guide, Apple Silicon macOS with the matching aarch64 Buzz release. A secure reachability plan Public HTTPS/WSS with a real domain and certificates, or a private overlay such as Tailscale. Do not improvise an unauthenticated public WebSocket port. A secret-handling plan Server secrets, owner identity, agent identities, API credentials, Keychain import, rotation, and backup procedures decided before deployment. An agent runtime Codex, Claude Code, Goose, or a custom runtime that can speak ACP directly or through an adapter. Time for validation A running container is not the finish line. Plan liveness, readiness, socket, authentication, send/receive, agent mention, restart, and expiry checks.
Pin first; upgrade only after a working checkpoint The recorded server deployment used public commit 5e0efb0 and the matching sha-5e0efb0 image. The initial Mac installation used the official desktop-v0.5.3 Apple Silicon release from July 31, 2026; its local SHA-256 matched GitHub's release-asset digest. Buzz Desktop v0.5.4 was released August 3, 2026 and the later desktop state reported v0.5.4. The public SHA-256 for Buzz_0.5.3_aarch64.dmg is a8a6eda9512d8f18a51a1babb69d92e41ee89137ebda9c0500d07d77f76e0e63. The public SHA-256 for Buzz_0.5.4_aarch64.dmg is 1b8df3e3e781eb9a37eed02a58d48c474c2c4d04c42388513351320c76eeac82. Tailscale 1.98.10 was used during the setup. These details describe one reproducible build, not a permanent recommendation to stay on an old commit. Check the current release notes, back up state, and test upgrades deliberately.
Step-by-step Buzz setup
Read the architecture and choose the deployment boundary. Decide where the relay, database, cache, object storage, desktop client, and agent runtimes will live. Write the trust boundary down. In my case, the server owned the relay and long-running agents; the Mac owned the human desktop client. If you only want to test Buzz locally, the project quick start is simpler. If you want a VPS relay, use deploy/compose rather than the repository's root development Compose file. Clone Buzz and pin a known source revision. Use the official Block repository. Record the commit and image you deploy so the desktop, relay, migrations, and troubleshooting notes have a real reference point. Create the Compose environment without exposing secrets. Copy the example environment and replace every CHANGE_ME value. Generate strong, stable values for the relay identity, Git hook HMAC, database, Redis, and object storage. Do not paste the completed file into an AI chat or screen recording. Keep the relay private while validating. In this build the HTTP/WebSocket listener used server loopback on port 3030. Your port can differ; the security property is the loopback bind, not that number. Start the stack and verify each dependency. Start the official Compose bundle, then check more than container status. Confirm migrations, relay liveness/readiness, database availability, Redis, MinIO, and the actual listener address. A service bound to 0.0.0.0 when you expected 127.0.0.1 is a security failure even if every container says healthy. Create a private relay path without public exposure. Install and authenticate Tailscale on the server and Mac. The successful historical design used a private raw TCP route to the loopback relay plus a Mac loopback forward. Buzz spoke ws:// through that forward while Tailscale encrypted transport across the overlay. Private WSS certificate provisioning was attempted but timed out or was unavailable in this tailnet. The working checkpoint was private in transit, but it was not application-layer WSS/TLS. Prefer WSS when your tailnet can provision it; otherwise describe the layers accurately. The exact historical forwarding command was not recovered with enough confidence to publish as fact. Use the current Tailscale Serve help to map a tailnet-only TCP listener to the server's loopback relay, keep Funnel disabled, then bind the Mac-side forward to 127.0.0.1 only. Download and verify Buzz Desktop. Choose the artifact that matches your architecture. For Apple Silicon, use the aarch64 DMG. Compare its SHA-256 with the digest published for the GitHub release, verify the code signature and Block team identity, ask Gatekeeper to assess it, and validate the notarization ticket before copying the app into Applications. Connect the desktop client to the private relay. Set the relay URL through Buzz's supported configuration or in-app relay switch. In the verified checkpoint, Buzz used the Mac's ws:// loopback forward; use wss:// when you have a real private or public TLS endpoint. Confirm an established WebSocket, authenticated session, community discovery, and harmless send/receive before importing more tools or agents. Keep the exact host and port consistent across the community configuration and NIP-42 authentication. During this build, transport succeeded while authentication failed because the forwarded port did not match the relay URL being signed. Do not trust a screenshot of an error or success banner by itself. Use the bundled CLI and relay logs to distinguish a stale UI state from the real socket state. Import the owner identity through protected storage. Move the identity only through a protected temporary file or similarly bounded channel, import it into macOS Keychain, and verify access without printing the value. Avoid command substitution or echo patterns that can leak into history, process listings, logs, or screen recordings. Delete the temporary transfer artifact after a successful import. If a private key or password ever appears in chat or a recording, rotate it; deletion from a local file does not undo disclosure. Run a harmless end-to-end messaging test. Send a benign message from the desktop, read it through the authenticated CLI or another client, and send a reply. Verify event authorship, channel, relay acknowledgement, and receipt. Record the timestamp and versions that passed. Add one real agent before adding a team. Give the agent a distinct Nostr identity, register its public identity as a relay member, configure its ACP runtime, default to owner-only responses, supervise the process, add it to one test channel, and validate a mention/reply cycle. Only then add more agents or broader allowlists.
How ACP connects a real AI agent to Buzz
Agent Client Protocol (ACP) is the interface between an agent client and an agent runtime. Buzz's buzz-acp harness listens for accepted relay events, starts or talks to the configured agent over ACP, and gives the agent Buzz CLI tools so it can read and publish workspace events.
What happens after a human mentions an agent 1 Buzz relay Authenticates the event, enforces membership, stores it, and fans it out. 2 buzz-acp Filters by author, channel, mention, and event kind, then queues accepted work. 3 ACP adapter Translates the prompt/session exchange for Codex, Claude Code, Goose, or a custom runtime. 4 Agent runtime Reasons, uses tools, and decides what response or action to take. 5 buzz-cli Publishes the signed reply or retrieves more workspace context. 6 Buzz Desktop Displays the agent as a participant with its own identity and activity trail.
Separate identities Each live agent needed its own Nostr keypair and relay membership. Sharing the owner's key would destroy accountability. Custom harness definitions J.A.R.V.I.S. pointed to a remote Hermes adapter. F.R.I.D.A.Y. pointed to a Claude/Bedrock adapter. The label in Buzz did not make either runtime real. Persistent launch services The adapters had to survive terminal closure and restart cleanly. A launch/service layer owned those live processes. Response gates J.A.R.V.I.S. could use owner-only mode. F.R.I.D.A.Y. used an allowlist so the owner and approved agent collaborators could address it. Keyless management cards The desktop UI definitions displayed and managed the agents, but the persistent services remained the only live relay identities. This avoided duplicate identities. Channel-level proof A real test meant mentioning the intended agent in Buzz, seeing the correct harness receive the event, and receiving a signed reply in the same room.
What broke — symptoms, causes, and fixes
The failures are more valuable than a clean install transcript. Buzz is new enough that several layers can look healthy independently while the end-to-end system is still wrong. This is the recovery map from the real build.
Failures observed during the deployment and follow-up recovery Tailscale setup kept circling in UI automation Stale macOS VPN/account state plus an unrelated VPN profile that had to be preserved Remove only stale Tailscale state, use UI for required approvals, then move bounded authentication and verification work to the CLI. Private WSS provisioning timed out The tailnet could not provision the private certificate path during the setup Use ws:// only inside the encrypted Tailscale TCP route and state clearly that overlay encryption is not application-layer WSS. Relay returned 404 through the loopback tunnel The relay validated the HTTP Host header against the configured community host A header-normalizing proxy was tested, but URL alignment became the cleaner solution; the proxy is not part of the proven current design. Transport connected but NIP-42 authentication failed The forwarded host or port differed from the relay URL used in the signed authentication event Align the Mac loopback port and configured relay URL exactly before debugging higher layers. First scripted owner query failed The request raced ahead of the authentication challenge and response Sequence NIP-42 authentication correctly and add bounded retry timing; always remove the temporary protected identity file. Buzz stayed on Build your profile and said relay unreachable Network transport was healthy, but onboarding state was stale or written to the wrong WebKit database Identify the database opened by the running app, correct onboarding state atomically, and relaunch through macOS LaunchServices. Launching the bundle executable did not open the desktop UI The executable can enter a CLI mode Launch with macOS open -a Buzz instead of invoking the binary directly. A screenshot appeared to show a failed relay connection The image captured an earlier attempt while the underlying socket state had changed Verify with the bundled CLI, WebSocket state, relay logs, and a harmless send/receive test. Screenshots are not connection telemetry. Built-in Fizz/agent returned needs configuration The visible template did not have a complete model/harness/runtime configuration Configure a real runtime and identity. Treat stock agents as templates, not guaranteed workers. J.A.R.V.I.S. appeared but did not respond correctly The existing remote Hermes service was not automatically an ACP runtime Add a custom remote adapter, supervise it, register its identity, and validate the complete mention-to-reply path. J.A.R.V.I.S. received the turn but initially produced no Buzz reply The first Hermes response path attempted an unnecessary internal CLI action without the bridge environment Correct the ACP response path and verify that a distinct J.A.R.V.I.S.-signed event returns through the relay. J.A.R.V.I.S. context was shallow A short persona prompt did not guarantee the existing Hermes memory and hierarchy were actually used Add durable memory and a full operating prompt, then test semantic role and reporting recall instead of accepting a proof marker alone. Old Jarvis and new J.A.R.V.I.S. identities both appeared The starter-derived identity remained after the dedicated owner-attested agent was created Archive the superseded identity with a replacement pointer, remove its new memberships, and preserve its signed historical messages. J.A.R.V.I.S. avatar upload was rejected The source screenshot carried macOS metadata the media path rejected Create a visually identical clean square image with metadata removed. Desktop-managed agents produced routing errors or duplicates A management definition and a live relay identity were being treated as the same object Keep one persistent live service per agent identity. Use keyless UI definitions to point at those harnesses instead of spawning competing identities. Agent cards disappeared after cleanup Broken live identities were removed too broadly, taking useful management definitions with them Restore the cards as keyless definitions linked to the working harnesses; do not restore the archived broken identities. F.R.I.D.A.Y. allowlist error The agent was in allowlist mode with an empty public-identity list Add the approved collaborator identity to the definition and live policy, restart, and validate the exact invariant. F.R.I.D.A.Y. was alive but not operating as a marketing director The prompt, memory, routing, and Desktop-managed lifecycle were too shallow Add the Bedrock-Claude wrapper, durable marketing memory, reporting contract, authenticated J.A.R.V.I.S. allowlist, and a persistent service. Homebrew AWS CLI crashed A local Python and XML runtime mismatch broke that CLI Test the real Claude JavaScript SDK and Bedrock path instead. The agent worked even though the unrelated AWS CLI remained broken. Marketing team references were broken Team configuration still pointed at missing agent definitions Repair the team persona references after restoring the management cards. Stale Keychain prompt remained on screen An earlier CLI/UI identity-import path left an authorization flow waiting Stop the stale process, deny obsolete prompts, and repeat through one controlled import path. Never paste a password into chat. Mobile pairing could not reach the pairing service The mobile path was not fully wired or reachable through this private deployment Label it incomplete. Do not use desktop success as evidence that mobile pairing works. Private route later stopped working The server's Tailscale node needed re-authentication Monitor overlay authentication and expiry. Re-login, revalidate the private route, then repeat end-to-end messaging. Four buzz-acp workers appeared after the clean checkpoint Buzz Desktop v0.5.4 started J.A.R.V.I.S. and F.R.I.D.A.Y. workers while the two persistent launch services were also running Choose one ownership model per identity—persistent services or Desktop-managed workers—then repeat signed semantic tests.
Security checklist for a private Buzz deployment
Pin source and images Record the commit, container image, desktop release, and checksums that passed. Avoid floating main images for a long-lived deployment. Keep the relay private by default Bind to loopback or an explicitly controlled interface. Use WSS through a reviewed TLS reverse proxy, or keep ws:// inside a private encrypted overlay; do not expose a raw WebSocket port casually. Use stable server secrets Relay identity, database, Redis, object storage, Git hook, and owner configuration must survive restarts and backups. Give every agent its own identity Separate keys make authorship and accountability meaningful. Never reuse the owner's private key for an agent. Default agent responses to owner-only Expand to an explicit allowlist only when collaboration requires it. Avoid anyone mode on a sensitive workspace. Store desktop identity in Keychain Use protected operating-system secret storage. Do not make chat, clipboard, terminal output, or screenshots part of the transfer path. Protect the screen-recording surface Collapse secret-bearing terminals, hide account details, redact private hosts and identities, and use sanitized status summaries. Back up before upgrades Database state, object storage, stable identities, and configuration form one system. Test restore, not only backup creation. Monitor dependency expiry Tailscale login, certificates, API credentials, model-provider access, and launch services can drift independently. Rotate anything disclosed If a secret appears in chat or video, assume it is compromised. Removing the message or file is not rotation.
Verified, inferred, and incomplete
What this guide can and cannot claim Verified — Aug 3 Relay stack healthy and loopback-only Service checks, listener verification, and deployment notes from the completed setup. Verified — Aug 3 Buzz Desktop installed from the official signed/notarized macOS release Release digest, Block signing identity, Gatekeeper, and notarization checks. Verified — Aug 3 Desktop authenticated and exchanged harmless messages with the private relay Socket/CLI validation and on-screen workspace evidence. Verified — Aug 3 Custom J.A.R.V.I.S. and F.R.I.D.A.Y. services were connected and configuration failures were repaired Persistent services, management definitions, allowlist repair, and message-path checkpoints. Verified — Aug 4 The Compose stack remained healthy and the relay remained private Fresh server-side status and listener checks. Incomplete — Aug 4 The private Mac-to-server route was currently healthy Tailscale on the server reported NeedsLogin, so the path required re-authentication. Incomplete — Aug 4 The current ACP runtime was free of duplicate processes Four workers were present: two persistent launch services and two Buzz Desktop-managed workers for the same agent definitions. Incomplete Mobile pairing worked The recorded attempt failed to reach pairing and was not recovered in the verified checkpoint. Inferred / recommended A current Tailscale Serve command is identical to the historical working command The historical private raw TCP/WebSocket route is proven, but the exact archived forwarding command was not recovered safely enough to publish as fact.
Can you fork and commercialize Buzz?
Buzz is licensed under Apache License 2.0. In practical terms, that is a permissive open-source license. It does not mean you cannot commercialize the project. It generally permits private use, modification, hosted services, paid support, and distribution of modified source or compiled applications.
Include the Apache 2.0 license when distributing covered work. Preserve applicable copyright, attribution, and NOTICE information. State significant modifications when distributing a changed version. Review the patent termination and contribution terms. Do not assume Block's name, Buzz name, icons, or trademarks are licensed for your commercial brand. Audit every bundled dependency because its license obligations may differ from the repository's top-level license.
Fork the code; create a new product identity If I turn this into a paid community workspace, I would use a new name, logo, domain, bundle identifiers, privacy terms, support model, and distribution pipeline. I would keep the Apache notices, document changes, audit dependencies, and get legal review before launch.
My verdict: is Buzz a Slack killer?
Buzz is not a Slack killer in the boring operational sense yet. It does not have Slack's reliability history, mobile maturity, administration, marketplace, or support. The setup still asks the operator to understand containers, private networking, cryptographic identities, agent runtimes, and service supervision.
But Buzz is more interesting than another chat clone. It gives humans and agents the same workspace substrate. The agent is not hidden behind a webhook that occasionally posts text; it can own an identity, receive scoped events, use tools, act in rooms, and leave a searchable trail beside the people supervising it.
Choose Buzz now if You are building an agent-heavy team or product, you value self-hosting and inspectable source, and you are willing to operate an early stack. Choose Slack now if Your priority is dependable company communication, mature mobile clients, existing integrations, administration, compliance tooling, and low operational burden. Run a pilot if You want one private channel, one real agent, one measurable workflow, and a controlled way to learn before migrating broader communication.
The compelling part of Buzz is not that it looks like Slack. It is that an agent can become an accountable participant in the same signed workspace as the humans directing it. Field note from this deployment
If you want the video version, I recorded the complete first-time build, including the slow parts and wrong turns. Subscribe at harshith.com/newsletter for the next practical AI build note and the final YouTube walkthrough.
Harshith Vaddiparthy works with founders, operators, and teams on practical AI products, workflows, advisory, training, and mentorship. This no-JavaScript version preserves the page's core information and navigation.