BeeBuzz beta access is opening up

BeeBuzz has been in beta for a while. The change now is that I’m starting to open the gates: approving users for the hosted SaaS beta and making the source code public under the GNU AGPLv3.

This is a practical release, not a broad product announcement. BeeBuzz is still small, still focused, and still shaped by the same constraint that started the project: send private push notifications to your own devices without turning the system into chat, workflow automation, or another general messaging surface.

The hosted beta is available to approved users. The code is available if you want to read it, run the development stack locally, or follow how the system is built.

What you can do today

BeeBuzz currently covers the core loop:

• sign in to the hosted beta
• pair a device with Hive, the BeeBuzz PWA receiver
• create API tokens scoped to topics
• send trusted-mode notifications over HTTP
• create webhook URLs for services that can POST to HTTPS
• install the CLI and send end-to-end encrypted notifications
• run the full stack locally for development

That is close to the complete intended feature set. BeeBuzz is a small Web Push system for alerts from servers, scripts, automations, CI jobs, monitoring tools, and personal infrastructure.

The simplest test is trusted mode:

curl https://push.beebuzz.app \
  -H "Authorization: Bearer $TOKEN" \
  -F title="Hello from BeeBuzz" \
  -F body="Trusted mode test"

In trusted mode, BeeBuzz receives the notification content, validates it, and dispatches it to the devices subscribed to the selected topic. This is the fastest path for webhooks and external services.

For content that should stay opaque to the server, the CLI can send in end-to-end mode:

beebuzz send "Hello from BeeBuzz"

In that flow, the CLI encrypts locally for your paired device keys. BeeBuzz stores and routes ciphertext; Hive fetches the payload and decrypts it on the receiving device.

Hive

Hive is the receiver side of BeeBuzz. It is a PWA rather than a native app.

That choice keeps the project web-only, but it also means the browser matters. Web Push support, Service Workers, notification permissions, install behavior, and Web Crypto support all affect whether a device can be paired cleanly.

The beta flow is built around that reality:

1. open Hive on the device
2. install it when the platform requires or strongly benefits from installation
3. grant notification permission
4. enter the pairing code from the BeeBuzz dashboard

On iPhone and iPad, installation is required for Web Push. On desktop browsers, the details vary by browser. The browser support documentation is the source of truth for the current matrix.

Webhooks and integrations

Webhooks are for services that can call an HTTPS URL but do not fit direct API-token sending well.

You create a webhook in the dashboard, choose the target topics and payload mode, then use the generated URL from another system. For example, a Home Assistant automation can call a BeeBuzz webhook with a JSON body containing a title and body.

Webhooks are trusted mode. That is intentional and explicit: if a third-party service sends plaintext to BeeBuzz, BeeBuzz can read it before dispatching the notification. End-to-end mode is for senders you control, where encryption can happen before the payload reaches the server.

Open source and self-hosting

The source code is available at github.com/lucor/beebuzz, licensed under the AGPLv3.

The repository includes the Go server, SvelteKit site, Hive PWA, CLI, migrations, OpenAPI document, deployment files, and security documentation. The local development flow is documented and is currently the recommended way to run the whole stack yourself during beta.

Production self-hosting is not the main supported path yet. The code is there, and the deployment files exist, but the documentation is still intentionally focused on local development and hosted beta usage. I would rather document that path properly than imply that every operational detail is already settled.

What is intentionally not there

BeeBuzz is not a team inbox. It is not a chat app. It does not try to replace Slack, Matrix, ntfy, Pushover, or a full notification platform.

The current scope is narrower:

• machine-to-person alerts
• paired personal devices
• topics
• API tokens
• webhooks
• plain text messages, not rich text
• trusted delivery when the server is allowed to read the payload
• end-to-end delivery when the sender can encrypt locally

That narrowness is part of the design. It keeps the codebase auditable and keeps the trust model understandable.

Hosted beta status

Hosted access is free during beta. After beta, the hosted service will move to a single paid plan to keep the project sustainable. Self-hosting remains free and open source under the AGPL license.

There will be rough edges, but the beta is not about discovering a large new feature backlog. The product scope is already close to complete. What still needs real-world use is the delivery loop, device pairing, browser behavior, the CLI, the webhook model, and the operational shape of the service.

If you want to try it, start with the quickstart. If you want to inspect or run the code, the repository is on GitHub.

BeeBuzz is no longer only something I write about in devlogs. More people can now use it through the hosted beta, test it against real workflows, and read the source end to end.

If you find the project useful or want to follow its development, a star on GitHub helps.