Running documents on your own servers used to mean giving up real-time collaboration, comments and version history. ShimoDocs is built the other way round: you get the collaborative editing surface first, and it happens to run inside your network boundary.
The editor, the file storage, the permissions model, the audit trail and the search index all run on servers your organisation controls. Your people still open a browser and edit the same document together; what changes is where the content lives and who can be compelled to produce it.
It is worth being precise about the distinction, because the terms get used loosely. On-premises describes whose hardware it runs on. A private cloud deployment is usually on-premises or in a dedicated tenant. Data residency is a third thing again: it answers where bytes sit, not who can read them. A hosted suite with a regional storage option is not an on-premises deployment.
A production deployment has four layers, and the middle two are where the project time goes.
Bringing your own middleware is a first-class path, not a workaround. The installer has an explicit "third-party middleware" route for each of them, and the guides cover the connection settings each one expects.
An integrated single-node environment deploys the whole stack onto one prepared machine. It is the right shape for an evaluation, a pilot, or a small team that values simplicity over redundancy, and it produces the acceptance materials a handover or an audit will ask for.
A high-availability cluster is the production shape: three or more master nodes with worker capacity, so losing a node does not take collaboration down. The recommended starting topology is three masters with additional workers added later as load grows. Both shapes install from the same package; the difference is the topology you prepare, not the software you run.
For a high-availability cluster, plan on at least three servers with 16 cores and 32 GB of memory each. The system disk needs 100 GB or more and the data disk should be separately mounted at 300 GB or more, with all nodes configured consistently. Clocks must be synchronised across nodes, and the installation node needs SSH access to the rest.
Two details catch people out. First, do not partition /root, /var or /tmp separately — the deployment expects them on the system disk. Second, nothing belongs on the system disk; document data, object storage and the database all live under the data mount. Both requirements are in the system requirements guide, and both are cheaper to honour before the hardware is provisioned than after.
It does not make the platform free of work. You take on upgrades, backup and restore testing, availability, and capacity planning. That operational burden is the real cost of running anything on-premises and the one nobody measures before committing — which is why our own guidance recommends piloting with instrumented operations time rather than scoring features.
It also does not make you compliant by itself. It gives you the control evidence that a compliance obligation requires: access logs you can produce, deletion you can demonstrate, and a retention model that matches your record-keeping policy. The control framework still has to be built on top.
This is the part on-premises deployments usually lose. A cloud suite gives you AI by sending your document context to the vendor; an on-premises deployment with no AI story gives you control and no assistance.
ShimoDocs separates the two. The AI configuration layer points at a model endpoint you choose, so inference can run inside the same boundary as the documents. Agents work inside the document with a visible identity, a live cursor and a full edit history, so a reviewer can see exactly what changed and take over at any point.
It means the document editor, the file storage, the permissions model and the audit trail all run on servers your organisation controls, rather than on a vendor service. Users still open a browser and edit together in real time; what changes is where the content and the metadata live.
Yes, if the deployment supports offline installation and does not depend on an external model endpoint. ShimoDocs ships offline image packages for isolated networks, and its AI layer can be pointed at a model running inside the same boundary.
A single-node installation on prepared infrastructure is a matter of hours. A high-availability Kubernetes deployment with external MySQL, Redis, MongoDB, Kafka and object storage is a project measured in weeks, most of which is middleware preparation rather than the suite itself.
For high availability, three or more servers with at least 16 cores and 32 GB of memory each, a separately mounted data disk of 300 GB or more, synchronised clocks, and either bundled or external middleware. The system requirements guide lists every prerequisite.
They are close but not identical. On-premises describes whose hardware it runs on; private cloud describes who can reach it. A private cloud deployment is usually on-premises or in a dedicated tenant, and the important property in both cases is that the network boundary and the keys are yours.