ownCloud Infinite Scale or OpenCloud: when each fits and what the decision turns on
A buyer who must pick a self-hosted file platform now should decide on ownership and support before features, because oCIS and OpenCloud share much of their code. oCIS under Kiteworks fits organizations that want the original project, its Apache-2.0 release line (v8.2.1 on October 2, 2026, with v9.0.0-rc.1 on October 12, 2026) and a vendor relationship with the company that owns the ownCloud brand, provided that ownership is acceptable to their procurement and risk teams. OpenCloud fits teams that want the fork maintained by OpenCloud GmbH under the Heinlein Group, which publishes under Apache 2.0 and AGPL-3.0 and offers paid builds for environments that need support and professional services (OpenCloud community). That choice suits buyers who accept a newer project with its own release history (v8.1.0 on October 5, 2026) and want to verify how that history develops.
Four drivers should settle it. The first is ownership and governance: ask who controls the roadmap, who can change license terms and how the Kiteworks ownership announced on November 21, 2023 affects the open-source position in writing (ownCloud announcement). The second is the support contract: request the written scope, response commitments and whether the paid tier covers upgrades and security fixes for the exact version you deploy, since the public material available here does not set out oCIS support tiers. The third is release cadence: compare how often each project ships, whether stable releases follow release candidates, and whether your change process can absorb a major version. The fourth is identity setup: both can use an embedded OpenID Connect provider or Keycloak, so test group mapping, MFA enforcement and offboarding against the version you intend to run before you commit.
Which platform fits which scenario
This table maps common buyer situations to the platform that fits each one better, and names the condition under which the other platform would be the stronger choice. Read each row against your own estate, team skills and governance requirements before shortlisting either product.
| Scenario | Better fit and reason | Choose the other platform when |
|---|---|---|
| Existing ownCloud estate | oCIS, because it is the ownCloud line that continues the same product family, with the same WebDAV and client ecosystem and a documented path from ownCloud's own releases. | Your estate depends on governance or support terms that OpenCloud GmbH offers and Kiteworks does not, or you want to avoid staying with the ownership change that followed the 2023 Kiteworks announcement. |
| New Kubernetes deployment | oCIS, because the documentation describes Kubernetes readiness with Helm charts, which suits a platform team that already manages Helm releases. | Your team prefers a Go service with a filesystem-only data path and wants to confirm the Kubernetes packaging and upgrade approach directly with OpenCloud GmbH before committing. |
| Team wanting a database-free filesystem store | OpenCloud, because its server is described as storing all data in the filesystem with no database, which reduces the number of stateful components to back up and restore. | You need the S3, NFS or PosixFS backend options documented for oCIS, or you want to confirm that OpenCloud's storage layout meets your backup and recovery design. |
| Buyer weighting vendor governance heavily | Depends on the buyer. Ask Kiteworks about the ownCloud Open Source Program Office and OpenCloud GmbH about its project governance, then compare written commitments on licenses, release policy and paid support. | Choose OpenCloud if the Heinlein Group's stated history and OpenCloud's dual Apache 2.0 and AGPL-3.0 licensing match your review criteria better than Kiteworks ownership. |
| Air-gapped site | Either platform can be self-hosted, so the deciding factors are offline image or binary delivery and update packaging. Confirm both vendors' offline update process before choosing. | Choose the platform whose offline installation and patch process your security team can verify inside the network, since neither vendor's air-gap procedure is detailed in the facts supplied here. |
| Need for an identity provider with no extra components | oCIS, which includes an embedded LibreGraph Connect identity provider for basic deployments and also connects to external OpenID Connect providers. | You already run Keycloak or another OIDC provider and want OpenCloud, which also authenticates through OpenID Connect with an external provider or the embedded option. |
| Office editing with Collabora Online or ONLYOFFICE | Both can be connected through WOPI, so confirm the connector and version pairing for your chosen platform before committing to an office suite. | Your office integration plan depends on a specific connector that has been tested with only one of the two platforms in your own environment. |
| Need for a paid support contract from the product's maintainers | OpenCloud, because OpenCloud GmbH offers paid builds for environments that need support and professional services. | Your procurement requires a support agreement with the company that owns the platform, in which case confirm what Kiteworks offers for oCIS in writing. |
How oCIS and OpenCloud are built and what that means for operations
oCIS and OpenCloud share a Go codebase, Apache 2.0 roots and OpenID Connect sign-in, but they differ in how much they ask of your infrastructure. The cards below cover the packaging, storage, identity and deployment choices that determine how much operating work each platform creates, and when those differences matter for your team.
Single Go binary of microservices
oCIS ships as one binary that runs several microservices in a single process, and the same packaging runs from a small single host up to Kubernetes clusters. The operational consequence is a simpler first install, but you still need to decide how the services are split once load grows. This matters most for small teams that want one artifact to patch. Confirm with the vendor how the single-process and multi-service modes are recommended for your user count before you commit.
Filesystem storage without a required database
OpenCloud stores all data in the filesystem and uses no database, and oCIS basic setups also need no external database. Backups, restores and capacity planning therefore center on the storage layer and its snapshots rather than on a separate database tier. This matters when your team has no database operations skills or wants fewer moving parts. Check how metadata consistency is protected during backup on the storage you choose, because a filesystem backup taken mid-write can differ from a database dump.
Choosing oCIS storage backends
The oCIS documentation lists S3, NFS and PosixFS storage backends, so the same platform can sit on object storage, a network file share or a local POSIX filesystem. The choice affects latency, backup tooling, and whether a storage vendor's features such as versioning are available to you. This matters when you already run an object store or a NAS that your security team has approved. Ask the vendor which backend it supports for your scale and whether any feature set differs by backend.
Embedded or external identity providers
Both platforms authenticate users through OpenID Connect, either with the embedded LibreGraph Connect provider or with an external provider such as Keycloak. Using the embedded option keeps the first deployment small, while an external provider lets your identity team own MFA, password policy and account lifecycle. This matters if you already run a corporate identity service or must meet an existing access review process. Confirm how group claims and role mapping are passed through in your chosen setup before rollout.
Kubernetes readiness and Helm charts
oCIS is documented as Kubernetes-ready and provides Helm charts, which suits platform teams that already run clusters and GitOps pipelines. The consequence is that upgrades, scaling and secrets follow your cluster processes, but you also inherit cluster maintenance. This matters most when your platform team standardizes on Kubernetes, not for a single-host file share. Check whether OpenCloud offers a comparable chart or manifest for your clusters, since this review does not establish that from the supplied sources.
Deployment support boundaries
Both projects are open source, so the operating model depends on who will patch, monitor and back up the stack. OpenCloud offers paid builds with support and professional services, and oCIS is maintained within the ownCloud and Kiteworks ecosystem. The practical question is which parts of the stack your own staff or a partner must own when a release breaks. Ask each vendor for its written support scope, supported versions and upgrade path before you size the team.
How each platform handles login and directory integration
An embedded identity provider keeps sign-in inside the platform, so a small or isolated deployment has fewer components to install, patch and back up. Both platforms offer an embedded option built on LibreGraph Connect, which can suit a lab, a branch site or an air-gapped network without an existing directory service. The trade-off is that the platform team also owns account lifecycle, password policy and recovery for every user.
- Minimal start for oCIS: The oCIS README says basic deployments need no external database and no external identity provider, so the first install has the fewest moving parts.
- Embedded option in OpenCloud: OpenCloud can use the same embedded LibreGraph Connect provider, so its login model is close to oCIS at this stage.
- Identity data in the platform: Accounts live alongside the platform's own data, so backups must cover the identity store as well as the files.
- Feature limits to confirm: Check whether the embedded provider supports multi-factor authentication, password rules, account lockout and bulk user import for your environment.
Before choosing this option, confirm with each vendor how accounts are created, disabled and exported, and whether the embedded provider stays supported as the user count grows.
For enterprise single sign-on, both platforms authenticate users through OpenID Connect. That lets one identity provider, such as Keycloak, handle sign-in for file access, administration and other applications. Central login keeps password policy, multi-factor rules and offboarding in one place, which is usually the first requirement security teams raise. The platform still needs correct client registration, redirect addresses and token claims.
- oCIS external providers: The oCIS README says it connects to external OpenID Connect providers such as Keycloak, alongside its embedded option.
- OpenCloud external providers: Its README says users authenticate through OpenID Connect with either Keycloak or the embedded provider, so the external path follows the same design.
- Client registration: Each platform needs its own OIDC client in the identity provider, with redirect addresses matched to the public hostname.
- Claims and roles: Map the claims that carry user name, email and group membership to platform roles, and confirm the exact claim names in each vendor's documentation.
- Hostname planning: Users who reach the platform through more than one hostname can break redirect handling, so test each address in staging.
Ask each vendor for a worked example of a Keycloak client configuration, and confirm which claims the platform reads for roles and quotas.
Many enterprises keep accounts in Active Directory or LDAP, and this comparison does not establish a direct LDAP connector for either platform. Confirm whether either platform has one before you design around it. The common alternative is to federate the directory into the external identity provider, so the platform trusts the tokens it issues. That keeps the platform unaware of the directory, but it moves group handling and account disablement into the identity provider.
- Direct LDAP support: Confirm for each platform whether a native directory connector exists, which versions include it, and whether it is part of the community or paid build.
- Federation through the identity provider: Directory changes reach the platform through the identity provider's tokens, so the federation settings become part of the platform's access design.
- Nested and disabled groups: Test whether nested groups and disabled accounts take effect, since an active session can outlive a termination.
- Service accounts: Confirm how sync clients and automated jobs authenticate when the directory enforces password rotation.
- Attribute mapping: Confirm which directory attributes map to quota, role and folder permissions.
Run a test with a disabled account and a nested group before go-live, and keep the result as evidence for your access review.
The supplied facts for both platforms describe OpenID Connect, not SAML 2.0 integration. Organizations whose identity provider offers only SAML will need a broker, such as Keycloak, that accepts SAML from upstream and issues OIDC tokens to the platform. A broker adds a component, so it also changes the upgrade, backup and availability plan for the whole stack.
- OIDC as the documented standard: Both platforms are described as using OpenID Connect, so SAML-only environments should not assume direct support.
- Broker operations: The broker is one more service to monitor, back up and patch, and it holds its own certificates.
- Certificate rotation: Schedule rotation of signing certificates on both sides of the broker so that a renewal does not lock out every user.
- Client application support: Confirm that desktop, mobile and office integrations accept the chosen login flow through the broker.
- Session behavior: Confirm session lifetimes, token refresh and forced sign-out when a user is removed.
Ask each vendor in writing whether SAML is supported directly, and if not, which broker patterns they have tested with the release you plan to deploy.
Capability comparison: oCIS against OpenCloud on supplied facts
This table compares ownCloud Infinite Scale and OpenCloud on license, language, database, storage, identity, clients, office integration, Kubernetes packaging, latest release and paid support. Where the published sources are silent, the cell tells you what to confirm with the vendor, so treat those rows as due diligence items rather than settled answers.
| Capability | ownCloud Infinite Scale (oCIS) | OpenCloud |
|---|---|---|
| License | Apache-2.0 | Apache 2.0 and AGPL-3.0, with source free to download and use |
| Server language | Go, shipped as a single binary of microservices | Go codebase released under Apache 2.0 |
| Database requirement | No external database needed for basic deployments | No database; all data is stored in the filesystem |
| Storage backends | S3, NFS and PosixFS | Filesystem storage is documented; confirm whether other backends are supported |
| Identity options | Embedded LibreGraph Connect or external OpenID Connect providers such as Keycloak | OpenID Connect with Keycloak or the embedded LibreGraph Connect provider; confirm SAML support |
| Client support | ownCloud web, Android, iOS and desktop clients over WebDAV and CS3 APIs | Confirm the supported client list and sync protocols with OpenCloud GmbH |
| WOPI office integration | Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server via WOPI | Confirm WOPI support and which office servers are certified or tested |
| Kubernetes packaging | Kubernetes-ready with Helm charts | Confirm whether official Helm charts or operators are maintained |
| Latest release cited | v8.2.1 (October 2, 2026); v9.0.0-rc.1 (October 12, 2026) | v8.1.0 (October 5, 2026) |
| Paid support | Confirm the support tiers and scope with ownCloud and Kiteworks | Paid builds with support and professional services from OpenCloud GmbH |
What is free, what is paid and what each license means
ownCloud Infinite Scale (oCIS) is a separate Apache-2.0 platform written in Go, distinct from the AGPL classic ownCloud Server. The source is free to use, modify and redistribute under Apache-2.0 terms. Commercial support comes from Kiteworks, which ownCloud GmbH joined in 2023, and the announcement said ownCloud's open-source position would stay the same. The license itself does not include support, so the paid relationship is a separate contract.
- License grant: Apache-2.0 allows use, modification and redistribution in source or binary form, including inside proprietary products, as long as license and notice requirements are kept.
- Patent terms: The license includes an express patent grant from contributors that ends if you bring a patent claim against the licensed work.
- No copyleft: Apache-2.0 does not require you to publish your own modifications or the rest of your product.
- Support boundary: The open-source license includes no support, warranty or indemnity. Kiteworks support terms must be read separately.
- Release lines: v8.2.1 (October 2, 2026) and v9.0.0-rc.1 (October 12, 2026) are the current reference points for planning upgrades.
Ask Kiteworks which oCIS release lines it supports, for how long, and whether security fixes reach customers on older versions.
OpenCloud is a fork of oCIS whose former developers continue the code at OpenCloud GmbH, founded under the umbrella of the Heinlein Group. The OpenCloud community page says the project is published under Apache 2.0 and AGPL-3.0, and the source is free to download and use. OpenCloud GmbH sells paid builds for environments that need support and professional services. The paid offering is a service and build layer on top of the public source, so the license questions apply to both.
- Dual licensing: The community page lists two licenses, so confirm which license applies to each repository and component before you change code.
- AGPL network clause: If you modify AGPL-licensed components and users interact with them over a network, you must offer those users the corresponding source.
- Server codebase: The OpenCloud server is a Go codebase under Apache 2.0 that stores data in the filesystem and uses no database.
- Paid builds: Ask whether the paid build contains code, patches or configuration that are not in the public repository.
- Release line: v8.1.0 was published on October 5, 2026, so check which release your support contract covers.
Ask OpenCloud GmbH which build you would receive, how it differs from the public source, and how it handles modified AGPL components in your deployment.
Both projects use permissive or network-copyleft terms, so the practical question is how you plan to use the software. Internal use, hosting for customers and shipping a product to third parties each trigger different obligations. The same modification can be private under one arrangement and require a source offer under another. Map your intended use to each license before the design is fixed, because changing the model later can be costly.
- Internal use: Both licenses allow you to run and modify the software for your own staff without publishing your changes.
- Hosted service for customers: Apache-2.0 has no source offer trigger for hosting. AGPL does when a modified version is used over a network by others.
- Distributed binaries: Shipping a modified appliance or image to customers requires keeping license and notice files and, for AGPL code, providing source.
- Trademarks: Neither license grants rights to the ownCloud or OpenCloud names or logos. Check each project's trademark policy before rebranding a deployment.
- Contributor terms: Check whether contribution terms ask for copyright assignment or relicensing rights before you upstream fixes.
Have counsel record how you intend to use the software, then confirm the license of each component you will modify or distribute.
A support contract defines what you actually receive beyond the license. Paid support is a separate purchase, and its scope is set by the contract, not by the open-source code. Neither vendor's public materials in this comparison provide support tiers, prices or response commitments, so every term below must come from the signed agreement. Get the answers in writing before you commit.
- Covered versions: Name the release lines covered, the start and end dates of support, and what happens when a line reaches end of support.
- Response commitments: Ask for severity definitions and response targets in the contract. Do not rely on verbal assurances or sales summaries.
- Security patch delivery: Confirm how fixes are released, whether they reach supported older lines, and how you receive advisories.
- Professional services: Clarify what is included, such as upgrades, migration assistance, integration with your identity provider or storage backend, and who performs the work.
- Contracting party: Confirm whether Kiteworks, OpenCloud GmbH or a reseller is the counterparty, and what warranty and indemnity language applies.
Request a written scope, deliverables and terms for each vendor, and compare them line by line before you choose.
Governance questions buyers should ask before choosing
The most important question for a CISO or procurement lead is who controls the direction of each platform, and the supplied facts answer only part of it. ownCloud GmbH announced on November 21, 2023 that it was becoming part of Kiteworks and said ownCloud's open-source position would remain the same, with a Kiteworks Open Source Program Office operating under the ownCloud brand (ownCloud becomes part of Kiteworks). Ask Kiteworks and ownCloud in writing who sets the oCIS roadmap, who approves changes to the owncloud/ocis repository, and whether the Apache-2.0 license and the release cadence would change under a future owner. For OpenCloud, ask OpenCloud GmbH who decides features, who maintains the opencloud-eu/opencloud repository, and how much of its roadmap depends on the Heinlein Group. Get the answers as contractual commitments or governance documents, not marketing statements.
Next, establish who holds the trademarks, the repositories and the right to publish builds. The OpenCloud community page says the project is based on a fork of oCIS, so ask which code, names and logos OpenCloud controls outright, and whether the fork can continue if upstream changes direction. On the ownCloud side, ask whether the Kiteworks-era trademark policy would limit redistribution or support by third parties. Ask both vendors how security fixes reach community builds compared with paid builds. OpenCloud says it offers paid builds with support, so confirm whether a vulnerability fix lands in the public repository at the same time as the paid build, and how long each takes. Request the disclosure policy and the target dates they commit to in writing.
Finally, plan for a future ownership change. Ask what happens to the release lines if a vendor is sold again, including whether the current license, the paid support contract and the update channel survive a change of control. Ask how the Heinlein Group relationship is structured: whether OpenCloud GmbH is a subsidiary, what legal entity holds the code and the support contract, and what happens if that relationship changes. Write exit terms into the contract, such as source escrow, the right to keep a pinned version under its existing license and a defined notice period. Because both products are self-hosted in your own infrastructure, your data stays in your environment, so the main risk is losing a supported update path rather than losing access to your files.
Moving data and users between oCIS and OpenCloud
This sequence gives you a tested path for moving files, users and sharing state between oCIS and OpenCloud, with a checkpoint at each stage so you know whether the move is safe to cut over.
Inventory users, groups, shares and storage layout
Your identity or platform team lists every user, group membership, share and external link, plus the storage layout behind them: spaces or folders, file sizes, versions and any trash or retention rules. Record which storage backend the source uses (S3, NFS or PosixFS for oCIS) and where each file lives on it. Finish when you have a written inventory that another engineer could use to reconcile the target against the source without asking questions. Confirm with each vendor which metadata their current release exports and which it does not.
Confirm identity mapping through OpenID Connect
Identity engineers map each source account to a target account using the OpenID Connect claims both platforms read, whether the identity provider is the embedded LibreGraph Connect provider or an external one such as Keycloak. Document the subject identifier, username, email and group claims for every user, and note any account that will not match one to one. Done when a test user can sign in to a target instance through the same provider and the claim values match the inventory. Ask both vendors how they handle subject identifiers that changed when the provider was set up.
Test the storage backend on a copy
Restore a copy of a representative sample of the source data into a non-production target that uses the same storage type you plan to run in production. Check that directory structure, file names, timestamps and checksums survive the copy, and that the target indexes the files without manual repair. Record any file the target rejects or renames. This step produces a pass or fail result for each storage type you intend to use. If the layouts differ between the two platforms, record that now, because it determines whether files can move directly or need a conversion step.
Move data in a controlled window
Copy the full dataset from source to target using the method your storage layout supports, and keep a frozen source snapshot for rollback. Run the copy in passes so that changes made during the initial transfer can be captured in a final delta pass. Compare file counts, sizes and checksums against the inventory and record any mismatch. The output is a signed-off data reconciliation report that lists every exception and its disposition. Confirm the approach for shares and version history with each vendor before the first pass, since those are the parts most likely to need rebuilding.
Rebuild sharing metadata and office connector settings
Recreate shares, external links and permissions that did not transfer, and reconfigure the WOPI connection to your office editor, such as Collabora Online or ONLYOFFICE Docs, against the target's URL and trust settings. Test that a document opens, saves and shows the correct co-author state from each office connector. Done when every share in the inventory has a documented status (migrated, rebuilt or retired) and each office integration passes a save test. Expect these items to need manual work, and confirm the exact steps with each vendor's documentation.
Validate sync clients and office integration
Point a pilot group of desktop, Android and iOS clients at the target, using the client builds each vendor supports, and confirm sign-in, initial sync, conflict handling and the file-lock behavior your users rely on. Repeat the office edit test with a pilot group across the common document types you use. Record every client version and connector version tested. This step is complete when the pilot group signs off on a written checklist and the platform team has a known list of client versions to deploy. Verify client compatibility with each vendor before you commit to a release line.
Cut over and keep the source for rollback
Freeze writes on the source, run the final delta copy, repoint DNS or the client configuration to the target, and announce the change to users with a support path. Keep the source instance read-only and intact for a rollback period that your change board sets. The result is a documented cutover record with the time of the freeze, the delta counts and the first successful client sign-ins. Once the rollback window closes, retire the source only after the reconciliation report and the sharing inventory are both archived.
What implementing each platform involves and where projects run long
Implementation effort for oCIS and OpenCloud is less about the install itself and more about the decisions that follow it. Both are Go services that can start with no external database, but a production build still needs the identity, storage and office decisions made before anyone runs a rollout. For oCIS, the quickstart needs no external database and no external identity provider, yet the embedded LibreGraph Connect provider is a different choice from a Keycloak realm you already operate. OpenCloud makes the same OpenID Connect choice, and it stores data in the filesystem with no database. Size the storage tier against the backend you pick: the oCIS documentation lists S3, NFS and PosixFS, and each one carries different performance and failure characteristics. Confirm the sizing numbers with each vendor's current documentation and your own load tests rather than assuming a shared baseline.
The usual delay points are identity claim mapping, storage performance testing and client rollout. Claim mapping stalls when group and role claims from Keycloak or another OpenID Connect provider do not match the roles the platform expects, so test a sample of real accounts before cutover. Storage performance testing often runs long because sync-heavy workloads expose latency that a lab test hides, and NFS or PosixFS behavior under concurrent writes deserves its own test plan. Client rollout is slow when desktop, Android and iOS clients must reach many users with matching server versions. Office integration through WOPI with Collabora Online or ONLYOFFICE Docs adds a separate service to configure, certify and monitor. Upgrade planning must also account for release lines: oCIS v9.0.0-rc.1 is a release candidate, and OpenCloud's release cadence differs, so write down which line you will run and when you will move. Kubernetes packaging through Helm charts reduces manual work but moves the same decisions into values files that need review.
DeployOpen plans, implements and hardens self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any implementation partner, including DeployOpen, to state in writing which identity integration, storage backend, office connector, client rollout and upgrade path are inside the scope, and which are assumed from your side. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the environment assumptions that drive effort, such as user count, storage volume, identity provider version and the number of client platforms, and for the test evidence that will close each delay point before go-live.
What drives the running cost of each platform
Running cost for either platform is mostly people time, not licenses, since both sources are open source. The cards below separate what you pay for once from what recurs, and name who is paid for each part, so you can turn the comparison into a written quote and an internal budget.
Infrastructure footprint at your scale
Both platforms are Go services, but the footprint you need depends on storage backend, replicas and whether you run Kubernetes. oCIS can run as a single binary and offers S3, NFS and PosixFS backends, so storage choice shifts cost between object storage fees and local disk. OpenCloud stores all data in the filesystem with no database. Ask each vendor or partner for a sizing baseline for your user count, file volume and availability target, and model storage growth over the contract term.
Operator skills for Go on Kubernetes
Running a Go binary on bare metal needs a systemd or container runbook, a reverse proxy and certificate handling. Running it on Kubernetes adds Helm chart management, ingress, persistent volumes and upgrade rollouts. Most of this effort is a recurring salary or contractor cost, and it is hard to estimate without knowing your team. Check whether your platform engineers already run Helm and object storage in production, and whether the skill set exists in-house before you assume a lower operating cost.
Paid support contract scope
Both sources are open source, so support is a separate purchase from the software. OpenCloud GmbH offers paid builds for environments that need support and professional services. Confirm in writing whether the contract covers incident response hours, security patch timing, named escalation contacts, and help with your identity and storage integrations. Support is recurring, so compare renewal terms and what happens if you drop the contract and keep running the same release.
Upgrade effort across release lines
Upgrades recur for the life of the deployment, and the release cadence is not the same on both sides. oCIS published v8.2.1 on October 2, 2026, while v9.0.0-rc.1 followed on October 12, 2026, so a major move is already in view. OpenCloud published v8.1.0 on October 5, 2026. Budget testing time for each major line, configuration key changes, and storage migrations. Ask each provider how long they support a line and how they document breaking changes.
Identity provider if none exists
Both platforms can use an embedded identity provider, LibreGraph Connect in both cases, or an external OpenID Connect provider such as Keycloak. If you have no identity provider, the embedded option avoids a separate system but leaves you running an authentication service that your security team must patch, monitor and back up. If you already run one, the cost is integration and claim mapping, not a new product. Confirm which option your identity team will support over the life of the platform.
One-time migration and onboarding
Initial setup, storage design, identity integration, client rollout and any data migration are one-time costs, usually delivered as a fixed-scope project with agreed deliverables. Ask for the scope in writing: which clients, which storage backend, how many environments, whether backup and restore tests are included, and how user data moves from an existing platform. Keep these costs separate from recurring support so you can see what you pay again each year.
Questions buyers ask before choosing oCIS or OpenCloud
How much effort does a self-hosted oCIS or OpenCloud deployment take?
Effort depends less on the product than on your storage, identity and office integration choices. Both platforms ship as a Go codebase that can start with a single binary, and oCIS documents a quickstart with no external database and no external identity provider. That quickstart suits evaluation, not production. Production effort grows with the storage backend you pick (oCIS documents S3, NFS and PosixFS), the identity provider you connect over OpenID Connect, the reverse proxy and TLS setup, backups of the filesystem data, and any Collabora Online, ONLYOFFICE Docs or Microsoft Office Online Server integration over WOPI. Ask each vendor for its supported production reference architecture and confirm which storage backends and identity providers it supports for your environment.
Can an internal team run oCIS or OpenCloud without outside help?
A team with Linux, container and identity skills can run either platform, but the answer depends on how much of the stack it owns. The internal team needs to operate the chosen storage backend, the identity integration, upgrades between release lines and backups, and to track security fixes in the component it depends on. oCIS is Kubernetes-ready with Helm charts, which helps teams already running Kubernetes and adds effort for teams that do not. If the team lacks depth in those areas, a fixed-scope engagement can plan, implement, document and handover the platform inside your own infrastructure, with ongoing support available as a retainer.
What does a paid support contract from each vendor actually cover?
The published material does not give a full list of paid support terms for either product, so read each contract rather than assuming coverage. OpenCloud GmbH states that it offers paid builds for environments that need support and professional services, while the source remains free to download and use. For oCIS, ownCloud GmbH now operates within Kiteworks, and its commercial terms are set by that company. Ask each vendor for written answers on response times, supported versions, which release lines receive security fixes, whether patches reach the open-source tree, and whether professional services are included. Also ask who is contractually responsible for the ownership and roadmap of the codebase.
How long does a migration to oCIS or OpenCloud usually take?
No supplied source gives a migration duration for either direction, so treat any number from a vendor or a consultant as an estimate to test. The main drivers are the volume of files and versions, the number of users and groups to map, how permissions and shares translate, the identity provider cutover, client reconfiguration, and the size of the validation window. Ask for a written migration plan that states the data inventory method, a pilot on a representative subset, rollback steps, and the criteria for cutover. Fixed-scope planning can set the timeline in writing before work starts.
Is moving between oCIS and OpenCloud practical?
Moving between them is more practical than moving to a different architecture, because both descend from the same oCIS codebase and both are Go platforms that use OpenID Connect and filesystem-oriented storage. The public material does not, however, document a supported in-place migration path, and the two projects have diverged in release lines, so compatibility of data layouts, configuration keys and client behavior must be verified on your own version pair. Before you choose, ask both vendors whether they publish migration tooling, which versions are compatible, and how they handle client and API differences. Plan for a pilot copy of production data before committing to either path.
Which governance questions should buyers ask before choosing oCIS or OpenCloud?
Start with ownership and direction, because both platforms trace back to the same origin. ownCloud GmbH announced on November 21, 2023 that it was becoming part of Kiteworks and said its open-source position would remain the same, with a Kiteworks Open Source Program Office operating under the ownCloud brand. OpenCloud was founded under the Heinlein Group, and its community page says the project is a fork of oCIS whose components were co-developed by CERN developers and others. Ask who holds commit rights, how decisions are made, whether contributor agreements apply, what license changes would require, and how a fork would be funded if the sponsor changed direction. Record the answers in your vendor file.
Which release lines and versions should a buyer check before committing?
Check the release line you would run and its support window, not only the newest tag. The sources show oCIS v8.2.1 published on October 2, 2026 and v9.0.0-rc.1 on October 12, 2026, which is a release candidate and not a production build. OpenCloud v8.1.0 was published on October 5, 2026. Confirm the support policy for each line, how security patches are backported, and the upgrade path between major versions. Ask each vendor to name the version you would deploy, the date its support ends, and the tested combination of client, storage backend and identity provider.
What should an evaluation of oCIS or OpenCloud include before a purchase?
A useful evaluation runs both platforms against your real workload, with a bounded scope and written success criteria. Include a test of your storage backend, the identity provider you will keep, your office integration over WOPI, desktop and mobile client behavior, backup and restore timing, and a failed-upgrade rollback. Record the effort in hours by role, which gives you a basis for the quote. Under a fixed-scope agreement, deliverables and timelines are agreed in writing before work starts, so the evaluation output can feed the decision and the implementation plan together.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ownCloud Infinite Scale vs OpenCloud, we start by confirming which licensing, identity and storage questions decide the choice for your team, then carry that decision through a written scope.
How we scope
- We confirm your licensing, support and governance requirements before comparing either platform in your environment.
- The written scope lists the platform, identity integration, storage backend and office integration covered by the engagement.
- Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform in your infrastructure, with storage backends and identity provider configured to your specification.
- We connect office editing and client access, then test sync, sharing and permission behavior against your user groups.
- Where you are moving from another file platform, we plan and test the data and user migration path before cutover.
How we hand over
- You receive architecture, configuration and runbook documentation covering the deployed platform and its integrations.
- Backup and restore procedures are documented and exercised so your operations team can run them without us.
- We document upgrade steps for the release line you choose, so your team can plan future version changes with confidence.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers cover the platform you run, so support terms follow the scope agreed for your environment.
- Confirm with us which vendor support, if any, you need alongside DeployOpen support before you sign a scope.
