When ONLYOFFICE DocSpace cloud fits and when self-hosting fits
Choose ONLYOFFICE's hosted DocSpace when staff time is the main constraint, and run the AGPL DocSpace server yourself when the main constraint is where documents live and who can reach them. Data location comes first because it decides whether the hosted option is open to you at all. If a regulator, a customer contract or internal policy requires files to stay in your own cloud account, data center or air-gapped network, the hosted service is off the table, and the question becomes which in-house operating model you can staff. If the residency rule covers only some data, split the estate: keep the restricted library self-hosted and test whether the hosted service meets the rest. Write down each data class, its residency rule and the owner who signs off on it before you request a quote.
The second test is how many admins and users you carry and whether you have people for upgrades and backups. The hosted plan is priced per admin, with storage and SSO in the Business plan, so the bill grows with the number of people who administer the system and with the storage you buy. Ask for the exact per-admin price, the storage allowance for your user count and confirmation that SSO is included in the tier you are quoting. Self-hosting moves those costs to your side: infrastructure, database, backup storage and the staff hours for upgrades and restores. If nobody on your team has restored a backup or tested an upgrade on a staging copy, the hosted option removes a recurring risk, provided your residency rule allows it.
The third test is how much control you need over the admin panel, white labeling and branding. ONLYOFFICE's edition comparison lists an admin panel and white labeling as Enterprise Edition features for ONLYOFFICE Docs, alongside Basic, Plus and Premium support tiers. Confirm in writing which of these your DocSpace deployment includes before you assume it. Self-hosting gives you direct control over configuration, branding and the server stack, but you also own the patch cadence and the support route. The hosted service gives you a vendor-run environment with fewer knobs. List the branding and admin controls your users must see, then ask the vendor for a written mapping of each control to each deployment model.
How ONLYOFFICE DocSpace cloud and self-hosting compare on each factor
This table compares DocSpace in ONLYOFFICE's cloud with running DocSpace yourself on licensing, operations, data location, upgrades, editions, support and cost. Read the editing engine rows as ONLYOFFICE Docs context, not as DocSpace-specific terms. Confirm current plan and license terms on ONLYOFFICE's own pages before you decide.
| Factor | DocSpace in ONLYOFFICE's cloud | Self-hosted DocSpace |
|---|---|---|
| Licensing | Governed by ONLYOFFICE's cloud plan terms. Confirm current terms on the edition comparison page. | Server license set by ONLYOFFICE. Confirm the license for the exact DocSpace version you plan to run. |
| Who operates the server | ONLYOFFICE runs the service. Your admins manage users, groups and settings within the plan. | Your team or a delegated partner runs hosts, databases, networking, access controls and monitoring. |
| Where documents are stored | Stored in ONLYOFFICE's cloud. Ask about hosting regions, encryption and how you export data. | Stored in your cloud account, data center or air-gapped network under your own retention rules. |
| Upgrade responsibility | ONLYOFFICE applies service updates. Ask for notice periods, maintenance windows and rollback options. | Your team plans, tests and applies each release, including dependent services such as the editing engine. |
| Available editions and enterprise features | Storage and SSO are tied to named plan tiers. Confirm which tier includes each feature you need. | Features depend on the license you hold. For ONLYOFFICE Docs, admin panel and white labeling are Enterprise features. |
| Support channels | Support follows the plan terms. Confirm response channels, hours and escalation in writing. | Community support runs through GitHub and the forum. Paid Enterprise support tiers are Basic, Plus or Premium. |
| Cost structure | Recurring subscription under plan terms. Ask for current pricing and how admins are counted. | Recurring infrastructure and staff or partner time, plus any subscription. Setup, upgrades and support are separate lines. |
What data location and access control mean for a regulated team
The cloud and self-hosted models differ mainly in who operates the systems that hold documents, administrator credentials and logs. Each card covers one place where that difference shows up in a regulated review. Use them to build questions for ONLYOFFICE and to decide which controls your team must own.
Where data and metadata sit
In the cloud model, documents, user records, sharing metadata and activity logs sit in ONLYOFFICE's hosting environment, so the region, backup locations and subprocessors are the vendor's to disclose. In a self-hosted model, the same data stays in your cloud accounts, data centers or air-gapped network, and you decide where backups and logs go. Ask which region holds each data type, and confirm that the metadata categories in the vendor's documentation match what your classification policy covers. Each data type needs a named location in both models.
Who holds administrator access
In the cloud model, ONLYOFFICE operates the platform, so ask which of its staff can reach tenant data, under what approval, and whether those accesses are logged and visible to you. In a self-hosted model, your team holds operating system, database and container access, so your own privileged access management and separation of duties carry that risk. Neither model removes the need for named administrators and break-glass procedures. Keep a reviewed list of who can change tenant settings in either case.
Identity and access policy
The Business plan includes SSO for DocSpace cloud, so confirm which identity protocols it supports, how group mapping works and whether multi-factor authentication is enforced by your identity provider. In a self-hosted deployment, you configure those integrations yourself, and access policy is only as strong as the identity provider and server settings you maintain. Check the edition comparison before assuming a feature is in your plan. Test deprovisioning in both models, so a removed user loses document access.
Audit evidence and logging
Ask what activity records the cloud service keeps, how long it retains them, and whether you can export them to your SIEM or hand them to an assessor. In a self-hosted deployment, logs exist only where you configure them, so retention, integrity protection and forwarding are your responsibility from the first day. Auditors ask for evidence of access reviews and change history in either model. Decide in advance which records prove each control, and test that you can produce them.
Residency questions for ONLYOFFICE
Put these questions in writing before signing: which regions host primary data and backups, which subprocessors touch tenant content, where support staff operate from, and how deletion works when a subscription ends. Ask for the vendor's current security and compliance documentation, and confirm that it covers DocSpace cloud rather than only other ONLYOFFICE products. Do not rely on a verbal answer or a marketing page. Terms change, so the answers belong in the contract.
Controls, evidence and audit boundaries
DeployOpen prepares controls, configuration records and evidence for a self-hosted deployment, including the material an assessor will request. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so neither the cloud service nor a self-hosted DocSpace should be described as certified unless the vendor's documentation or an assessor says so. Confirm the applicable framework and scope with your assessor before work starts.
What your team runs in each model
This table lists the operating tasks that move between the hosted ONLYOFFICE cloud service and a self-hosted deployment, with who performs each one and the skills your team needs. Read the cloud column as questions to confirm in the agreement, and the self-hosted column as work your staff owns. The main takeaway is that self-hosting moves capacity planning, patching and incident response onto your team, and the 9.4 change to Community Edition makes load testing central to that planning.
| Operating task | Cloud model | Self-hosted model |
|---|---|---|
| Installation and Docker deployment | ONLYOFFICE provisions the hosted environment. Confirm the setup steps and what you configure yourself. | Your team installs the server. Docker is the recommended method for ONLYOFFICE Docs. Needs container and Linux administration skills. |
| Configuration | Settings are exposed through the hosted admin options. Confirm which settings you can change. | Community Edition is configured through config files only. Needs disciplined config management and change tracking. |
| Backups and restore | Confirm backup frequency, retention and whether you can request a restore test in the agreement. | Your team backs up files, databases and configuration, and tests restores. Needs database and storage administration skills. |
| Monitoring and alerting | The vendor monitors the hosted service. Ask what metrics, logs and alerts you can see. | Your team owns metrics, logs and alerts for the document server and its dependencies. Needs observability tooling. |
| Concurrent editing limit | Confirm concurrency terms and user limits in your plan before rollout. | Since 9.4, Community Edition has no 20 simultaneous connection limit, so capacity depends on your hardware. Plan load tests before go-live. |
| Upgrades across major lines | The vendor applies upgrades on its schedule. Ask for notice periods and rollback terms. | Your team plans moves such as 9.4 to DocumentServer v10.0.0 (released October 12, 2026), tests integrations, then cuts over. Needs change management. |
| Security patching | The vendor patches the hosted stack. Confirm patch windows and how advisories reach you. | Your team tracks ONLYOFFICE releases and patches container images and the host operating system. Needs vulnerability management. |
| Integration with file platforms | Integration depends on what the hosted service exposes. Confirm connectors for your file platform. | Docs integrates with Nextcloud, ownCloud, Seafile and WOPI platforms. Your team configures and tests each connector. Needs integration testing skills. |
| Incident response and support | Ask who triages, notification timing and the escalation path in the contract. | Your team detects, triages and restores. Community support runs through GitHub and the forum. Enterprise adds Basic, Plus or Premium support. |
What moves the cost in each model and what to ask for in a quote
The two models spread cost across different parties. In ONLYOFFICE's cloud, the recurring cost is the plan fee for DocSpace, which is priced per admin with storage and SSO included in the Business plan. You pay ONLYOFFICE for the platform and the hosting, and your internal staff spend less time on operations. In a self-hosted DocSpace deployment, you pay your own cloud or data center bills, the staff who patch and back up the stack, and any paid license for the Enterprise or Developer edition your use case requires. Each model also carries implementation work: planning, identity integration, data migration and hardening. That work is usually one-time, but it is often paid to a partner such as DeployOpen under a fixed written scope. Confirm current DocSpace cloud plan pricing directly on ONLYOFFICE's pricing pages, because plan tiers, admin counts and storage limits can change.
Recurring costs in the self-hosted model rise with user count, storage growth, the number of environments you keep (production, staging, disaster recovery) and the support tier you buy. Admin headcount is the largest driver to model, since every admin added to a cloud plan raises the fee, while self-hosting shifts that cost into staff time and infrastructure. One-time costs rise with the number of integrations, the identity provider you connect, and how much existing file data must be moved. Ask every vendor and partner for the same breakdown: which items are one-time and which recur, what is included in SSO and storage, what the license covers for each edition, who carries upgrade and security patch work, and what happens to data and pricing if you leave. For the self-hosted path, ask DeployOpen for a written scope that lists deliverables, timelines and the retainer for ongoing support or upgrades. DeployOpen does not publish a price list, and a quote follows from that scope.
Who supports and upgrades ONLYOFFICE in each model
In the cloud model, ONLYOFFICE operates the DocSpace service, so the vendor controls when the platform is upgraded and how it is patched. Your team manages users, rooms and administrator settings within the service, and the subscription determines which admin features and storage limits apply. Pricing is per administrator, and the Business plan includes storage and SSO, so the cost structure is recurring and tied to the plan you choose. Data sits in ONLYOFFICE's environment, which changes who can answer questions about data location and retention.
- Upgrades: ONLYOFFICE applies platform releases to the service, so you do not schedule DocumentServer or DocSpace upgrades yourself.
- Support channel: Support runs through ONLYOFFICE's own service channels, and the tier depends on the plan you buy.
- Plan boundaries: Storage and SSO are included in the Business plan, so confirm which features your target plan covers before you commit.
- Data location: Ask where data is stored, which regions are used and how backups and deletion requests are handled.
- Exit path: Ask how documents and user data can be exported if you later move to a self-hosted deployment.
Before you sign, get the support tier, service levels and data processing terms in writing from ONLYOFFICE.
The Community Edition is AGPL-3.0 licensed, and your team installs, configures and upgrades it inside your own infrastructure. ONLYOFFICE Docs Community Edition has no paid vendor support tier, so the support model is community based. Community support runs through GitHub and the ONLYOFFICE forum, and it depends on public responses rather than a contracted response time. Configuration is handled through config files only, which keeps the setup transparent but places the operating burden on your staff.
- Upgrades: Your team applies each release, such as DocumentServer v10.0.0 published on October 12, 2026, and tests it against your integrations.
- Support channel: GitHub issues and the community forum, with no contracted response commitment.
- Scaling: ONLYOFFICE Docs 9.4 removed the 20 simultaneous connection limit from the Community Edition, so connection caps no longer drive the edition decision on their own.
- Admin features: The admin panel and white labeling are Enterprise features, so Community operators manage these through configuration.
- Developer Edition: Vendors that embed the editors into services they supply to customers need a commercial Developer Edition license instead of relying on AGPL terms alone.
Confirm internally who monitors security advisories and who owns the upgrade calendar before you go live.
The Enterprise Edition is a paid self-hosted edition that you run in your own environment, with ONLYOFFICE providing the vendor support tier you purchase. The edition adds an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support. Your team still performs upgrades and infrastructure work, but the support contract gives you a named vendor channel for production issues. The subscription cost recurs, and the support tier is the main variable to compare.
- Upgrades: Your team schedules and applies releases, with vendor support available for questions during the process.
- Support tier: Basic, Plus and Premium levels differ in coverage, so compare response expectations and hours in the written quote.
- Admin panel: Central administration is available in the Enterprise Edition and is not part of the Community configuration model.
- White labeling: Useful when the editors appear under your own brand inside your workspace.
- Scaling: The Enterprise Edition lists scaling for thousands of users as a feature, so ask how sizing and load testing are supported.
Ask ONLYOFFICE which support tier matches your production hours, escalation path and data residency needs before you purchase.
In this model, your organization runs ONLYOFFICE in its own cloud accounts, data centers or air-gapped networks, and an implementation partner plans, deploys, hardens, backs up, upgrades and documents the platform under a written scope. DeployOpen supports self-hosted platforms through fixed-scope engagements, with ongoing support, upgrades and continuous testing available as retainers. DeployOpen is not ONLYOFFICE, so vendor support, licensing and product defects still go to ONLYOFFICE under whichever edition you hold. The partner adds implementation and operating capacity, not a replacement for the vendor's support tier.
- Upgrades: The partner can take on upgrade planning and execution under a retainer or as a defined project.
- Support split: DeployOpen handles implementation, operations and integration work, and ONLYOFFICE provides product support for the edition you license.
- Engagement form: Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Pricing: DeployOpen does not publish a price list, so a quote follows from the written scope.
- Accountability: Define in the contract which party responds to incidents, which handles patches and who keeps the documentation current.
Check that the partner scope, the vendor support tier and your internal on-call duties together cover every production hour you need.
How to move ONLYOFFICE DocSpace data from cloud to self-hosted, or back
This sequence takes a DocSpace tenant from inventory to a verified target environment and a decommissioned source, with a rollback path at every cutover point. Each step names who does the work and what must be confirmed before the next one starts.
Inventory users, admins, spaces, documents and branding
Your internal team lists every user account, administrator, room or space, document library, third-party integration, and branding setting in the current tenant, and records who owns each item. DeployOpen can take on this work under a fixed scope if you prefer an external team to build the inventory. The step is done when you have a signed-off inventory that maps each space to an owner and each integration to a named system, so nothing is discovered for the first time during cutover.
Confirm export and import options with ONLYOFFICE
Before you commit to a path, ask ONLYOFFICE in writing which export and import methods apply to your current DocSpace version and which apply to the self-hosted DocSpace server you plan to run. Confirm what moves as files, what moves as metadata, and what must be recreated by hand, such as access rights, integrations and branding. The step is done when the answers are attached to the project record and each gap has an owner.
Plan the target environment
Your infrastructure or platform team defines where the self-hosted DocSpace server will run, including the operating environment, database, storage, backup target, network access and identity integration, and confirms the supported versions with the vendor documentation for the release you will deploy. A partner such as DeployOpen can prepare this design as part of a fixed-scope implementation. The step is done when the design is reviewed by security and operations and the backup and restore method has been agreed.
Run a test migration on a copy
Load a copy of the exported data into the target environment and compare it with the source. Your team checks user counts, room membership, document counts, version history where it applies, and integration behavior. Record every mismatch and classify it as fixed, accepted or blocking. The step is done when a repeat test produces no blocking mismatches and the owner of each accepted difference has signed off.
Validate access rights and document formats
Verify that each group and user sees only the spaces they should, and that administrator roles match the inventory. Then open a sample of documents in each native format, .docx, .xlsx and .pptx, and a sample of files that depend on conversion for DOC, ODT, RTF, ODS, CSV and ODP. Confirm that edits, comments and PDF operations behave as expected, including PDF editing with annotations and form filling. The step is done when the access matrix and format test log are approved by the data owners.
Cut over with a rollback plan
Schedule the production cutover, freeze changes on the source tenant, run the final export, import and reconciliation, then redirect users and integrations. Keep the source tenant readable and retain the last verified backup so you can return to it if a blocking issue appears. Written rollback criteria, agreed before the window opens, decide when to revert. The step is done when users log in to the target, integrations return the expected results, and no rollback criterion has been triggered during the agreed observation period.
Decommission the old tenant
Once the target has run cleanly, export a final archive from the source for your records, remove integrations that point to the old tenant, revoke service accounts, and close the cloud subscription or agreed exit terms. Confirm with your legal and records team how long the archive must be retained and where it is stored. The step is done when the subscription is ended in writing, the archive is verified and stored, and the configuration record shows that no live system still depends on the old tenant.
What buyers ask before choosing ONLYOFFICE DocSpace cloud or self-hosting
How does the total cost of self-hosting DocSpace compare with the cloud plan?
Self-hosting swaps a per-admin subscription for infrastructure, labor and support that you carry yourself. The cloud plan's price, storage allowance and SSO terms are on ONLYOFFICE's own pages, so confirm them there before you build a comparison. On the self-hosted side, recurring costs include compute and storage in your cloud account or data center, backups, monitoring, patch testing and staff time for upgrades. One-time costs include design, identity integration and initial hardening. User count, availability targets, storage volume and the number of document servers you run all push the self-hosted bill up or down. Ask any implementation partner for a quote built from a written scope that lists these inputs, then compare it with the cloud plan at the same user count, storage volume and SSO requirement. DeployOpen does not publish a price list, so its quote follows from that written scope.
How long does a self-hosted DocSpace rollout take, and what drives that time?
The duration depends on scope, and no supplied source gives a standard timeline for a DocSpace rollout, so treat any figure you hear as something to confirm in writing. The main drivers are the number of integrations (identity provider, storage, document editors and any file platforms), the readiness of your hosting platform, network and TLS setup, change approvals inside your organization, the volume of data to migrate and the testing you require before go-live. Version choice also matters, because ONLYOFFICE publishes new releases on its own schedule, with DocumentServer v10.0.0 dated October 12, 2026 in the supplied release record. Ask for a timeline tied to named deliverables and milestones. DeployOpen's engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
What skills does an internal team need to run self-hosted DocSpace?
Your team needs working skills in Linux administration, container operation, database and storage administration, reverse proxy and TLS configuration, and identity integration. ONLYOFFICE's DocumentServer README names Docker as the recommended installation method for ONLYOFFICE Docs, so container skills are a practical baseline. Someone also has to own backups and test restores, monitor availability, track vendor releases and apply upgrades on a schedule. Confirm the exact components and supported platforms for the DocSpace version you plan to deploy against ONLYOFFICE's documentation, because the stack changes between releases. Write down who answers alerts out of hours, who approves upgrades and who keeps the runbook current. Those ownership decisions often cost more time than the initial installation.
Can a team self-host DocSpace without an implementation partner?
A team can self-host without a partner if it already has the skills described above and enough capacity for upgrades, hardening, backup testing and evidence collection. The real question is whether that capacity exists every quarter, not only during the first install. Community support for ONLYOFFICE comes through GitHub and the forum, while Enterprise adds support tiers, so decide early which level of response time your business needs and confirm what each tier covers on ONLYOFFICE's edition comparison page. A partner can take on part of the work under a written scope: planning, implementation, customization, integration, hardening, backup setup, upgrades, documentation and support. DeployOpen offers those services for self-hosted platforms in your own infrastructure, and ongoing support, upgrades and testing are available as retainers.
How hard is it to switch from DocSpace cloud to self-hosting later?
The document files themselves are the easy part, because ONLYOFFICE's native formats are .docx, .xlsx and .pptx Office Open XML files. The harder parts are users and identities, permissions, sharing links, comments and version history, room or folder structures, and the integration settings that connect the editors to your storage and identity provider. Before you commit, ask ONLYOFFICE in writing what export paths exist for each of these items and whether any of them stay behind in the cloud. Then run a test migration with a representative set of users and folders, and time it. Plan a cutover window, a rollback path and a period when both systems stay readable. Write the migration steps into the scope so the cost of moving is visible before the move starts.
Does a free Community Edition deployment cover what buyers need?
It depends on your needs, and the supplied facts cover ONLYOFFICE Docs rather than the DocSpace server, so confirm DocSpace edition terms on ONLYOFFICE's pages. For ONLYOFFICE Docs, the Community Edition is AGPL-3.0 licensed, and ONLYOFFICE 9.4 removed the 20 simultaneous connection limit from it. The Enterprise Edition adds an admin panel, white labeling, scaling for thousands of users and Basic, Plus or Premium support, and Community configuration is done through config files only. ONLYOFFICE also sells a Developer Edition under a commercial license for software vendors that embed the editors in services they provide to customers. If you only edit documents for your own staff, the Community path may fit, but an admin panel, white labeling or a formal support contract usually triggers an Enterprise quote. Check the edition comparison before deciding.
Which compliance evidence can each DocSpace hosting model provide?
Neither model delivers a certificate on its own, and the proof you need depends on the framework you must meet. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, because independent auditors and certification bodies do that work. In a cloud model, ask ONLYOFFICE which third-party reports it holds, what scope they cover and how you obtain them, then map the gaps that remain in your own controls. In a self-hosted model, you own the evidence for hosting, access control, logging, backups, patching and change records. Ask your assessor which control IDs in your framework apply to each layer, and build the evidence pack around those IDs. Confirm every report and its scope with ONLYOFFICE and your auditor before relying on it.
How DeployOpen plans, deploys and supports self-hosted ONLYOFFICE
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For ONLYOFFICE DocSpace cloud vs self-hosted, we start by agreeing where the data must sit, who operates the server and what the upgrade path looks like before any installation begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which DocSpace or Docs components, storage locations and identity sources are covered.
- Ongoing support, upgrades and continuous testing can be added later as a retainer, priced separately from the build.
How we build
- We deploy the self-hosted server inside your cloud account, data center or air-gapped network, as agreed in scope.
- Integrations with your file platform, identity provider and storage are configured and tested against the written scope.
- Hardening, backup and restore procedures are implemented and tested before the platform is handed to your team.
How we hand over
- You receive documentation covering architecture, configuration, backup, upgrade steps and operating runbooks for your team.
- Handover includes a review of the cost components that remain with you, such as hosting, storage and staff time.
- Compliance-relevant controls and evidence are prepared for your assessor, though DeployOpen does not issue audit reports or certifications.
How we support
- Support after handover can be provided through a retainer covering upgrades, patching and periodic testing.
- Upgrade planning checks each ONLYOFFICE release against your scope before it is applied in your environment.
- Ask any provider, including DeployOpen, to confirm response windows and support tiers in writing before you sign.
