World-Office: Building a Self-Hosted, Open-Source Document Editing Suite
~6 min read
rusttypescripttauridigital-sovereigntyself-hostingopen-sourcedocument-editingwopicodeberg
Save products you love by clicking the heart icon.
We use privacy-friendly analytics (Plausible + Umami) to understand how visitors use this site. No analytics are loaded without your consent. Privacy Policy
DINUM has formally directed all French ministries to migrate from Microsoft products to open-source alternatives, building on two decades of GendBuntu experience within the Gendarmerie.
The modern enterprise runs on documents. Yet the two dominant document editing platforms — Microsoft 365 and Google Workspace — share fundamental problems:
European institutions are increasingly aware of this. Germany's public sector has been migrating toward open-source alternatives like openDesk (by Open Code & Sovereign Cloud Stack). But the ecosystem remains fragmented: there is no single, self-hostable office suite that combines modern web editing with native desktop performance, comprehensive format support, and full protocol interoperability.
That gap is what World-Office aims to fill.
World-Office is designed from the ground up as a modular, layered system. The key insight is that document editing involves three fundamentally different concerns — parsing, editing, and protocol handling — and each demands different technology choices.
┌────────────────────────────────────────────┐
│ Desktop App (Tauri) │
│ ┌──────────────────────────────────────┐ │
│ │ Web Editor (React / WYSIWYG) │ │
│ └──────────────────────────────────────┘ │
│ ┌──────────────────────────────────────┐ │
│ │ Rust Backend (Tauri Commands) │ │
│ │ - Session/file management │ │
│ │ - Plugin system │ │
│ │ - Update mechanism │ │
│ │ - Window/tray management │ │
│ └──────────────────────────────────────┘ │
└────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ Server (Rust + Tokio) │
│ ┌──────────────────────────────────────┐ │
│ │ 16 Format Crates (DOCX, ODT, XLSX, │ │
│ │ PDF, EPUB, Markdown, LaTeX, ...) │ │
│ │ Each implements FormatRoundtrip trait │ │
│ └──────────────────────────────────────┘ │
│ ┌──────────────────────────────────────┐ │
│ │ 8 Microservices (Rust) + 1 Node.js │ │
│ │ - WOPI protocol bridge │ │
│ │ - Document conversion (DocBuilder) │ │
│ │ - WebDAV sync │ │
│ └──────────────────────────────────────┘ │
│ ┌──────────────────────────────────────┐ │
│ │ Nextcloud Integration (PHP + Vue 3) │ │
│ └──────────────────────────────────────┘ │
└────────────────────────────────────────────┘
The server-side core is written entirely in Rust, organized as a workspace of 26 crates. The format layer is the crown jewel: 16 dedicated format crates, each implementing the FormatRoundtrip trait for parsing and serialization. Supported formats include:
Each format crate is independently testable and follows the same trait interface, making it straightforward to add new formats without touching existing code.
The service layer comprises 8 Rust microservices (plus one Node.js service for the DocBuilder CLI — the document conversion tool). A WOPI (Web Application Open Platform Interface) bridge enables interoperability with existing WOPI-compatible storage backends like Nextcloud, ownCloud, and Collabora.
The web editor lives in a monorepo under apps/web/, structured as a Turborepo-managed TypeScript project. It provides a vanilla JS WYSIWYG editor layer with React wrappers, designed so the editing experience can be embedded either in a browser (via the web server) or in the desktop app (via Tauri's WebView).
The build pipeline produces a static dist that the Tauri desktop shell loads as its frontend — no separate web server required for the desktop variant.
The desktop proof-of-concept wraps the web editor in a native Tauri 2 shell. It provides:
Why Tauri over Electron? The desktop app does not need Node.js runtime features — it is a pure document viewer/editor. The binary is under 20 MB compressed, memory usage is approximately half of an equivalent Electron app, and the attack surface is substantially smaller (no Node.js integration).
The most technically demanding part of World-Office is the format roundtrip system. The constraint is deceptively simple: parsing a document and re-serializing it must produce a file that opens identically in the original application.
This is far harder than it sounds. DOCX files, for example, are ZIP archives containing a complex tree of XML files, with styles, numbering definitions, font tables, footnotes, endnotes, headers, footers, and relationships all spread across separate files. A parser must preserve:
The FormatRoundtrip trait enforces this contract at compile time:
#[async_trait]
pub trait FormatRoundtrip: Send + Sync {
/// Parse raw bytes into the canonical document model
async fn parse(&self, data: &[u8]) -> Result<Box<dyn Document>>;
/// Re-serialize back to bytes
async fn serialize(&self, doc: &dyn Document) -> Result<Vec<u8>>;
/// Roundtrip: parse + serialize + byte-level comparison
async fn roundtrip(&self, data: &[u8]) -> Result<Vec<u8>> {
let doc = self.parse(data).await?;
self.serialize(&doc).await
}
}
Each format crate includes roundtrip tests that verify the parsing and serialization produce bitwise-identical output for a library of test documents.
The entire project is hosted on Codeberg — a Europe-hosted, free-software Git platform. CI is powered by Forgejo Actions, Codeberg's built-in runner infrastructure.
The CI pipeline runs on shared codeberg-medium runners (4 CPU, 8 GB RAM) and covers:
--test-threads=1 for filesystem isolation), build checks for all targetstsc type checking, pnpm build across the Turborepo monorepoRelease pipeline note: The initial release pipeline was blocked by
has_actions: False(Forgejo Actions must be explicitly enabled per repo) and workflows referencingdocker://node:20-bookwormimages (Codeberg shared runners only support their own labels). Both issues were resolved: Actions were enabled via the API, and all 7 workflow files were migrated tocodeberg-mediumrunners.
The desktop proof-of-concept has reached a functional state. Key metrics:
| Metric | Value |
|---|---|
| Rust source files | 16 modules |
| Tauri commands registered | 68 |
| Rust unit tests | 8 (all passing) |
| Vitest integration tests | 17 passing, 1 skipped |
| Binary size | ~19 MB |
| Bundle size (.deb) | 5.9 MB |
| Build targets | deb, rpm, AppImage, msi (Windows), dmg (macOS) |
| Build system | Rust nightly + pnpm + Turborepo + Tauri 2 |
All Rust modules use platform-abstraction APIs (tokio::fs, std::path::Path, dirs crate, keyring crate). The only platform-specific code is in the update installer, which dispatches to the appropriate system tool:
pkexec dpkg -i for .deb packagesmsiexec /i for .msi installershdiutil attach → bundle copy → hdiutil detach for .dmg disk imagesWorld-Office is under active development. The immediate priorities are:
graphwiz-ai/debian-repoThe most important architectural decision was the language choice. Rust gives us memory safety without garbage collection, deterministic performance for document parsing, and a compiler that catches entire categories of bugs at build time. TypeScript on the frontend gives us fast iteration on the editing experience. Tauri bridges the two with a minimal native shell.
World-Office is free software (AGPL-3.0 for the server, MIT for artwork). The source code is at codeberg.org/World-Office/server. Contributions, bug reports, and discussions are welcome.