ranuts/document: OnlyOffice and WebAssembly in a Browser Tab, With No Server
Edit DOCX/XLSX/PPTX in your browser — client-side, no server, works offline (OnlyOffice + WebAssembly)
At a glance
- What is it?
- ranuts/document runs the OnlyOffice editing engine and its WebAssembly converter entirely on the visitor's device, so DOCX, XLSX and PPTX files are never uploaded. The trade-off is AGPL-3.0 licensing and an editor bundle that only loads when someone opens a file.
- Who is it for?
- Adopt ranuts/document if you need document editing that never leaves the device, or if you are embedding an editor into a product where you already handle auth and storage. Do not adopt it if your users expect Google Docs style multi-user editing or if your organisation cannot accept AGPL-3.0 obligations; the source is under that licence, and compliance is your call to make with counsel.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: office files that must not touch a server
Most browser-based office editors are thin clients over a backend. The file goes up, the server converts and renders it, and the result comes back. That model fails in three common situations: regulated environments where document contents cannot leave the machine, offline or air-gapped settings, and embedded products where the vendor does not want to run a document conversion service at all. ranuts/document inverts the arrangement. According to the README, the OnlyOffice engine and its WASM converter run on the visitor's device, so documents are never uploaded and no account is involved. That is the whole pitch, and it is a narrow one. This is not a collaboration suite. It is a document editor that assumes the file is the user's business and nobody else's. The audience follows from that: privacy-sensitive teams, developers embedding editing into an app that already has its own storage layer, and anyone who wants a Word or Excel file openable on a laptop with no network. The homepage at edit.chaxus.com is the reference deployment, and the project also ships as a static build and a Docker image.
How the OnlyOffice WASM engine ends up in the tab
The README is explicit that the OnlyOffice engine and its WASM converter run client-side, but it does not document the internal pipeline, so treat the following as what the material supports rather than a full architecture description. What is visible is the boundary: the repository's primary language is HTML, the build produces a static directory of files servable by any web server, and the landing page at / does not load the editor bundle until a document is opened. That last detail matters. The heavy OnlyOffice and WebAssembly payload is deferred, so a visitor who only reads the landing page never pays for it. The editor lives at /editor and accepts an input document through several routes: a src or file URL parameter for remote files that permit CORS, a new=docx parameter for a blank document, or a saved=<id> parameter that reopens something this browser already holds. Conversion between formats, including export to PDF, happens in the same tab. Because the converter is WebAssembly, the browser is executing compiled code rather than posting bytes to a conversion endpoint. The practical consequence is that the first load is large and every subsequent load can be served from the PWA cache.
Autosave, IndexedDB and the seven-day deletion rule
The persistence design is the most opinionated part of the project and the part most likely to surprise users. While you edit, the editor writes the document into IndexedDB so that a refresh, a closed tab or a crash does not destroy the work. Reopening the editor offers that copy back. Two constraints come with it. First, the README states plainly that these copies are not a backup and that anything worth keeping should be exported. Second, each document is deleted automatically seven days after it was last edited or opened, whether or not the user returns. The /history route lists what the browser is holding, with a per-row delete, a delete-all, and a switch that turns autosave off entirely. On a shared machine, the README points at that page as the one to visit. There is a separate saving mechanism layered on top: where the browser allows it, saving writes back into the file the user originally picked, so the document stays in the file system rather than accumulating in a downloads folder. The README scopes that behaviour to Chromium and says that elsewhere it downloads as before. That is a real behavioural fork between browsers, and it changes how a user thinks about where their document lives.
Running it: Docker, source, and the URL parameters that matter
The fastest path to a self-hosted instance is the published image. The README gives this command: docker run -d --name document -p 8080:80 ghcr.io/ranuts/document:latest. Running from source is the usual three steps: git clone https://github.com/ranuts/document.git, then cd document, then pnpm install, then pnpm run dev. There is no database, no API key and no server-side configuration, because there is no server-side component. Configuration happens through the URL. On /editor, src=<url> opens a document from a URL that must allow CORS, file=<url> is the legacy spelling and wins if both are present, new=docx starts a blank document (docx, xlsx and pptx are the accepted values), saved=<id> reopens one of the browser's own saved documents, readonly=1 disables editing and export, embed=1 switches on embed mode, and locale=zh-CN sets the interface language. For embedding, the README shows an iframe pointed at /editor?embed=1 and a postMessage exchange: the host sends { id: '1', type: 'document:open-url', payload: { url: '...' } } and listens for document:opened and document:saved events, uploading the file when the latter arrives. The README notes that embedded editors keep no local copies, which is a sensible default for that mode.
Where this approach breaks down
The clearest limitation is stated by the project itself: embedded editors keep no local copies. That is correct for an embedding host that owns storage, but it means the crash-recovery story that applies to the standalone editor does not apply inside an iframe. If the host page fails to persist on document:saved, the work is gone. A second boundary is browser dependence. The write-back-to-the-picked-file behaviour is scoped to Chromium in the README; on other browsers the fallback is a download, which is a different product experience for the same action. Third, the first-load cost of an OnlyOffice and WebAssembly bundle is not something a static host can make disappear, only cache after the fact; the README's claim about offline use depends on the PWA having been installed and primed on a prior visit. Fourth, and most structurally, this is a single-user editor. Nothing in the material describes concurrent editing, presence, comments or any collaborative layer. If two people open the same file, they are editing two independent copies, and reconciliation is the user's problem. Anyone reaching for this as a Google Docs substitute is reaching for the wrong tool. It is also worth noting the release cadence visible in the material: v0.0.4 in May 2026, v0.0.5 in July, v0.0.6 in September. That is a young project still on zero-point version numbers.
How it differs from server-side document editors
The obvious comparison is a hosted editor such as Google Docs or Microsoft 365 in the browser, or a self-hosted suite like Collabora Online. Those systems put the document engine on a server and make the browser a rendering and input surface. The payoff is collaboration, central storage, permissions and audit, all of which require the file to live somewhere the server can reach. ranuts/document makes the opposite trade. The engine travels to the file instead of the file travelling to the engine. Nothing needs to be uploaded, so nothing needs to be trusted with the upload, and the editor works with the network off. What you give up is everything that depends on a shared server: real-time co-editing, server-side search and indexing, administrator-visible document inventories, and the ability to enforce policy on content at rest. Collabora Online, for instance, is a server product that integrates with Nextcloud and similar platforms precisely because the storage and sharing layer lives there. Choosing between the two is choosing where the document lives, and the README's answer is unambiguous: on the device, in the user's own file, with a seven-day browser copy as a safety net rather than a store.
WebMCP tools, licensing and what maintenance looks like
Two items in the README deserve separate attention. The first is agent readiness: the project exposes WebMCP tools so a browser AI agent can open, convert and read documents. That is an unusual capability for a client-side editor and it fits the architecture, since an agent running in the same browser has the same access the user does. The README does not enumerate the tool names or their schemas, so the shape of that API is something to inspect in the source before designing around it. The second is licensing. The project is AGPL-3.0. That is a strong copyleft licence with a network-use clause, and it applies to a project whose entire value proposition is that you can self-host it. If you deploy a modified version as a network service, the licence's terms are something you need to understand before you ship. This is not legal advice; talk to counsel about your specific deployment. On maintenance cost, the material supports a limited but real picture: a static build with no server means no runtime to patch, no database migrations and no scaling work. The cost sits in the frontend bundle and in tracking upstream OnlyOffice and WebAssembly changes, plus whatever it takes to keep the PWA cache coherent across releases. The presence of a CI workflow and releases across three consecutive months suggests active upkeep, but the version numbers are still in the 0.0.x range.
Editorial conclusion
Adopt ranuts/document if you need document editing that never leaves the device, or if you are embedding an editor into a product where you already handle auth and storage. Do not adopt it if your users expect Google Docs style multi-user editing or if your organisation cannot accept AGPL-3.0 obligations; the source is under that licence, and compliance is your call to make with counsel. Before committing, verify three things on your own deployment: that the OnlyOffice WASM bundle loads inside your Content Security Policy, that the postMessage origin check in your host page matches the iframe origin you actually serve, and that your target browsers support the File System Access path the README describes for saving back into a picked file. On Chromium that path writes to the original file; elsewhere the README says it downloads as before, and that difference changes the user experience more than any other line in the documentation.
Community notes