"You can't self-host a real office suite — that's why everyone rents Google Docs." VBWD Office is a working argument against that assumption: a self-hosted, privacy-first document suite — a file vault, a rich-text editor and a spreadsheet — that runs on infrastructure you control. This is a review of how it's actually built, from the three public repositories, because the design decisions are more interesting than the feature list.

One storage spine, three products

The central idea is a refusal to build three apps. A document is a single record — an office_node — and its doc_type decides which product opens it: file is VBWD Space (the vault: folders, upload/download, append-only versions, per-user quota), text is VBWD Docs (a rich-text editor over a structured JSON model with an AI helper), and sheet is VBWD Spreadsheets.

Diagram: VBWD Office — an office_node storage spine branches into VBWD Space (file), VBWD Docs (text) and VBWD Spreadsheets (sheet); one tree, one trash, one version history, one quota and one access-control path; encrypted at rest, capability-based sharing.

Because the three share one spine, they share one tree, one trash, one version history, one quota and — the decision that pays off everywhere else — one access-control path. A Doc or a Sheet is a file in Space the moment it exists. Every "can this person touch this?" question is answered in one place instead of three subtly different ones, which is how most document apps grow their worst security bugs.

Security stated plainly — including what it is not

The repository is refreshingly honest about its threat model. Documents are encrypted at rest — a per-document data key sealed with the app secret — and every access is authorised server-side. But it is explicitly not end-to-end encrypted: the server can read contents, because the AI helper, preview and search require it. The README says so outright, noting that "anyone claiming E2EE while holding the keys would be misleading you." That candour is itself a design signal — you know exactly what you're trusting.

Sharing is modelled as a capability, not an identity. A share is a row carrying an opaque token (stored hashed), a permission (view / comment / edit), an optional password and expiry, and an allow_anonymous flag. The bearer gets exactly that permission on exactly that document — never a session — and revocation is immediate. The hard edges are thought through: an invalid, revoked or expired token returns a 404 indistinguishable from a token that never existed; a node owned by someone else returns 404, not 403, so existence itself isn't disclosed; and content outside the preview allow-list is served as an attachment with nosniff, so an uploaded .html behind a public link can never become stored XSS on the host's own origin.

The spreadsheet engine has no eval

The detail I liked most is in the formula engine. A spreadsheet is, functionally, user-supplied code running on your server — and the naive way to run it, a language eval, is remote code execution with extra steps. VBWD Office refuses that entirely: the sheet module imports nothing from the platform, Flask or the database, contains no eval, and instead lexes formulas, parses them to an AST and evaluates them in an interpreter, with a purity oracle test enforcing that boundary in CI. Errors like #DIV/0!, #REF! and #CYCLE! are treated as values in the lattice rather than exceptions, and an unrecognised imported function keeps its original text plus a #NAME? — because silently dropping a formula gives you a workbook that looks fine and is quietly wrong.

How the pieces are split

The suite ships as three coordinated plugins. The backend (vbwd-plugin-office, Python) holds the models, repositories and a deep services layer — access resolution, sharing, tokens and passwords, quotas, an edit-lease service for collaborative locking, document and sheet editors, export to DOCX/HTML/Markdown, and the AI service — behind a routes layer whose every public endpoint is declared explicitly so the platform's route-exposure oracle can hold it to an allow-list. The admin front end (vbwd-fe-admin-plugin-office, TypeScript) is a back-office view: a documents catalogue, storage stats and a share audit. The user front end (vbwd-fe-user-plugin-office) is the actual suite — a Space file manager, a Tiptap-based Docs editor with an AI sidebar, the Spreadsheets grid, and the public share page — all in one Vue package with i18n.

What the build teaches

VBWD Office is a good case study in the platform's own philosophy: pick one spine and make everything a special case of it, be honest about the security model rather than marketing it, and treat user input — a shared link, a formula — as hostile by default. Installing it is a single row in the SDK's plugin registry, and its dependencies are deliberately empty so the bundle stands alone. It won't replace a 300-person productivity org's every feature, and it doesn't pretend to. What it proves is narrower and more useful: a self-hosted, auditable office suite where your documents live inside your own perimeter is a real, buildable thing.

The three repositories are public: vbwd-plugin-office (backend), vbwd-fe-admin-plugin-office (admin) and vbwd-fe-user-plugin-office (user). Read the documentation or get in touch to run it yourself.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.