Buzz self-hosted: o que significa rodar seu próprio relay?

Fala aí, beleza? A Block, empresa do Jack Dorsey, soltou o Buzz em 21 de julho de 2026 como projeto open source sob licença Apache 2.0, e tem uma pergunta que aparece na mesma hora que a ficha cai: quem guarda as minhas mensagens?

A resposta inteira mora em uma palavra: relay

O Buzz é construído sobre o protocolo Nostr, e o relay é o backend escrito em Rust onde cada mensagem, reação, etapa de workflow, aprovação de review e evento de git vira um evento assinado dentro de um único log auditável

Ou seja, falar de Buzz self-hosted não é falar de tema escuro nem de plugin: é decidir em qual máquina esse log vive, e quem tem a chave do armário 🙂

Por que o relay concentra a decisão sobre seus dados

Primeiro o PORQUÊ, que aqui muda tudo

Formação Recomendada

Formação Agentes de IA

Domine a criação de Agentes de IA e Venda para Empresas

• 402 aulas
• 32 projetos
• 38h 19min

Conhecer formação

No Buzz, identidade é um par de chaves criptográficas com assinaturas Schnorr, igual para humanos e para agentes

Não é uma linha na tabela de usuários de uma plataforma, é uma chave que você carrega

Se você conhece o jeito que uma chave SSH funciona, a analogia é essa: a identidade é sua e é portátil, ela não pertence ao servidor em que você entrou

Aí vem a outra metade da história

O relay é a fonte única de verdade de uma comunidade Buzz, um relay por comunidade

E isso é uma faca de dois legumes: a chave é portátil, mas a comunidade fica operacionalmente dependente daquele relay específico, porque é ali que o log de eventos existe

Tome cuidado com a leitura preguiçosa dessa frase: "é descentralizado" não significa "tanto faz onde roda"

O relay em si é um binário Rust único que serve o relay WebSocket, a API REST e a interface web no mesmo processo

Um processo, três papéis, o que é MUITO conveniente pra quem vai hospedar

Os três caminhos de uso que o README oferece

O README do repositório block/buzz apresenta três caminhos, e cada um responde a pergunta dos dados de um jeito diferente

1. Usar o serviço hospedado da Block em buzz.xyz

Esse é o caminho de quem quer só ver a coisa funcionando

O Buzz abre o Builderlab no navegador, que é o serviço que cria o relay hospedado e administra a comunidade, e o relay fica em um subdomínio do tipo suacomunidade.communities.buzz.xyz, montado com o nome que você escolher

O nome da comunidade aceita letras minúsculas, números e hífens, com limite de até 3 comunidades por conta

O serviço é gratuito e está declaradamente em estágio inicial: o próprio site convida a testar as fases iniciais junto com eles ("Come test the early stages with us")

Controle de dados aqui? Zero custódia sua: as mensagens, a mídia e os membros vivem na infraestrutura da Block

2. Baixar o app desktop empacotado das releases

Aqui é o "next, next e finish" da história

Tem build empacotado pra macOS (.dmg pra Apple Silicon e pra Intel), Linux (.AppImage e .deb) e Windows (.exe), tudo publicado nas releases do GitHub

E se liga nisso, que é o ponto que confunde muita gente: o app é só o cliente

Por padrão ele se conecta em ws://localhost:3000, e a variável BUZZ_RELAY_URL define outro relay antes de abrir o app (também dá pra trocar o relay dentro do próprio app)

Então o app desktop não decide nada sobre seus dados, ele apenas aponta pro relay que decide

3. Rodar a partir do código-fonte

Esse é o caminho de quem quer o relay na própria mão

Os pré-requisitos listados no README são Docker e Hermit, ou alternativamente Rust 1.88+, Node 24+, pnpm 10+ e just

É o caminho com mais fricção e com a única resposta que interessa pra quem pergunta sobre privacidade: os dados ficam onde você mandou eles ficarem

Hospedado, app desktop ou código-fonte: o que muda em cada escolha

Repare que o app desktop não é uma terceira opção de custódia, ele é o cliente das outras duas

O que o relay próprio exige de infraestrutura

A lista é curta e é dura

• Postgres
• Redis
• Object storage compatível com S3

É isso: três dependências de infraestrutura pra sustentar o binário do relay

O que você ganha em troca é a parte que importa pra quem levanta a mão na reunião: mensagens, mídia e membros ficam na infraestrutura que você escolheu, com os dados no seu próprio Postgres, sem depender da infraestrutura da Block

Quem já montou pipeline de IA self-hosted pra não mandar dado sensível pra fora reconhece o raciocínio na hora, é o mesmo trade-off: você assume operação pra não assumir dependência

Como o README descreve rodar a partir do código-fonte

Bora ver na prática?

1. Preparar o ambiente com just setup, que prepara Docker, migrações e dependências do desktop

just setup

O erro comum deste passo é rodar sem os pré-requisitos no lugar: o README pede Docker e Hermit, ou então Rust 1.88+, Node 24+, pnpm 10+ e just

2. Subir o relay com just relay

just relay

Lembra que o binário serve WebSocket, REST e interface web no mesmo processo? É esse processo que sobe aqui

3. Abrir o app desktop com just dev

just dev

O erro comum aqui é esperar ver a comunidade de outro relay sem apontar o cliente: o padrão é ws://localhost:3000, e pra outro endereço existe o BUZZ_RELAY_URL (ou a troca dentro do app)

4. Não levar esse caminho pra produção

Desde 1 de agosto de 2026, o README direciona deploys de produção para um bundle oficial de Docker Compose, em vez do caminho de desenvolvimento acima

Esse é o erro comum mais caro da seção inteira: subir o ambiente de dev, achar que está de pé e chamar aquilo de produção

5. Ou usar o template de um clique no Railway

A Block publicou em 2 de agosto de 2026 um template de deploy em um clique do Buzz Relay no Railway, que provisiona relay, Postgres, Redis e object storage

É o atalho pra quem quer custódia sem montar as três dependências na mão

Se o seu papo é levar isso pra nuvem com redundância, o raciocínio de n8n self-hosted com alta disponibilidade vale como referência de como se pensa banco, estado e disponibilidade antes de chamar de produção

Vale rodar o próprio relay do Buzz hoje?

Veredito honesto, sem torcida

A custódia é real, não é marketing: com o relay próprio, os dados ficam no seu Postgres e a comunidade não depende da infraestrutura da Block

Porém o onboarding do caminho self-hosted tem lacunas reconhecidas em issues abertas no repositório oficial (#2312 e #2816), incluindo o fluxo "já tenho uma comunidade", que só oferece o Builderlab e nunca pede uma URL de relay

Traduzindo: o software aceita relay próprio, mas a porta de entrada ainda empurra você pro hospedado

Então fica assim, na régua do que você quer hoje:

• Quer só experimentar e entender o modelo de eventos assinados? O hospedado gratuito resolve, com a ressalva de estágio inicial declarada pela própria Block
• Quer custódia dos dados sem montar infra na mão? O template do Railway sobe relay, Postgres, Redis e object storage de uma vez, e é o caminho mais curto pro relay ser seu
• Quer o relay próprio de ponta a ponta, na sua infra? Dá, com o bundle oficial de Docker Compose pra produção, mas você aceita a fricção de um projeto lançado semanas atrás e um onboarding com lacunas reconhecidas

Projeto novo é assim, beleza? A parte boa é que o log auditável e as chaves Schnorr são exatamente o tipo de decisão de arquitetura que não muda de opinião no mês seguinte

E pra quem gosta de olhar arquitetura antes de sair rodando coisa, este vídeo do canal mostra uma skill que faz a IA ler seu código e desenhar a arquitetura sozinha (Archify):

Conclusão

A escolha entre os três caminhos do Buzz não é técnica, é de apetite: quanto controle você quer versus quanta fricção você aceita operar

Hospedado é conveniência com os dados na casa da Block, app desktop é só o cliente apontando pra algum relay, e código-fonte é você segurando Postgres, Redis e object storage pra ficar com o log inteiro

Próximo passo concreto: abra o repositório github.com/block/buzz e leia o README atual antes de montar qualquer coisa

O projeto é recente e o caminho de produção JÁ mudou em agosto de 2026, então a documentação de hoje vale mais que qualquer tutorial de ontem 😀

até o próximo post!