Embed into a web application

A user of your product has a page with a list of files. Today they click “download” and leave for someone else’s program. After these steps, they will click “edit” and stay with you: the document opens right on the page, under your name, and the file never leaves your server.

For the business, this means file permissions and versions stay in your system, and the user doesn’t switch between products. For the development team — the four steps described below.

What you need to have

Three things, and you almost certainly already have two of them.

What is needed	What it means in plain words
A page with a list of files	The one that currently has “download”. It will get an “edit” button.
A “who is signed in” address	Your server answers which user has come. That is your account area — it already exists.
A “give me file number N” address	Your server hands the document itself to whoever has the right. That is your storage — it already exists too.

The editor has no accounts of its own and never will: it asks your system who has come and trusts its answer. Passwords, roles, and permissions remain yours.

Four steps

This section is for whoever will do the wiring. If you decide rather than wire, it’s enough to know: the editor is installed on your server as one ready-made image, and one frame is added to the page.

1. Take the image. The server editor ships as a ready-made Docker image: inside are the shell, the core of the same version, and everything they need; Linux x86-64, 2 GB of memory plus about 250 MB per open document. The image is in the webhost/ folder of the release catalog — the same place as the SumDoc builds — and loads without internet access:

   docker load -i SumDoc-<version>-webhost-docker.tar.gz

2. Run it on your side. One command on your server. It starts a service that listens only on the local address — it can’t be reached from outside.

   docker run -d --name fastdoc-webhost --restart unless-stopped \
     -p 127.0.0.1:8090:8090 \
     -v /srv/fastdoc-cabins:/data/cabins \
     hissih/sumdoc-webhost \
     --base-path /fastdoc --max-cabins 12 --idle-min 20 \
     --auth-url 'https://your-host/api/me' \
     --attach-url 'https://your-host/api/files/{id}/content'

   The last two addresses are your “who is signed in” and “give me the file”. The service knows nothing else about your system. Working copies of documents live in the /data/cabins volume and survive an image update. Next to the archive in the release catalog is an installation guide, and inside the image is doctor, a check of your host against the contract.

   Without Docker, the service starts from the delivery archive with the same sandbox manager, only the path to the core and the dependency directory are set by hand — Editor in the browser.

3. Route it through your server. An ordinary nginx proxy with one mandatory condition: the WebSocket upgrade must go through. Without it the editor cannot reach the core and shows an empty space. A ready sample configuration is in the delivery.

   The editor must open over https and on the same domain as your application. Otherwise the browser will not give it your cookies, and the user will see “sign-in required” instead of the document.

4. Put the frame on the page. Four lines where the “download” link is now:

   <iframe src="/fastdoc/?doc=document-id"
           style="width:100%;height:100%;border:0"
           allow="clipboard-read; clipboard-write"></iframe>

   In place of document-id, substitute the file number from your own database — the one you already know.

What the user will see

They click “edit” and stay on your site. The editor opens with their document: the ribbon, pages, cursor, everything as in the familiar program. They edit a paragraph, click “save” — and the file returns to your storage as a new version.

You can see what this looks like right now without installing anything: the live editor example and the live spreadsheet example are working programs, not screenshots.

The same server editor is already embedded in Layers — our workspace for teams, which is also installed on your side as a Docker image. You can see it working without installing anything: sign in to the public Layers node (free), create a page, drag a .docx or .xlsx into it and open it — these are the same images described above, connected to the workspace’s own “who is signed in” and “give me the file” addresses.

The one thing everyone trips over

The saved file arrives as multipart/form-data — a single part named file. Your handler must parse the multipart body, not write it to a file as is. If you write it as is, documents will be corrupted after every save — silently, without a single error in the log.

This is not a hypothetical danger: the sample host in the delivery itself tripped over it.

The same for spreadsheets

For Excel spreadsheets, the path is the same in spirit: the screen works in the browser, your server does the calculation. For developers — the spreadsheet web host image is in the webhost/ folder of the SumSheet release catalog (SumSheet-<version>-webhost-docker.tar.gz); the launch is the same, only the image is hissih/sumsheet-webhost and the port is 8092: The processor on the server and SumSheet runtimes.

There is also a second path that documents don’t have: spreadsheets can calculate right in the browser, on the user’s device. Then your server serves only the page and the file, and there is nothing to install or update on the server. What this gives and what it costs — The core in the browser.

One caveat about the second path: workbooks that fetch data from the network themselves — from databases or over https — are not calculated in the browser. Such workbooks are calculated by your server, via the first path.

Further on, when the simple path is not enough

The first steps answer the question “how to open and save”. Then the harder tasks begin, and each has its own page.

What you want to do	Where to look
Build a document from a template: headings, tables, headers and footers, a table of contents	What SumDoc can do with a document
Merge edits from several people, accept or reject tracked changes	Working on a contract together
Send one document to a list of recipients from a CSV	Printing and publishing
Compute a workbook: formulas, pivot tables, data queries	Capability map next to Excel
Understand what happens on which click, and add your own menu	Responding to clicks
The exact names of all calls, with fields	SumDoc reference, SumSheet reference

Verify in 15 minutes

The core responds, your document is opened and saved — before any embedding.

SumDoc quick start

Understand how it works

Who owns what, where the boundaries run, and why the page has no copy of the document of its own.

The editor in the browser

Embed into a desktop applicationIf your product is a program on a computer rather than a website: an ERP, an accounting system, your own shell.