Decide your data residency and hosting model
Workspace owner · Safeguard the work
Your team decides
Where your workspace's data lives is a decision your team or organization has to make and record — it carries legal weight, and no documentation can make it for you. This page gives you the established facts and the decisions to work through. Have whoever advises you on data protection review the outcome before it is applied to client work.
Why this matters
This is the decision that determines whether using Buzz for a given piece of work is defensible. Client or health-sector material cannot go to a Block-hosted relay under any responsible reading of GDPR. Getting this wrong does not cause a support ticket; it causes a breach.
What we know today
- The relay is the workspace. Everything — messages, media, canvases, the audit log — lives wherever the relay runs, readable by whoever operates it.
- A Block-hosted relay is the fastest way to start. A self-hosted relay is the only defensible option for client or health-sector material.
- Self-hosting means running the relay stack — Postgres, Redis, object storage — but this is no longer expert-only: Block documents a Docker Compose path and a Railway one-click, and a community template runs the stack privately over Tailscale. See Running your own relay. Note that the Railway route puts the data on Railway's cloud, not your hardware — it does not satisfy a residency rule by itself. A managed self-hosting product (Hivekeeper) remains roadmap.
- Workspaces drift. A channel opened for internal work acquires client material by the third week, because that is where the conversation was happening. A hosting decision made once and never revisited quietly stops being true.
How do you classify the material the workspace will hold?
Agree the categories your team uses — for example: internal only, client non-personal, client personal data, special-category/health data — and what goes in each. Decide who classifies, and at what point in a project. Without a classification, the hosting rule below has nothing to bite on.
What hosting rule follows from each classification?
Write the rule so someone can apply it without asking you. A defensible starting position: anything client or health-sector requires a self-hosted relay; hosted relays are for non-sensitive internal work only. Also decide what happens when the rule and convenience conflict — when a client wants speed and the classification says self-host.
Who stands up and runs the relay?
Decide what actually happens operationally: who runs the self-hosted stack, what it costs in time, and which of the documented deployment paths fits — compose on your own VPS or hardware for client material, the Tailscale template for practice-internal work. If nobody on the team will own the relay, the realistic options are to decline the work or restrict Buzz to internal use. Say plainly which one you are choosing.
Two obligations follow the relay operator and are worth naming here rather than discovering later. Platform safety — illegal content, network abuse, legal reporting duties — belongs to whoever runs the relay; self-hosted, escalated reports arrive at your own desk with no backstop behind you. And security patching is now more on you than it was: Block withdrew its commitment to publish a security advisory describing each vulnerability, its impact and the fix once a release ships. Reporters are still credited; the published-advisory expectation is gone, which means tracking releases and changelogs yourself is the only way to know what a version fixed.
How do you learn a security fix has shipped?
Since v0.5.15 there is no promise of a published advisory to watch. Reporting moved the other way in v0.5.19: vulnerabilities are now reported through GitHub's private vulnerability-reporting form rather than by email, public-channel reports are explicitly refused, and new dependencies wait three days before adoption. Read together, disclosure has moved onto GitHub's private advisory machinery rather than been abandoned — but the publication commitment is still absent. Decide who on your side follows the release stream, how often, and what triggers an upgrade on a self-hosted relay. For a workspace holding client material, "we update when we notice" is a position that has to be written down and defended, not one that can be assumed.
How is the decision recorded?
Agree what is documented, where, and in what form — so that in twelve months someone can reconstruct why this project's data sat where it did. Check what contractual commitments your organization already makes about data location; the decision has to satisfy them.
What triggers a re-check?
Decide the conditions for revisiting: scope expands, a new external party joins the workspace, a category of data appears that was not anticipated, or the hosting arrangement changes. Consider also whether a separate community per client is your practical isolation boundary, given that guest access is unproven — see Give an external stakeholder scoped guest access.
Last checked: Buzz v0.5.20, 2026-09-02.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026