Selbstlern-Kurs

Buzz selbst hosten

Den „Human + AI Agent Workspace" von Block auf dem eigenen Server — vom leeren VPS bis zum verbundenen Team aus Mensch und KI-Agenten. Roter Faden: unser echter Deploy auf einem Hostinger-VPS unter buzz.fl-pro-consulting.de.

Worum geht's?

Buzz (buzz.xyz) ist ein Workspace, in dem Menschen und KI-Agenten (Claude Code, Codex, Goose …) in gemeinsamen Channels zusammenarbeiten — mit eigenen Identitäten und nachvollziehbarem Audit-Trail. Statt der gehosteten Cloud betreibst du hier das Buzz-Relay selbst: deine Daten, dein Server, deine Regeln.

Du lernst den kompletten Weg am echten Beispiel: Identity-Key erzeugen → Docker-Stack holen & konfigurieren → Container starten → Domain, Reverse Proxy & TLS → Mitglieder aufnehmen → KI-Agenten per ACP einladen → Backup & Betrieb. Jede Stufe endet mit einer Selbst-Checkliste.

Dieses Portal ist ein Selbstlern-Kurs zum Durchklicken. Dein Fortschritt wird lokal gespeichert.

? Für wen ist diese Schulung?

Überall, wo KI-Agenten datensouverän im eigenen Raum mitarbeiten sollen — nicht in einer fremden Cloud.

🤖
Agenten-Nutzer:innen
Du arbeitest mit Claude Code, Codex oder Goose und willst sie in einem gemeinsamen Workspace bündeln.
🛡️
Datenschutz-Bewusste
Konversationen und Dateien bleiben auf dem eigenen Server in der EU.
🐳
Docker-Absolventen
Du kannst Compose-Stacks starten — hier kommt ein echter Vier-Service-Stack dazu.
🖥️
Self-Hoster
Du hast (oder planst) einen VPS mit Reverse Proxy und willst einen weiteren Dienst dahinter hängen.
🧪
Früh-Adopter
Buzz ist Developer Preview — du willst früh verstehen, wie Human+Agent-Workspaces funktionieren.
🤝
Kleine Teams
Ein geschlossenes Relay nur für euch — Mitglieder kommen per Admin-Befehl rein, niemand sonst.

🗺️ Von null bis zum laufenden Relay — die Reise

Drei Phasen: vorbereiten, auf den Server bringen, betreiben.

Skizze
Phase 1Identity-Key erzeugen
Phase 1Stack holen & .env
Phase 2Container starten
Phase 2Domain · Proxy · TLS
Phase 3Mitglieder & Agenten
Phase 3Backup · Update · Sicherheit

Phase 1 (Stufen 1–4): verstehen, Schlüssel erzeugen, Konfiguration vorbereiten. Phase 2 (5–6): der Stack läuft und ist per HTTPS/WSS erreichbar. Phase 3 (7–9): Mensch und Agenten kommen rein — und der Dienst bleibt sauber am Laufen.

🧵 Roter Faden: unser echter Deploy

Keine Spielwiese: Jeder Schritt folgt unserer realen Einrichtung eines Buzz-Relays auf einem Hostinger-VPS (KVM 4) hinter dem bestehenden Nginx Proxy Manager — inklusive der beiden Fallen, in die wir dabei getappt sind (npub≠hex in Stufe 4, DNS vor Zertifikat in Stufe 6).

🪜 Die 9 Stufen

Voraussetzungen: ein Linux-Server (VPS) mit Docker und ein laufender Nginx Proxy Manager — beides lernst du in Self-Hosting & VPS; die Container-Grundlagen in Docker verstehen & sicher self-hosten; sicheren Zugang in SSH von Anfang an. Versionsstand: Buzz Developer Preview · Stand August 2026 (schnelllebig — Befehle gegen das Upstream-Repo prüfen).
Stufe 1

Was ist Buzz?

Ein Workspace, in dem Menschen und KI-Agenten als gleichberechtigte Mitglieder zusammenarbeiten — und was davon du selbst hostest.

1 Human + AI Agent Workspace

Buzz ist das quelloffene „Human + AI Agent Workspace"-Projekt von Block (buzz.xyz): Channels und Threads wie in Slack oder Discord — aber KI-Agenten sind eigene Mitglieder mit eigener Identität, die lesen, antworten und arbeiten können.

Damit wird aus „ich chatte mit meinem Agenten im Terminal" ein gemeinsamer Raum: Du schreibst in einen Channel, Claude Code oder Codex antwortet dort, ein zweiter Agent greift das Ergebnis auf — und alles bleibt als Verlauf nachvollziehbar.

2 Relay vs. Desktop-App — was hostest du selbst?

Buzz besteht aus zwei Hälften. Selbst hosten heißt: die Server-Hälfte (das Relay) läuft bei dir.

🖥️ Buzz-Relay (das hostest du)
  • Server-Komponente (Rust), spricht WebSocket (wss)
  • Speichert Identitäten, Channels, Nachrichten & Medien
  • Läuft als Docker-Stack auf deinem VPS (ab Stufe 2)
  • Geschlossen: nur aufgenommene Mitglieder kommen rein (Stufe 7)
💻 Buzz-Desktop-App (der Client)
  • Läuft lokal auf deinem Rechner
  • Erzeugt deinen Identity-Key (Stufe 3)
  • Verbindet sich per wss:// mit deinem Relay
  • Hier docken später die KI-Agenten an (Stufe 8)

3 Warum selbst hosten?

🛡️
Datensouveränität
Konversationen, Dateien und Agenten-Aktionen liegen auf deinem Server — nicht in einer fremden Cloud.
🚪
Geschlossener Raum
Dein Relay ist closed: Mitgliedschaft wird per Admin-Befehl vergeben, nicht per Einladungslink.
🌍
Eigene Regeln
Standort, Backups, Updates und Zugänge entscheidest du — wie bei jedem Self-Hosting-Dienst.
Einordnung: Buzz ist aktuell Developer Preview (Stand August 2026). Das heißt: Features und Befehle können sich schnell ändern, und für den Produktivbetrieb pinnst du das Image auf eine konkrete Version statt main (Stufe 4). Zum Lernen und für den eigenen Gebrauch ist der Stand genau richtig.

✓ Geschafft, wenn du …

Stufe 2

Architektur des Self-Hostings

Vier Services per Docker Compose — und warum der Stack viel genügsamer ist, als die offizielle Empfehlung vermuten lässt.

1 Die vier Services

Der Upstream-Stack (github.com/block/buzz → deploy/compose) bringt alles mit — du startest ihn komplett per docker compose up -d (Stufe 5).

📡
buzz-relay
Der Kern, in Rust geschrieben. Spricht WebSocket (wss) nach außen — intern Port 3000, dazu ein Health-Port 8080.
🐘
buzz-postgres
postgres:17-alpine — Identitäten, Channels, Nachrichten. Nur intern erreichbar.
⚡
buzz-redis
redis:7-alpine mit appendonly — Cache & Queues für den Relay.
🗄️
buzz-minio
S3-kompatibler Objektspeicher für Medien (Bucket buzz-media) — plus der One-Shot buzz-minio-init, der den Bucket anlegt.
„Exited" ist hier ok: buzz-minio-init ist ein One-Shot-Container — er legt beim ersten Start den Bucket buzz-media an und beendet sich dann. In docker compose ps zeigt er danach dauerhaft „Exited (0)". Das ist kein Fehler, sondern sein Job (Stufe 5).

2 Datenfluss: wss von außen, alles andere intern

Nach außen spricht nur der Reverse Proxy — die Services reden untereinander im internen Docker-Netz.

Skizze
Buzz-AppDesktop-Client
wss · 443 →
NPMReverse Proxy + TLS
intern →
buzz-relay:3000
buzz-relayRust-Kern → postgresDaten · redisCache/Queues · minioMedien

Die App verbindet sich per wss über den Nginx Proxy Manager mit dem Relay. Postgres, Redis und MinIO haben keinen Port nach außen — sie hängen nur im internen Compose-Netz. Persistenz liefern die Volumes buzz-postgres-data, buzz-redis-data, buzz-minio-data und buzz-git-data.

TLS ohne Caddy: Der Upstream bringt ein compose.caddy.yml für HTTPS mit. Wir nutzen stattdessen den bestehenden Nginx Proxy Manager, der auf dem Server ohnehin alle Zertifikate verwaltet — ein Dienst mehr hinter demselben Proxy (Stufe 6).

3 Was der Stack wirklich braucht

Die offizielle Empfehlung von 4 GB RAM ist sehr konservativ — gemessen auf unserem Deploy läuft der komplette Stack mit deutlich weniger.

  • Gemessener RAM (gesamt): ca. 140–400 MB — je nach Last.
  • Im Leerlauf: Relay ~9 MB, MinIO ~82 MB, Postgres ~49 MB, Redis ~3 MB.
  • Praxis: ein kleiner VPS (2 GB) trägt den Stack locker neben anderen Diensten.
Trotzdem messen statt raten: Werte gelten für unseren Deploy mit wenigen Mitgliedern. Mit vielen Agenten und Medien wächst vor allem MinIO. Kontrolle jederzeit per docker stats (Stufe 5).

✓ Geschafft, wenn du …

Stufe 3

Identity-Key erzeugen

Deine Identität bei Buzz ist ein kryptografisches Schlüsselpaar (Nostr) — erzeugt in der Desktop-App, der private Teil verlässt sie nie.

1 Schlüsselpaar statt Account

Buzz nutzt Nostr-Keys: Kein Benutzername, kein Passwort — dein Schlüsselpaar ist deine Identität. Der öffentliche Schlüssel identifiziert dich gegenüber dem Relay, der private beweist, dass du es bist.

Skizze
🔒 Privater Schlüsselbleibt in der Desktop-App — nie kopieren, nie verschicken
🔓 Öffentlicher Keykommt als npub1… aus der App — für Owner & Mitgliedschaft

Wie bei SSH (siehe SSH-Schulung): der private Teil bleibt bei dir, der öffentliche darf verteilt werden — beim Buzz-Relay an den Admin, der dich als Mitglied aufnimmt (Stufe 7).

2 Key in der Desktop-App erzeugen

Drei Klicks in der Buzz-Desktop-App — dann hast du deine öffentliche ID.

  1. Buzz-Desktop-App installieren & öffnen (Download über buzz.xyz).
  2. „Create a new identity key" wählen — die App erzeugt das Schlüsselpaar lokal.
  3. „Copy your public ID" klicken — in der Zwischenablage liegt dein öffentlicher Schlüssel im Format npub1….
Buzz Desktop-App — Onboarding
Buzz-Desktop-App, Identitätsansicht mit öffentlicher ID (npub1…, gekürzt) und Copy-Button — Platzhalter-Mockup, echte Aufnahme folgt
Identity-Key in der App erzeugen und die öffentliche ID (npub1…) kopieren.
Der private Schlüssel bleibt in der App. Wer ihn hat, ist dich — ihn gibt es nicht als „Copy"-Button, und du solltest ihn auch nicht exportieren oder weitergeben. Für Server-Konfiguration und Mitgliedschaft brauchst du ausschließlich den öffentlichen Schlüssel.

3 npub → hex umwandeln

Die App gibt den Key als npub1… (bech32-Kodierung). Das Relay erwartet an zwei Stellen die hex-Form (64 Zeichen) — umgewandelt wird per NostrTool.

  1. NostrTool öffnen (Webtool zur Schlüssel-Konvertierung).
  2. Deinen npub1…-Key einfügen.
  3. Die hex-Ausgabe (64 Kleinbuchstaben/Ziffern) notieren — die brauchst du in Stufe 4 für RELAY_OWNER_PUBKEY.
NostrTool — npub → hex
NostrTool im Browser: npub1…-Eingabe oben, 64-stellige hex-Ausgabe darunter (Schlüssel im Bild gekürzt/unkenntlich)
Derselbe öffentliche Schlüssel in zwei Schreibweisen: npub1… (App) ↔ 64-stelliger hex (Relay-Konfiguration).
Merksatz für Stufe 4: npub1… ist für Menschen, hex ist für die Config. Wer das npub in die .env schreibt, bekommt die erste Falle unseres echten Deploys ab (dort erklärt).

✓ Geschafft, wenn du …

Stufe 4

Stack holen & .env konfigurieren

Der fertige Compose-Stack kommt vom Upstream-Repo — deine Arbeit steckt in einer sauberen .env. Inklusive der beiden Fallen aus unserem echten Deploy.

1 Stack vom Upstream holen

Der Compose-Stack liegt im Repo github.com/block/buzz unter deploy/compose — mit compose.yml und .env.example. Du brauchst nur dieses Verzeichnis auf dem Server.

Variante A: direkt auf dem Server (per SSH)
› git clone --depth 1 https://github.com/block/buzz.git › mkdir -p ~/buzz-relay && cp -r buzz/deploy/compose/. ~/buzz-relay/ › cd ~/buzz-relay && cp .env.example .env
Variante B: lokal vorbereiten & hochladen
› scp -r deploy/compose user@<KV4-IP>:~/buzz-relay/ # scp siehe SSH-Schulung
Image pinnen für den Ernstfall: Das Compose-File zieht ghcr.io/block/buzz:main — also die laufende Entwicklungsversion. Für die Developer Preview ok; für Produktion auf einen konkreten Stand pinnen (ghcr.io/block/buzz:<sha> oder Semver-Tag), damit ein pull nicht überraschend eine neue Version einspielt (Stufe 9).

2 Domain- & Sicherheits-Werte setzen

Die Domain-Werte zeigen auf deine Subdomain — RELAY_URL mit wss://, die Media-URL mit https://…/media.

📄.env (Auszug — Domain & Sicherheit)
# Domain & URLs
BUZZ_DOMAIN=buzz.fl-pro-consulting.de
RELAY_URL=wss://buzz.fl-pro-consulting.de
BUZZ_MEDIA_BASE_URL=https://buzz.fl-pro-consulting.de/media
BUZZ_MEDIA_SERVER_DOMAIN=buzz.fl-pro-consulting.de
BUZZ_CORS_ORIGINS=https://buzz.fl-pro-consulting.de

# Geschlossenes Relay + Migrationen beim Start
BUZZ_REQUIRE_AUTH_TOKEN=true
BUZZ_REQUIRE_RELAY_MEMBERSHIP=true
BUZZ_AUTO_MIGRATE=true

# Owner = dein öffentlicher Key aus Stufe 3 — als hex, NICHT als npub1…
RELAY_OWNER_PUBKEY=<64-stelliger-hex-key>
BUZZ_REQUIRE_RELAY_MEMBERSHIP=true macht das Relay closed: Ohne Aufnahme per Admin-Befehl (Stufe 7) kann sich keine App verbinden. BUZZ_AUTO_MIGRATE=true führt Datenbank-Migrationen beim Start automatisch aus — bei einer Developer Preview willst du das.

3 Secrets erzeugen

Sechs Werte in der .env sind Geheimnisse — jedes wird einzeln per openssl als 64-stelliger Zufalls-Hex erzeugt.

Secrets generieren (6×)
› openssl rand -hex 32 # → BUZZ_RELAY_PRIVATE_KEY › openssl rand -hex 32 # → BUZZ_GIT_HOOK_HMAC_SECRET › openssl rand -hex 32 # → POSTGRES_PASSWORD › openssl rand -hex 32 # → REDIS_PASSWORD › openssl rand -hex 32 # → BUZZ_S3_ACCESS_KEY › openssl rand -hex 32 # → BUZZ_S3_SECRET_KEY
Die .env ist ein Geheimnis: nicht committen, nicht verschicken, in Backups mitdenken (Stufe 9) — ohne sie ist der Stack nach einem Restore nicht mehr derselbe.

4 Die beiden Fallen aus unserem Deploy

Beide haben uns beim echten Aufsetzen Zeit gekostet — du überspringst sie.

✗ Falle 1: npub in die Config
  • RELAY_OWNER_PUBKEY=npub1… wird abgelehnt
  • Die App liefert npub, das Relay will 64 Zeichen hex
✓ So geht's
  • npub1… per NostrTool in hex umwandeln (Stufe 3)
  • Den hex-Key in die .env — fertig
✗ Falle 2: CHANGE_ME übersehen
  • Übrig gebliebene Platzhalter in der .env
  • Relay restartet in Schleife: …must be at least 32 characters
✓ So geht's
  • Vor dem Start prüfen: grep CHANGE_ME .env
  • Keine Ausgabe = alle Platzhalter ersetzt
Der 2-Sekunden-Check vor dem Start
› grep CHANGE_ME .env # keine Ausgabe → sauber ✓

✓ Geschafft, wenn du …

Stufe 5

Container starten & prüfen

Ein Befehl startet alle vier Services — danach liest du an ps, logs und stats ab, ob der Stack gesund ist.

1 Hochfahren

Im Stack-Verzeichnis (wo compose.yml und .env liegen):

auf dem Server, in ~/buzz-relay
› docker compose up -d # Images ziehen, alle Services starten › docker compose ps -a # Wer läuft? Wer ist „Exited"? (ohne -a bleibt der Init-One-Shot unsichtbar)

Beim ersten Start zieht Docker die Images (ghcr.io/block/buzz:main, postgres, redis, minio) — das dauert einen Moment. Danach laufen relay, postgres, redis und minio; buzz-minio-init hat seinen Bucket angelegt und sich beendet.

docker compose ps
Terminal: docker compose ps -a — relay, postgres, redis und minio Up (healthy), buzz-minio-init Exited (0)
Vier Services „Up", der Init-One-Shot „Exited (0)" — genau so soll es aussehen.
„Exited" ≠ kaputt: Nur buzz-minio-init darf beendet sein (Exit-Code 0). Steht einer der vier Kern-Services auf „Exited" oder „Restarting", stimmt etwas nicht — meist die .env (Falle 2 aus Stufe 4).

2 Logs lesen & Health prüfen

Der Relay loggt Start, Migrationen und Fehler. Neben Port 3000 (wss) lauscht er intern auf einem Health-Port 8080.

Logs & Health
› docker compose logs -f relay # Start & Migrationen live verfolgen (Strg+C zum Rausgehen) › docker compose exec relay curl -s localhost:8080/health # Health-Check von innen
Restart-Schleife mit …must be at least 32 characters? Das ist Falle 2 aus Stufe 4: Ein CHANGE_ME-Platzhalter (oder zu kurzer Wert) ist in der .env übrig. Korrigieren, dann docker compose up -d erneut.

3 Ressourcen messen

Ein Blick auf docker stats zeigt, wie genügsam der Stack ist — unsere Messung: ~140–400 MB gesamt.

docker stats (Beispielwerte unseres Deploys, Leerlauf)
NAME MEM USAGE buzz-relay ~9 MiB buzz-minio ~82 MiB buzz-postgres ~49 MiB buzz-redis ~3 MiB
docker stats — Buzz-Stack
Terminal: docker stats der vier Buzz-Container mit Leerlauf-CPU- und RAM-Werten im zweistelligen MB-Bereich
Der ganze Stack im Leerlauf: zweistellige MB-Werte statt der offiziell empfohlenen 4 GB.

✓ Geschafft, wenn du …

Stufe 6

Domain, Reverse-Proxy & TLS

Der Relay läuft intern — jetzt bekommt er eine Adresse: A-Record, Nginx-Proxy-Manager-Host mit Websockets-Schalter, Let's-Encrypt-Zertifikat. In genau dieser Reihenfolge.

1 Zuerst DNS: der A-Record

Lege in der Domain-Zone einen A-Record an, der deine Buzz-Subdomain auf die Server-IP zeigt — bevor du irgendetwas mit Zertifikaten machst.

Skizze
buzz.fl-pro-consulting.deSubdomain
A-Recordin der Domain-Zone
<KV4-IP>dein Server

DNS-Grundlagen vertieft die Schulung Self-Hosting & VPS (Stufe „Domain"). Kurz: Der A-Record verknüpft Namen und IP — und Let's Encrypt prüft genau das.

Echte Falle aus unserem Deploy — DNS vor Zertifikat: Wir hatten den Proxy-Host angelegt und sofort ein Zertifikat angefordert, bevor der A-Record gegriffen hatte. Ergebnis: NPM lieferte einen 500er — „Some challenges have failed". Let's Encrypt ruft die Domain über HTTP ab; zeigt sie (noch) nicht auf deinen Server, schlägt die Challenge fehl. Also: A-Record setzen, kurz warten, dann das Zertifikat.

2 Proxy-Host im Nginx Proxy Manager

Der Upstream bringt ein compose.caddy.yml für TLS mit — wir nutzen stattdessen den bestehenden Nginx Proxy Manager (NPM), der auf dem Server ohnehin alle Hosts und Zertifikate verwaltet.

  1. NPM öffnen. Die Admin-Oberfläche ist nicht öffentlich — sie läuft nur per SSH-Tunnel: ssh -L 8181:localhost:8181 user@<KV4-IP>, dann im Browser http://localhost:8181 (Tunnel bauen: SSH-Schulung).
  2. Proxy-Host anlegen: Domain buzz.fl-pro-consulting.de, Forward an buzz-relay Port 3000.
  3. „Websockets Support" aktivieren — der entscheidende Schalter, siehe unten.
  4. SSL-Tab: Let's-Encrypt-Zertifikat anfordern, dazu Force SSL, HTTP/2 und HSTS einschalten.
NPM — Proxy-Host „Details"
NPM-Proxy-Host-Maske: Domain buzz.fl-pro-consulting.de, Forward buzz-relay Port 3000, Websockets-Support-Schalter aktiviert und rot markiert
Der Proxy-Host: Forward auf den internen Relay-Port 3000 — und der Websockets-Schalter an.
Websockets Support muss an: Die Buzz-App spricht wss:// — ohne den Schalter leitet NPM die Upgrade-Header nicht weiter, und der wss-Handshake schlägt fehl. Die App hängt dann beim Verbinden, obwohl HTTPS im Browser tadellos aussieht. Der häufigste Fehler bei diesem Setup.
NPM — SSL-Tab
NPM-SSL-Tab: Let's-Encrypt-Zertifikat für buzz.fl-pro-consulting.de ausgewählt, Force SSL, HTTP/2 und HSTS aktiviert
Let's Encrypt holt das Zertifikat automatisch — vorausgesetzt, der A-Record aus Schritt 1 greift bereits.

3 End-to-End prüfen

Zwei schnelle Tests, bevor du weiterziehst:

  • HTTPS: https://buzz.fl-pro-consulting.de im Browser öffnen — Schloss da, kein Zertifikatsfehler.
  • Media-Pfad: https://buzz.fl-pro-consulting.de/media antwortet (dieser Pfad gehört laut BUZZ_MEDIA_BASE_URL aus Stufe 4 dazu).

Der eigentliche wss-Test kommt in Stufe 7: die Desktop-App, die sich wirklich verbindet.

✓ Geschafft, wenn du …

Stufe 7

Owner & Mitglieder

Dein Relay ist geschlossen — niemand kommt per Link rein. Mitglied wird, wer per Admin-Befehl aufgenommen wird.

1 Geschlossenes Relay verstehen

Mit BUZZ_REQUIRE_RELAY_MEMBERSHIP=true (Stufe 4) ist dein Relay closed: Eine App kann sich zwar per wss verbinden — aber ohne aufgenommene Mitgliedschaft lehnt der Relay sie ab. Das ist gewollt: Dein Workspace gehört nur denen, die du explizit reinholst.

Dich selbst kennt der Relay schon: Dein hex-Key steht als RELAY_OWNER_PUBKEY in der .env. Für alle anderen — zweite Personen, deine KI-Agenten (Stufe 8) — braucht es buzz-admin.

2 Mitglieder verwalten per buzz-admin

Die Admin-Befehle laufen im laufenden Relay-Container — auf dem Server, im Stack-Verzeichnis.

Mitgliederverwaltung (auf dem Server, in ~/buzz-relay)
› docker compose exec relay buzz-admin add-member --pubkey npub1… # aufnehmen › docker compose exec relay buzz-admin list-members # wer ist drin? › docker compose exec relay buzz-admin remove-member --pubkey npub1… # wieder rausnehmen
Hier ist npub richtig: Anders als RELAY_OWNER_PUBKEY in der .env (hex, Falle 1) nimmt add-member den Key im npub1…-Format — also genau das, was die App per „Copy your public ID" liefert. Die Person, die rein soll, schickt dir ihren npub; du führst den Befehl aus.

3 Desktop-App verbinden

Jetzt der End-to-End-Moment: Die App verbindet sich mit deinem Relay statt mit der gehosteten Cloud.

  1. In der App als Relay-Adresse wss://buzz.fl-pro-consulting.de eintragen.
  2. Verbinden — die App authentifiziert sich mit deinem Identity-Key aus Stufe 3.
  3. Der Workspace öffnet sich: Channels, Verlauf, Medien — alles von deinem Server.
Buzz — Workspace nach Verbindung
Buzz-Workspace nach Verbindung: Channel-Liste, Willkommens-Channel und Relay-URL wss://buzz.fl-pro-consulting.de — Platzhalter-Mockup, echte Aufnahme folgt
Verbunden: Der Workspace läuft komplett über dein Relay — kein Buzz-Cloud-Server dazwischen.
Hängt die App beim Verbinden? Fast immer Stufe 6: „Websockets Support" im NPM-Proxy-Host ist aus, oder die Mitgliedschaft fehlt (list-members prüfen). Der Relay-Log (docker compose logs -f relay) sagt dir, welcher von beiden es ist.

✓ Geschafft, wenn du …

Stufe 8

KI-Agenten einladen

Der eigentliche Zweck von Buzz: Claude Code, Codex & Goose kommen als eigene Mitglieder in den Workspace — per ACP, mit eigenem Key und eigenem Audit-Trail.

1 Agenten sind Mitglieder, keine Bots

Ein KI-Agent bekommt bei Buzz eine eigene Identität — genau wie du. Er liest Channels, antwortet, arbeitet Aufgaben ab. Angeschlossen wird er über ACP (das Agent-Client-Protokoll, das Coding-Agenten wie Claude Code, Codex oder Goose mit Werkzeugen und Oberflächen verbindet) — Buzz bringt dafür einen ACP-Harness mit.

Ein Key pro Agent: Jeder Agent bekommt seinen eigenen Identity-Key — nicht deinen. So bleibt der Audit-Trail pro Agent sauber: Im Verlauf steht eindeutig, welcher Agent was geschrieben oder geändert hat. Unverzichtbar, sobald mehrere Agenten im selben Workspace arbeiten.

2 Einen Agenten aufnehmen — der Ablauf in der App

  1. In der Desktop-App unter „Agents" einen neuen Agenten anlegen — Name vergeben (z. B. „Kimi"), Harness/Command wählen (Kimi Code CLI, Claude Code, Codex). Du musst keinen Key selbst erzeugen: Die App generiert den Identity-Key des Agenten automatisch.
  2. Agent aktivieren — die App registriert ihn dabei selbst am Relay: Profil (kind:0), Channel-Beitritt und NIP-42-Auth laufen ohne Server-Zugriff. Ein manuelles buzz-admin add-member ist nicht nötig.
  3. Per @Mention anstupsen — bei der ersten Erwähnung in einem Channel startet der ACP-Harness auf deinem Rechner, der Agent antwortet als eigenes Mitglied („managed by you").
Manueller Weg (Sonderfall): Nur wenn ein Agent nicht über die App läuft — etwa ein eigener Dienst auf dem Server — erzeugst du den Key selbst (wie in Stufe 3) und nimmst ihn per docker compose exec relay buzz-admin add-member --pubkey npub1… auf.
Buzz — Agent im Channel
Buzz-Workspace: Flolu erwähnt @Kimi im Channel, der Kimi-Agent antwortet im Thread als eigenes Mitglied („managed by you
Mensch und Agent in einem Channel — der Agent antwortet mit eigener Identität, alles im Audit-Trail.

3 Mehrere Agenten sauber betreiben

  • Benennung: Identitäten sprechend halten (z. B. ein Key „claude-code", einer „codex") — der Verlauf wird sonst unlesbar.
  • Austritt genauso wie Eintritt: Einen Agenten entfernst du mit remove-member — sein Key ist damit sofort raus, ohne dass du den Server anfassen musst.
  • Vertrauensgrenze: Agenten können im Workspace handeln. Halte sie in den Channels, in denen sie arbeiten sollen — und lies den Audit-Trail regelmäßig mit.

✓ Geschafft, wenn du …

Stufe 9

Betrieb: Backup, Update, Sicherheit

Ein Dienst, den niemand sichert und aktualisiert, ist ein geliehener. Drei kleine Routinen machen dein Relay alltagstauglich.

1 Backup: Datenbank, Volumes, .env

Drei Dinge gehören ins Backup: die Postgres-Datenbank (Identitäten, Channels, Nachrichten), die Volumes (MinIO-Medien, Git-Daten) — und die .env (ohne Secrets kein Restore).

buzz-backup.sh (täglich per Cron)
#!/usr/bin/env bash cd ~/buzz-relay docker compose exec -T postgres pg_dump -U buzz buzz | gzip > ~/backups/buzz/db-$(date +%F).sql.gz tar czf ~/backups/buzz/volumes-$(date +%F).tar.gz buzz-minio-data buzz-git-data .env find ~/backups/buzz -mtime +14 -delete # Rotation: 14 Tage
Cron einrichten
› crontab -e 17 3 * * * /home/user/buzz-backup.sh # täglich 03:17 Uhr
Restore einmal testen: Ein Backup, das du nie zurückgespielt hast, ist eine Hoffnung, keine Sicherung. Einmal auf einer Testmaschine einspielen — danach schläft es sich besser. Offsite-Kopie nicht vergessen (3-2-1, siehe Self-Hosting-Schulung, Stufe „Updates & Backups").

2 Updates einspielen

Buzz ist Developer Preview — Updates kommen oft. Der Update-Weg ist kurz:

Update-Routine
› docker compose pull # neue Images holen › docker compose up -d # Container mit neuen Images neu erstellen › docker compose logs -f relay # Migrationen (BUZZ_AUTO_MIGRATE) beobachten
Backup vor dem Update: Gerade bei einer Preview kann ein Update brechen. Erst das Backup (Schritt 1), dann pull — und für Produktion das Image auf einen getesteten Stand pinnen statt main (Stufe 4).

3 Sicherheit & Monitoring im Alltag

  • Membership-Enforcement an lassen: BUZZ_REQUIRE_AUTH_TOKEN=true + BUZZ_REQUIRE_RELAY_MEMBERSHIP=true sind die Tür — nie „temporär" abschalten.
  • Mitglieder auditieren: regelmäßig buzz-admin list-members — jeder Eintrag muss dir bekannt vorkommen.
  • Ressourcen im Blick: docker stats (unsere Basislinie: ~140–400 MB gesamt) und der Health-Port 8080 des Relays — wachsen RAM oder Platte (MinIO!), früh reagieren.
  • Keine Ports nach außen: Der Relay ist nur über NPM erreichbar; Postgres, Redis und MinIO bleiben intern — wie in der Docker-Schulung: Container-Ports nie per -p ins Netz.

✓ Geschafft, wenn du …

Lernkontrolle

Quiz

7 Fragen quer durch die Stufen. Ab 6 richtigen Antworten schaltest du dein Zertifikat frei.

Frage 1 von 7
…
Abschluss

Dein Zertifikat

Glückwunsch! Trage deinen Namen ein und drucke das Zertifikat (oder speichere als PDF).

FL
Florian Ludwig
AI Consultant · Kutzschbach INNOVATIONS
Zertifikat
Buzz · Self-Hosting
Hiermit wird bestätigt, dass
Dein Name hier
den Kurs „Buzz selbst hosten — Human + AI Agent Workspace auf dem eigenen Server" erfolgreich abgeschlossen hat.
—Datum
★GEPRÜFT
Florian LudwigAI Consultant · Kutzschbach INNOVATIONS