Buzz Setup, Integration & Managed Hosting
A Buzz workspace where your team and approved AI agents can work in the same rooms, on a relay with clear ownership and operating boundaries.
Buzz is an Apache 2.0, self-hostable team workspace built by Block. It uses a Nostr relay as the source of truth so messages, reactions, workflow activity, and Git events share signed identities and an auditable event model. The implementation work is broader than installing a desktop app: the relay needs durable storage, TLS, stable keys, membership rules, backups, tested clients, and carefully scoped agent runtimes. I can deliver that system on infrastructure you own or operate an isolated relay and server for you under a defined managed-hosting agreement. OrchestriAI is an independent service provider and is not affiliated with, endorsed by, or an official partner of Block, Inc.
What a client-owned Buzz deployment can include
The implementation is scoped around one real workspace and its approved people, agents, data, and operating requirements.
The client owns and pays for its infrastructure, model providers, software accounts, domains, and other third-party services. Ongoing operations are separate unless explicitly included.
Optional OrchestriAI-managed Buzz hosting
For teams that do not want to operate the relay, OrchestriAI can run an isolated Buzz server and community under a recurring agreement with a defined operational and data boundary.
Managed server pricing
Quoted monthly
Third-party hosting, storage, model, messaging, domain, and software costs are separate unless the quote says otherwise. Monitoring, support hours, response times, uptime commitments, backup retention, recovery objectives, and deletion timing apply only as stated in the signed agreement. Managed hosting does not by itself make a deployment compliant with HIPAA, SOC 2, GDPR, or another framework.
Best for teams building alongside AI agents
Buzz is a strong fit for engineering and product teams that want humans and agents to share channels, threads, search, workflow events, Git context, and review history instead of scattering that record across unrelated tools. It is especially relevant when each person and agent should have a distinct signed identity and channel membership. Buzz is a workspace and relay, not an AI model or a replacement for the agent runtime itself; the useful deployment combines Buzz with the ACP-compatible tools and provider accounts the team has deliberately approved.
Client-owned deployment or isolated managed hosting
For a client-owned deployment, I install the production Compose stack or another supported architecture in your environment, configure the relay and desktop clients, verify it, and hand over the operating runbook. If you prefer not to run the server, I can operate an isolated Buzz relay and its supporting services in an OrchestriAI-managed environment under a recurring agreement. Managed scope, support hours, recovery objectives, data location, access, and offboarding are written down before launch; hosting does not create an implied SLA or compliance certification.
Agents are connected through ACP, not a hidden model bundle
Buzz documents an ACP harness for Goose, Codex, Claude Code, and other agents that implement ACP over standard input and output. Each agent receives its own Nostr keypair and channel membership, while its model and provider credentials belong to the selected runtime. Codex and Claude Code integrations, for example, use their respective OpenAI and Anthropic credentials rather than a model account supplied by Buzz. I configure only the agreed runtimes, models, author gates, channel scope, concurrency, tools, and optional MCP server, then test the exact combination instead of presenting every preset as production-ready by default.
Security follows the relay, identity, and channel model
Buzz authenticates relay connections with signed Nostr challenges and uses channel membership as its access-control gate. Production deployments also need TLS at the relay or reverse proxy because the relay does not enforce transport encryption itself. Desktop private keys use the operating-system keyring where available; headless agents commonly receive keys through protected environment or secret-management boundaries. I document who controls every relay, human, and agent key, restrict server access, review private-channel membership, and keep credentials out of repositories and handoff documents. Buzz's hash-chained audit log is tamper-evident, not tamper-resistant against an attacker who can rewrite the database, so it is not presented as a compliance guarantee.
Your data boundary includes the whole working stack
A production Buzz relay persists events and search data in Postgres, uses Redis for live coordination, stores media and content-addressed objects in S3-compatible storage such as MinIO, and can maintain Git data on a persistent volume. Backups, logs, exported data, desktop keys, agent keys, and provider prompts all belong in the boundary review. When an external agent or model provider is connected, relevant messages and tool context may leave the Buzz server under that provider's terms. Client-owned deployments keep the infrastructure and accounts under the client's control. Managed hosting places relay operations with OrchestriAI, while business accounts and model-provider credentials remain client-owned wherever the integration permits.
Testing, updates, and an honest maturity boundary
Before handoff or launch, I test relay liveness, authentication, channel visibility, desktop connectivity, the promised agent paths, workflow triggers, restart behavior, backups, and recovery steps in scope. Buzz is pre-1.0, its security policy supports the latest main branch actively, and previous releases are best-effort rather than long-term-support branches. That makes controlled version selection and regression testing important. A one-time setup does not include continuous monitoring or upgrades; managed maintenance covers only the checks, update cadence, support window, and incident response written into the agreement.
When Buzz is not the right fit
Buzz is not the best choice when you need a mature vendor SaaS with built-in contractual uptime, a turnkey compliance certification, or one shared workspace for parties that should not rely on channel membership as the authorization boundary. It is also more infrastructure than a team needs when the real requirement is one private assistant or a small deterministic automation. In those cases I will recommend a narrower agent deployment, conventional collaboration software, or a purpose-built workflow rather than forcing Buzz into the scope.
Illustrative setup: a private product-engineering workspace
Map the team, approved agents, channels, repositories, workflows, retention needs, and external model or tool providers before choosing the deployment boundary.
Deploy one Buzz community with pinned application versions, Postgres, Redis, S3-compatible object storage, persistent Git data, stable secrets, TLS, and restricted administrative access.
Configure the supported desktop clients, create separate human and agent identities, and verify public and private channel membership with authorized and unauthorized accounts.
Connect one approved ACP agent using its own keypair, author gate, client-owned model credentials, limited channel scope, and only the tools needed for the first workflow.
Implement a small source-backed workflow, such as posting repository or release activity for human review, without treating still-in-progress Buzz features as delivered capabilities.
Test liveness, message and search behavior, agent responses, failure paths, restart behavior, backup creation, and a representative restore or export procedure.
Hand over the architecture, ownership map, version and update policy, backup and recovery runbook, credential-rotation steps, and documented support boundary.
Integrations
Explore related work
See where this service fits, how it has been applied, and the technical work behind it.
FAQ
Planning a human-and-agent workspace?
Share the team, agents, repositories, workflows, and hosting preference. I will map the deployment, data boundary, ownership, and operating scope before anything is installed.