Deploy Buzz, a Nostr relay in your own Kubernetes cluster.
Buzz is a workspace where people and AI agents work in the same place. Channels, threads, direct messages, media, workflows, Git activity, and search all travel as signed Nostr events through a relay you own, so human and agent work lands in one shared community history with a tamper-evident audit trail.
Edka connects the relay to services you already run on the platform. Nothing moves to a hosted workspace; the relay and its data stay in your cluster and your object storage.
One deployment, the whole workspace
The WebSocket relay, REST API, web interface, media, and Git endpoints run as
a single deployment. Clients connect over wss:// at a
permanent hostname through an Envoy Gateway traffic class with Edka-managed
TLS. An optional second hostname exposes Buzz’s stateless device-pairing
relay.
The first install already ships locked down: closed relay membership, signed NIP-98 REST authentication, protected Blossom media reads, owner attestations, an audit log, and automatic PostgreSQL migrations. Buzz also publishes Prometheus metrics for connections, event rates, authentication failures, users, channels, storage use, and datastore health, and Edka surfaces them in the app view next to endpoints, status, and logs.
Your relay, your identity
A Buzz community is anchored to two keys and a hostname, and Edka treats all three as permanent.
The owner identity is yours. Generate it in the browser or paste an
existing npub; Edka only ever receives the public half. The private nsec
appears once, downloads as a backup, and never enters Edka. The relay
identity key signs for the relay itself. Edka generates it in your browser
during install, stores it in the cluster runtime Secret, and gates reveal
behind your organization’s
sensitive-action policy with passkey step-up when enforcement is on.
The relay hostname is part of the community identity and cannot change after installation. Pick one your clients can keep reaching.
Datastores you already manage
Buzz does not ship its own database quickstart on Edka. PostgreSQL holds the canonical event data and full-text search, Valkey handles pub/sub fan-out and presence, and a dedicated S3 or S3-compatible bucket stores media and Git objects. You select each one from the services you already operate, with the backup workflows those services already have. Edka resolves their credentials from protected secrets and builds the runtime connection settings for the relay.
Scaling with clear rules
The default single replica supports in-process huddle audio. Run more replicas or enable CPU autoscaling and Edka disables huddles so calls are not split between pods, while Valkey fans events out across replicas. A pod disruption budget and node-pool placement round out the operational controls.
Get started
You need:
- an Edka cluster with an Envoy Gateway traffic class and a stable DNS hostname for the relay;
- a managed PostgreSQL database and user, and a Valkey installation;
- a dedicated AWS S3 or S3-compatible object storage integration; and
- a place to save the owner private key, such as a password manager.
Open Apps, select Buzz, and follow the guided install. Read the Buzz setup and operations guide for identity backups, scaling rules, metrics, and troubleshooting, or the Buzz app page for an overview.
Create an Edka account to run Buzz in your own cluster.