ONLYOFFICE vs CryptPad: when a server that cannot read documents is the right trade
If you are choosing a self-hosted office editor for a regulated team, the first question is whether your administrators should be able to read document content at all. ONLYOFFICE and CryptPad both give users a browser-based editor for Word-style documents and spreadsheets, but they answer that question differently. ONLYOFFICE Docs is a server-side editor: the document server processes files so that it can render, convert and co-edit them, and it is designed to sit behind an existing file platform such as Nextcloud, ownCloud, Seafile or a WOPI-compatible host. CryptPad encrypts each document in the browser before it reaches the server, so an administrator running unmodified code cannot open users' content. ONLYOFFICE is the better choice when your files must stay in a central store that administrators, search, backup and compliance tooling can read, and when you need the platform integrations and admin controls that come with it.
CryptPad is the better choice when the requirement is that the operator cannot read content, for example for a legal, research or board-level group whose documents must stay opaque to the people running the server. That protection has a cost. CryptPad's architecture document describes symmetric encryption with a single pre-shared key known to all participants of a document, so access control and sharing are handled inside the document model, not by a directory your identity team manages. Confirm with CryptPad how that key model matches your offboarding and access review rules before you commit. The trade-off is therefore not editor quality alone but who holds the keys and who can revoke access.
Which platform fits which team scenario
This table maps common team situations to the platform that fits better and the condition that would reverse the answer. Read each row as a decision: the first column names the scenario, and the other cells explain the reasoning and what would change it.
| Scenario | Better fit | Reason and condition that would change the answer |
|---|---|---|
| Server-side admin controls and integrations with Nextcloud or ownCloud | ONLYOFFICE | ONLYOFFICE Docs integrates with Nextcloud, ownCloud and Seafile and runs on the server, so administrators control it. Admin panel and white labeling are Enterprise features, so confirm whether the Community Edition is enough for your controls. |
| Administrators must not be able to read document content | CryptPad | CryptPad encrypts in the browser before data reaches the server, so unmodified server code cannot read content. Choose ONLYOFFICE only if your policy accepts server-side access to documents for admin and integration needs. |
| Public-facing space for external groups with no accounts | CryptPad | Its end-to-end design suits sharing with people outside your directory. Confirm how key sharing and account recovery work for your external users, since the architecture document describes a single pre-shared key per document. |
| Team must embed editors inside its own customer-facing service | ONLYOFFICE | ONLYOFFICE sells a Developer Edition under a commercial license for software vendors that embed the editors. Confirm the license terms with ONLYOFFICE before shipping, since CryptPad is not built as an embeddable service product. |
| Teams that need admin reporting, scaling tiers and vendor support contracts | ONLYOFFICE | Enterprise adds scaling for thousands of users and Basic, Plus or Premium support. If your team can run CryptPad with internal support, the gap narrows, so compare what each requires in writing. |
| Mixed teams needing both confidential and collaborative editing | Run both, scoped by data class | Route highly sensitive projects to CryptPad and routine documents to an ONLYOFFICE-backed file platform. The split only works if users understand which space holds which data. |
How each platform is built and what that means for operations
ONLYOFFICE and CryptPad solve the same editing problem from opposite ends of the trust model. One runs the document engine on your server, the other runs it in the user's browser, and that choice shapes how you install, upgrade, monitor and staff each one.
Server-side editing with ONLYOFFICE Docs
ONLYOFFICE Docs is a server-side editor. Your file platform, such as Nextcloud, ownCloud, Seafile or any WOPI-compatible host, sends documents to the document server, which renders and co-edits them and returns the result. Docker is the recommended installation method, so the team that runs it should be comfortable operating containers. Check how the editor is reached from your file platform, which services must be routable between them, and how TLS is terminated before you plan the rollout.
Single process after version 9.4
Version 9.4 consolidated the Community Edition into a single process without RabbitMQ or database dependencies. Fewer moving parts means fewer services to monitor, back up and patch, and a smaller set of failure points during an upgrade. Teams that already built monitoring around a queue broker or a separate database should confirm which of those checks still apply on 9.4 and later, and which can be retired.
Browser-side encryption in CryptPad
CryptPad encrypts data in the browser before it reaches the server, so an administrator running unmodified code cannot read document content, and account keys derive from a username and password the server never sees. Operationally this means the server stores ciphertext, so server-side search, content inspection and content-based data loss prevention are not available. Check whether your compliance or eDiscovery process depends on any of those before you commit.
Official container images and the admin guide
CryptPad publishes official AMD64 and ARM64 Docker images and directs production self-hosting to its admin installation guide. Your team should plan for the guide's configuration steps, the mapping of storage and data directories to persistent volumes, and any hardware architecture choices. Confirm with CryptPad which image tags it supports for production, and how it recommends handling its office editor components, since those come from modified ONLYOFFICE code before version 9 and modified Euro-Office code from version 9 on.
Upgrades and version tracking
Upgrades differ in what they touch. ONLYOFFICE upgrades change the server-side editor that all connected file platforms depend on, so you test the connector pairing before rollout. CryptPad upgrades change the browser client and the server together, and its office editor code has its own lineage. Ask each vendor how it signals breaking changes, whether old clients keep working during a rolling upgrade, and how long you can stay on a release line.
Who runs it and what they need
An ONLYOFFICE deployment is operated like a conventional web service: an infrastructure or platform team owns the container host, the document server, the file platform connector and the certificates. A CryptPad deployment adds a key-management question, because users lose their content if they lose their passwords and the server cannot recover it. Assign an owner for user recovery and for the monitoring that matters to each platform, and confirm the support path you can count on for production incidents.
Capability comparison: ONLYOFFICE Docs and CryptPad
This table compares what ONLYOFFICE Docs and CryptPad each offer for editing, administration, integrations and content access. Read the rows about content encryption and server access first, because they decide whether the admin and integration rows matter for your team. Where the supplied research does not settle a capability, the cell tells you what to confirm with the vendor.
| Capability | ONLYOFFICE Docs | CryptPad |
|---|---|---|
| License | AGPL-3.0 for Community Edition; paid Enterprise and Developer editions add commercial terms | AGPL-3.0, developed by a team at XWiki SAS |
| Office engine | Native editor for .docx, .xlsx and .pptx; converts DOC, ODT, RTF, ODS, CSV and ODP | Office apps before version 9 based on modified ONLYOFFICE code; from version 9 on modified Euro-Office code |
| PDF editing | Text editing, page manipulation, annotations and form filling | Confirm with the vendor; not covered by the supplied research |
| Application coverage | Documents, spreadsheets and presentations, with PDF editing | Documents, sheets, presentations, forms, kanban, code, rich text and whiteboards |
| Content encryption | Server-side editing; content is processed on the document server | Encrypted in the browser before it reaches the server |
| Server access to content | Administrators can access documents on their own servers | Administrators running unmodified code cannot read user content |
| Integrations | Nextcloud, ownCloud, Seafile, Moodle, Odoo and WOPI-compatible platforms | Office integration is built on modified ONLYOFFICE or Euro-Office code; confirm third-party integrations with the vendor |
| Admin panel and white labeling | Enterprise Edition features; Community Edition is configured through config files | Confirm admin tooling and branding options with the vendor |
| Support model | Community support via GitHub and forum; Basic, Plus or Premium support with Enterprise | Community-driven; confirm any paid support options with the vendor |
What is free, what is paid and under which license
ONLYOFFICE Docs Community Edition is licensed under AGPL-3.0, so an organization can download, self-host and modify the editors without a license fee for the software itself. The current DocumentServer release line is v10.0.0, published on October 12, 2026, following v9.4.0 on May 19, 2026. ONLYOFFICE Docs 9.4 removed the 20 simultaneous connection limit from the Community Edition and consolidated it into a single process without RabbitMQ or database dependencies.
- AGPL-3.0 terms: Running modified code as a network service can trigger source disclosure duties for those modifications, so review them with counsel before embedding changes.
- Community support: Support comes through GitHub and the community forum, not a contracted service level.
- Configuration: The Community Edition is configured through config files only, with no admin panel.
- Integrations: It works with Nextcloud, ownCloud, Seafile, Moodle, Odoo and WOPI-compatible platforms, with Docker as the recommended install method.
- Recurring cost: Your own staff or an implementation partner carry the patching, upgrades and monitoring.
Check the current DocumentServer release notes and the license text in the repository before you commit to a version.
ONLYOFFICE Enterprise Edition is the paid, commercially supported tier. According to ONLYOFFICE's edition comparison, it adds an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support levels. The Community Edition remains AGPL-3.0, so the paid tier buys operational features and support rather than a different core editor.
- Admin panel: Gives administrators a graphical console instead of editing config files only.
- White labeling: Lets you replace ONLYOFFICE branding in the interface for your users.
- Scaling: Scaling for thousands of users is listed as an Enterprise feature in the comparison.
- Support tiers: Basic, Plus and Premium levels are listed, and the response terms differ by tier.
- Quote inputs: Ask for the license term, the number of users or instances, which support tier is included and whether upgrades are covered.
Confirm the current feature list, license terms and support tier definitions directly with ONLYOFFICE before budgeting, because editions change.
ONLYOFFICE also sells a Developer Edition under a commercial license. It is aimed at software vendors that embed the editors in services they provide to their own customers. The AGPL Community Edition covers many internal deployments, but a vendor that bundles the editors into a product it sells to others should check whether the AGPL terms fit that distribution model before relying on it.
- Who needs it: Software vendors that embed the editors in a service delivered to customers.
- Who usually does not: An internal team that self-hosts the editors for its own staff, subject to the license review.
- Commercial terms: The license is separate from AGPL-3.0 and is negotiated with ONLYOFFICE.
- Distribution: Ask whether the license covers your hosting model, sublicensing and white-label use.
- Duration: Ask how the license term and renewals work, as no duration was supplied here.
When a legal review is needed, have counsel compare the AGPL obligations with the Developer license terms against your product model.
CryptPad is an end-to-end encrypted, open-source collaboration suite licensed under AGPL-3.0. It is actively developed by a team at XWiki SAS. The latest release supplied for this comparison is CryptPad 2026.5.1, published on May 26, 2026. Its office applications before version 9 are based on modified ONLYOFFICE code, and from version 9 on they are based on modified Euro-Office code, so the editor licensing sits beneath CryptPad's own AGPL terms.
- AGPL-3.0 core: The CryptPad code is available under the same license family as ONLYOFFICE Community.
- Maintainer: Development is carried out by a team at XWiki SAS.
- Funding sources: CryptPad has been funded by NLnet PET, NGI TRUST and NGI DAPSI grants, CryptPad.fr subscribers and Open Collective donations.
- Derived editors: Review the license of the modified ONLYOFFICE or Euro-Office code included in the version you deploy.
- Paid edition: No paid edition facts were supplied for this comparison.
Ask CryptPad or its maintainers whether a commercial support or paid tier exists, and what it covers.
No paid edition facts were supplied for CryptPad, so this page does not state whether a paid tier, commercial support or hosted plan exists. The reader should ask the vendor directly rather than assume either way. The questions below help a procurement team compare a CryptPad deployment with an ONLYOFFICE contract on equal terms.
- Support scope: Ask whether any commercial support covers security fixes, upgrade assistance and incident response.
- Release terms: Ask how long each release line is maintained and how security advisories are delivered.
- Hosting: Ask whether a managed option exists and where its data would be located.
- Editor components: Ask which ONLYOFFICE or Euro-Office code is in the release you plan to run and who patches it.
- Budget inputs: Ask for every recurring fee, including any support tier, hosting and staff time.
Record the answers in writing, since they determine whether CryptPad or ONLYOFFICE fits your budget and support model.
What a server that cannot read content gives up
CryptPad encrypts every document in the browser before it reaches the server, so an administrator running unmodified code cannot read content, and account keys derive from a username and password the server never sees. That protection is the reason to choose it, and it is also the reason several server-side features a team may expect are weaker or absent. Before you commit, list the features your users rely on today and check each one against this model rather than assuming the ONLYOFFICE behavior carries over. The affected areas are server-side search across document bodies, server-side conversion and thumbnailing, content moderation, eDiscovery and legal hold, and integrations that read files through an API. Recovery is the sharpest edge: if a user loses the password that derives their keys, the server cannot reset access to their content in the way a conventional admin console can. Ask CryptPad how its account recovery and key handling work in the version you plan to run, and test a lost-password scenario in a pilot before users depend on the platform.
The architecture document describes symmetric encryption with a single pre-shared key known to all participants of a document. That means anyone who holds the document key can read it, and removing a collaborator is a key-management question, not just a permissions change. Ask CryptPad how key rotation and member removal behave for a document after someone leaves, and whether a departed user's copies remain readable. Note that this is a property of the design you are assessing, not a defect to be fixed by configuration. Take these questions to two people: CryptPad, for the cryptographic behavior and supported recovery paths, and your compliance owner, for whether a platform the operator cannot inspect satisfies your retention, eDiscovery and records obligations. If those obligations require the operator to search, export or hold content, a server that cannot read content is probably the wrong fit, and ONLYOFFICE's server-side editors deserve a closer look.
What drives the running cost of each option
Running cost for ONLYOFFICE and CryptPad sits in different places. ONLYOFFICE moves money toward paid editions and integration work, while CryptPad concentrates it in your own hosting, staff time and the support you buy or go without. The cards below name who gets paid for each component and what to request in a written quote.
Server infrastructure and Docker hosting
Both platforms run on your infrastructure, so the hosting bill is yours to carry. ONLYOFFICE Docs Community Edition is AGPL-3.0 and Docker is the recommended installation method, so the editor server, document storage and the platform it plugs into all need capacity. CryptPad publishes official AMD64 and ARM64 Docker images, which makes it lighter to host at small scale. Ask any vendor or partner to size CPU, memory and storage for your user count and document mix in writing, and to state which components run in containers and which run on hosts you manage.
Staff skills and operating effort
Someone on your team pays the operating cost in hours. ONLYOFFICE Community is configured through config files only, so the admin skills needed are Docker, reverse proxy and certificate handling, and integration tuning for each file platform. CryptPad follows its admin installation guide for production, and its encryption model means you cannot recover a user's content from the server, so backup and key-handling procedures matter more. Ask who on your team will own each system and what training or documentation the provider includes.
Support options and what they cost
Support is where the two models differ most. ONLYOFFICE Enterprise Edition includes support in Basic, Plus or Premium tiers, while Community users rely on GitHub and the forum. CryptPad is community-developed and funded by NLnet PET, NGI TRUST and NGI DAPSI grants, CryptPad.fr subscribers and Open Collective donations, so no contracted response commitment comes with it. Decide whether a fixed response window is a requirement, then request the tier, response terms and renewal basis for each option in writing.
Upgrades across major lines
Upgrades carry recurring cost whichever product you choose. ONLYOFFICE DocumentServer moved to v10.0.0 on October 12, 2026, after v9.4.0 on May 19, 2026, so major-line changes need regression testing against your file platform. CryptPad's office editors track modified ONLYOFFICE code before version 9 and modified Euro-Office code from version 9, so editor changes can arrive through CryptPad releases. Ask how long each vendor or maintainer supports a line, what migration steps apply, and whether upgrade work is covered by the quote or billed separately.
Integration work with existing file platforms
The integration cost depends on where your files already live. ONLYOFFICE Docs integrates with Nextcloud, ownCloud, Seafile, Moodle, Odoo and WOPI-compatible platforms, so connecting it to an existing platform is usually configuration rather than new development. CryptPad runs as its own suite with its own encrypted storage, so moving existing files into it, and keeping them in step with a file sync platform, is a separate migration project. Scope each connector, identity link and data migration in writing, and name who tests access controls and sharing behavior before go-live.
Quote scope and recurring fees
A written quote should separate one-time work from recurring cost. One-time items include installation, integration, hardening, migration and documentation. Recurring items include hosting, support subscriptions, retainers for upgrades and testing, and any Developer Edition license needed to embed the editors in a service you give customers. ONLYOFFICE does not publish a price list in these facts, and DeployOpen quotes follow from the written scope. Request line items for each category, the assumptions behind user counts, and the exit terms if you change platform later.
Moving from one platform to the other without losing documents
The sequence below sorts documents into those a team can export and re-import and those that must be re-created, so each direction ends with a known set of content, known access rights and a tested pilot group. Nothing moves until the inventory says what can actually be read by the tool doing the move.
Inventory formats, folders and encryption status
Start by listing every document, spreadsheet and presentation, the format it is stored in, the folder or space it lives in and who owns it. For ONLYOFFICE, the native formats are .docx, .xlsx and .pptx, and files in older formats such as DOC, ODT, RTF, ODS, CSV or ODP go through conversion. For CryptPad, mark every item as encrypted in the browser, because the server cannot read that content and no server-side export will pull it out. The output is a spreadsheet with one row per item, a column for format, a column for owner and a column for source platform. Confirm the export options for each product in your version before you rely on them.
Classify content as re-exportable or re-creatable
Split the inventory into two groups. Files held on the ONLYOFFICE side, stored in a file platform or on a server you control, can usually be exported in an Office format and imported into the target. Content inside a CryptPad encrypted space cannot be moved by a server-side tool that cannot read it, so a person must open it in the browser and recreate it or save an export from the client. Moving ONLYOFFICE content into an encrypted CryptPad space is a re-creation task in the same way. Record the decision for each item, with an owner for every item marked re-create.
Map users, groups and access rights
Build a table of who can view, edit and share each item today, and the group or role that grants that access. On the ONLYOFFICE side, access comes from the file platform the editors are attached to, such as Nextcloud, ownCloud, Seafile or a WOPI host. On the CryptPad side, access depends on shared links and keys held by participants, so a person who is removed from a shared document still needs the key rotated or the document recreated under a new key. The output is an access map showing which people and groups need which rights on the target, and a list of items where access must be granted again by hand.
Rebuild integrations, links and embeds
List every place where a document link, embed or automation points to content on the source platform, including wiki pages, ticketing systems, intranet pages and external partners. Links into ONLYOFFICE are typically URLs served by the file platform, so they must be updated when the file moves. Links to CryptPad documents include the key in the link, so every shared URL must be redistributed after re-creation. Test each rebuilt link from a clean browser session. The check is a short written list of old links, new links and the owner who confirmed each one opens.
Run a pilot group before cutover
Choose a small group that uses both kinds of content daily, move their documents first and have them work in the target for a set period agreed with the project owner. Ask the pilot group to report where editing, conversion or sharing behaved differently from the source, and log each issue against the inventory row it affected. Check that formatting survives the round trip for the file types in use, and that encrypted content recreated in CryptPad opens for every intended participant. Cutover waits until the pilot log has no open issues that affect documents in scope.
Cut over and confirm the source is closed
Move the remaining inventory in the order the pilot tested, freeze edits on the source for the items being moved, and notify users of the new locations and links. Keep the source read-only and retained until every item in the inventory is marked as moved, re-created or retired, and the owners have signed off. The completion check is a reconciliation of the inventory against the target, with a count of items moved, items re-created and items deliberately left behind, each with an owner.
Where ONLYOFFICE and CryptPad projects usually run long
The seam between the editor and the file platform is where ONLYOFFICE projects usually run long. Connecting Document Server to Nextcloud, ownCloud, Seafile or another WOPI-compatible platform means agreeing on a shared JWT secret, setting the internal and public URLs each side uses to reach the other, and confirming that traffic can pass through any proxy or firewall in both directions. Each connector has its own setup path, so a mixed estate of file platforms multiplies the testing. If the team needs the admin panel, white labeling or a paid support tier, add that Enterprise configuration to the written scope early, because it changes what gets installed and who supports it. Confirm the exact settings against the version you deploy.
CryptPad work starts with its admin installation guide and ends at the network edge. Plan the reverse proxy, TLS certificates and hostnames together, and confirm the domain arrangement the guide requires before any user signs in. The official AMD64 and ARM64 Docker images shorten the build, but proxy headers and WebSocket paths still need testing from a real client browser. Schedule a round of failure testing once the instance is live, since a fault in the edge layer often looks like a fault in the editor and can cost days of diagnosis.
The longest CryptPad delays usually come from policy decisions, not from the software. Account keys derive from a username and password the server never sees, so the operator cannot reset a forgotten password or recover a lost key. Before onboarding, decide who may hold an account, how users store their recovery material and what happens to shared documents when someone leaves. Documents use a single pre-shared key known to all participants, so removing a person from a shared document is a process to test and record, and the architecture document is the place to confirm the exact behavior. Scope the effort to move existing files into encrypted documents as client-side work. Get legal, HR and document owners to sign off these choices in writing, and agree scope and timelines in writing before work starts.
Questions buyers ask before choosing or hiring help
Can CryptPad use the ONLYOFFICE admin panel?
No, not as a feature you can rely on today. The ONLYOFFICE admin panel is listed in ONLYOFFICE's edition comparison as an Enterprise Edition feature, and CryptPad runs its own modified editor code and its own account and sharing model. CryptPad administration is handled through its own admin tooling and configuration. Confirm with CryptPad and ONLYOFFICE which administrative controls, if any, carry over into a CryptPad deployment, and ask for the exact list in writing before you assume any parity. The practical consequence is that user management, audit and white-label controls need to be evaluated on the CryptPad side, not inherited from ONLYOFFICE.
What does it cost to run each option?
Both paths carry infrastructure and staff time, and the license fee is only one part. ONLYOFFICE Docs Community Edition is AGPL-3.0 licensed, so there is no license fee for the Community code, but Enterprise features and support are paid separately under ONLYOFFICE's edition terms. CryptPad is also AGPL-3.0 licensed, and its official Docker images make the server footprint predictable. Recurring costs are hosting, storage, backups, patching and the time your team spends on upgrades. One-time costs include setup and any integration work. Ask any vendor or partner for a quote that separates license, support, hosting, one-time setup and recurring operations, and ask which items are optional.
How long does a deployment take?
The duration depends on scope, not on the license. A single-node test instance can be stood up quickly from a container image, while a production deployment needs decisions on identity, storage, backups, TLS, monitoring and user migration. No timeline is supplied for either product in this comparison, so treat any number you hear as unverified. Drivers include the number of integrations, how many existing documents you migrate, whether you need high availability, and how much validation your security team requires. Ask for a fixed-scope plan with milestones and named deliverables before committing to a date.
What does the work need from our internal team?
Plan for named owners across infrastructure, identity, security and the business users who will test the editors. The platform team owns containers or hosts, the database, reverse proxy and certificates. The identity team decides how users sign in. Security reviews key handling, retention and logging. A key difference is that CryptPad's encryption happens in the browser, so your team must explain to users that recovery and sharing behave differently from a server-side editor, and must decide who holds responsibility for lost passwords. ONLYOFFICE needs a document server integrated with your file platform, so your team owns those connections. Confirm each responsibility with the vendor documentation before you staff the project.
Can our team self-host without a partner?
A capable platform team can self-host either option using the official documentation, but the answer depends on your team's experience with containers, reverse proxies, backups and upgrades. CryptPad publishes official AMD64 and ARM64 Docker images and says production self-hosting follows its admin installation guide, so a team that already runs containers has a documented starting point. ONLYOFFICE recommends Docker for installation as well. Partner help is typically useful for hardening, integration with identity and storage, and ongoing upgrades. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, under fixed-scope agreements, with ongoing support available as a retainer.
Can encrypted content later move to ONLYOFFICE?
Not automatically. CryptPad encrypts every document in the browser with keys the server never sees, and its architecture uses symmetric encryption with a single pre-shared key known to all participants of a document. An ONLYOFFICE server cannot read that content directly, so moving documents means decrypting them through a client that holds the keys, exporting to a standard format such as .docx, .xlsx or .pptx, and then importing into the new system. Format fidelity, comments, version history and permissions may not survive the trip. Ask the vendors what export paths exist and test them on a sample set before you commit.
Does a server that cannot read content meet our compliance needs?
It can support some controls, but it does not prove compliance on its own. End-to-end encryption reduces what administrators can see, which helps with confidentiality arguments. It does not replace access reviews, logging, retention, incident response or the evidence an assessor asks for. Auditors and certification bodies issue any attestation, and DeployOpen prepares systems, controls and evidence for those assessments without issuing reports. Ask your assessor early whether the key-management model and loss of recovery are acceptable for the data you handle.
How DeployOpen works on this
DeployOpen plans, implements, customizes and supports self-hosted open-source platforms inside your own infrastructure, so the choice between a server-side editor and an end-to-end encrypted one is made against your real data flows and admin needs. We start from a written scope and only then build, test and document the environment you approve.
How we scope
- Map which documents, users and integrations need server-side features such as admin controls and connectors.
- Record where content may be read by administrators and which encryption trade-off your policies accept.
- Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope.
How we build
- Deploy the chosen editor stack in your cloud accounts, data centers or air-gapped network, not ours.
- Test browser-side key handling, file sharing and editing paths against the scope you approved.
- Confirm the license and edition each component needs, including any Developer Edition requirement for embedding.
How we hand over
- Document architecture, configuration files, hardening decisions and backup procedures for your operations team.
- Provide evidence and records that your internal or external auditors can review, without claiming any certification.
- Walk your administrators through daily operation, user onboarding and what to do if you later move between platforms.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrades for each component against its release line so editor and platform versions stay compatible.
- Ask us to quote ongoing support from the written scope, since DeployOpen does not publish a price list.

