Which ownCloud line fits your team: Classic or Infinite Scale
Choose ownCloud Classic 11 if you want the AGPL PHP server running in Docker, and oCIS if you want a Go single binary with S3, NFS or PosixFS storage that deploys with Kubernetes and Helm. Classic 11 is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images, so it suits a team that wants a packaged container stack and is comfortable operating that image lifecycle. oCIS, published under Apache-2.0, suits a team that wants to pick its own object storage or filesystem backend, run microservices on Kubernetes, or connect to an existing OpenID Connect provider such as Keycloak instead of the embedded identity provider.
Neither line is a drop-in upgrade of the other. They use different code bases, different licenses, different storage models and different identity paths, so moving users means a data migration and a change of client and integration configuration, not an in-place upgrade. Before you commit, confirm with ownCloud which Classic release line your compliance or support contract covers, check that your office integration (for example Collabora Online, ONLYOFFICE Docs or Microsoft Office Online Server over WOPI) is supported on the line you pick, and test a sample of your users and shares on a staging copy. Those checks decide the choice more often than feature lists do.
If your existing estate is on Classic and your main need is stability with a familiar admin model, staying on Classic is the lower-change option. If you are starting fresh, or your platform team already runs Kubernetes and wants to manage file storage as a service, oCIS is the stronger starting point, provided your team can own the Go services and the storage backend. Ask DeployOpen to scope the migration path in writing before you set a date, because the data move and client rollout effort depends on your user count, storage size and integrations.
How the two lines fit different team scenarios
If your team already runs ownCloud Classic, the default path is usually to stay on Classic while you plan the move, because your users, apps, sync clients and operating routines already work. Classic 11 is the line that matters here, and it is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. A team that keeps Classic accepts that image-based operation is its only supported model. Moving to oCIS means changing the storage model, identity setup and deployment tooling, so the cost is a migration project, not an upgrade.
- Staying on Classic: Your existing apps, database and maintenance runbooks carry over unchanged, and the change window stays small.
- Moving to oCIS: You gain the Go single binary, S3, NFS or PosixFS storage and Helm charts, but you rebuild your storage and identity assumptions.
- Image-managed operation: Classic 11 bundles the web server, PHP and database inside ownCloud's images, so patching follows image updates.
- Version lines: ownCloud Server 10.16.6 and 11.0.0 both appear in the researched release record, so confirm which line your support terms cover before you plan.
- Migration scope: Ask for a written inventory of apps, users, shares and storage before anyone estimates the effort.
Before you decide, confirm with ownCloud which Classic line your contract and support window cover and whether a migration path to oCIS is documented for your versions.
A team starting a new on-premises file share with no existing ownCloud footprint has the most freedom. The question is which operating model it wants to own. oCIS runs as a single binary of microservices, needs no external database and no external identity provider for basic deployments, and includes an embedded LibreGraph Connect identity provider or connects to external OpenID Connect providers such as Keycloak. Classic 11 is the better fit when the team wants the familiar PHP server and is comfortable running Docker as its only deployment method. Choose oCIS when the team wants a small, self-contained service with fewer moving parts, and accept that it is a newer architecture to learn.
- Simple start: oCIS runs without an external database or identity provider, which shortens the first build.
- Identity choice: Use the embedded identity provider for a small group, or connect to an existing OpenID Connect provider as your directory grows.
- Storage choice: S3, NFS and PosixFS backends let you match storage to where your files already live.
- Docker-only Classic: If your platform standard is containers, Classic 11 fits, but the image model is fixed.
- Client and office support: oCIS works with ownCloud's web, Android, iOS and desktop clients and supports WOPI-based editing through Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server.
Ask each vendor which identity provider and storage combinations your user count and compliance scope require, and test them with real sync clients before you commit.
A platform team that already runs Kubernetes and manages clusters through Helm will find oCIS the more natural fit. oCIS is Kubernetes-ready and ships with Helm charts, so deployment, upgrades and configuration can sit in the same pipelines as other services. Classic 11 can run in containers, but it is deployed only with Docker through ownCloud's images, so the platform team would be operating a monolithic PHP stack inside a cluster rather than using the chart-based model. The trade-off is that the team takes on the microservice model, its observability needs and its storage design. Teams without Kubernetes experience should not choose oCIS for this reason alone.
- Helm-based deployment: oCIS charts let you fit file sync into existing GitOps and release processes.
- Storage on cluster infrastructure: S3 or NFS backends can use storage services your platform already operates.
- Operational surface: oCIS splits functionality into microservices, so expect more components to monitor and upgrade.
- Classic in a cluster: Running Classic 11 on Kubernetes still means working around the Docker-only image model.
- Skills requirement: Your team needs Kubernetes, Helm and identity configuration skills to run oCIS well.
Confirm the chart version, supported Kubernetes versions and storage backend behavior in your own cluster before you adopt either line for production.
Sites with strict network isolation or very limited hardware need a different calculation. oCIS is a single binary that the researched material describes as running from a Raspberry Pi to Kubernetes clusters, and it needs no external database for basic deployments. That makes it a candidate for a small or disconnected footprint, as long as the team can move the binary, its dependencies and its updates across the boundary. Classic 11 requires Docker and a set of images managed by ownCloud, which brings its own transfer and update process into the air gap. A team that cannot run Docker on its hosts should treat Classic as ruled out.
- Small footprint: oCIS as a single binary is the lighter option for limited hardware, if your site fits its storage and identity choices.
- Docker requirement: Classic 11 needs Docker and ownCloud's images, so you must mirror and verify every image you import.
- Update transfer: Both lines require a repeatable way to bring signed releases into isolated networks. Confirm how each vendor delivers updates to offline sites.
- Office integration: Collaborative editing through WOPI needs an office server inside the same isolated network.
- Testing: Run a full install and restore inside the isolated environment before you rely on it.
Check the hardware, storage and update requirements in the vendor documentation for your exact version, because a single-binary install is not the same as a supported production topology.
Why the PHP server and the Go binary behave differently in production
Classic 11 and oCIS fail in different places, so the production checklist differs. ownCloud Classic 11 is deployed only with Docker, and the web server, PHP runtime and database are managed inside ownCloud's images. That shifts much of the runtime decision to ownCloud's packaging, but it also means your team inherits the container lifecycle, volume layout and image update cadence. oCIS, by contrast, is a separate Apache-2.0 platform written in Go that the README describes as a single binary of microservices. For basic deployments it needs no external database and no external identity provider, so a pilot can start with far fewer moving parts.
The README describes oCIS as running from a Raspberry Pi to Kubernetes clusters. That range matters for footprint, but it does not mean a Raspberry Pi suits a regulated workload. Treat it as evidence that the binary is light enough to run small and scale out, and size production hosts with ownCloud's own requirements and your load tests. For Classic, confirm which PHP and database versions ownCloud's Classic 11 images ship and whether your standards allow them. Check the ownCloud Server 11.0 system requirements against your approved database and container platform before you commit.
Before choosing, write down your own database and runtime standards. Ask whether your team can accept an embedded or vendor-managed database inside an image, who patches PHP and the database between ownCloud releases, and whether a Kubernetes cluster with Helm charts is already governed by your change process. If the answer is that every database must be an externally managed, centrally backed-up service, oCIS's no-external-database default is a starting point you must replace with your own configuration. Confirm that choice with the vendor and your own platform team before you rely on it.
Storage, identity and office integration side by side
Storage, identity and office editing are where ownCloud Classic and Infinite Scale differ most in day-to-day operation. The cards below mark what the documentation supports for oCIS and what your team must test against its own SSO directory, storage estate and office servers before committing to either line.
Storage backend choice
The oCIS documentation lists S3, NFS and PosixFS as storage backends, so the backend becomes a platform decision rather than a file server detail. Object storage, network file shares and POSIX volumes each change how backups, quotas, encryption at rest and disaster recovery are handled. Confirm which backend your data residency and backup tooling support, and test restore time on a realistic data set. Classic 11 uses the storage layout described in its own documentation, which should be compared on the same workload.
Embedded or external identity provider
oCIS can run with its embedded LibreGraph Connect identity provider or connect to an external OpenID Connect provider such as Keycloak. The embedded option is documented as sufficient for basic deployments, but most regulated teams will want users and MFA managed by the directory they already audit. Verify group claims, token lifetimes and how existing LDAP or SAML sources map to oCIS roles before go-live. Classic 11 identity options should be checked separately against the same requirements.
WebDAV and CS3 client support
oCIS works with ownCloud's web, Android, iOS and desktop clients over WebDAV and CS3 APIs. Any third-party tool, sync agent or scripted integration your organization relies on must be tested against that API surface, not assumed to work. Check client versions against the server line you plan to run, and confirm how sync conflicts and large file uploads behave on your network. Ask ownCloud which client builds it supports for each oCIS release.
WOPI office editors for oCIS
oCIS supports collaborative editing through Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server over WOPI. Each editor has its own license terms, hosting footprint and support model, so the choice affects cost and data flow. Test co-authoring, lock behavior and document conversion with the exact editor version and TLS setup you intend to run. Confirm which editor combinations ownCloud documents as tested for your oCIS version.
Office integration on Classic 11
Classic 11 is deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. That constraint narrows how you attach an external office editor and how you patch its components. Map your current office integration against the Classic 11 requirements and confirm which WOPI connectors are supported in the Docker deployment. Plan the image update cadence alongside your change process.
Feature and deployment differences between Classic 11 and oCIS
This table compares the two ownCloud product lines on language, deployment, storage, identity, Kubernetes and client support. Read each row as a fit question: a cell that says to confirm means the supplied research does not settle it, so check it with ownCloud before committing.
| Capability | ownCloud Classic 11 | ownCloud Infinite Scale (oCIS) |
|---|---|---|
| License | AGPL-3.0 (owncloud/core) | Apache-2.0 |
| Language and runtime | PHP server, delivered as ownCloud images | Single Go binary of microservices |
| Supported deployment methods | Docker only, with web server, PHP and database inside ownCloud's images | Single binary, Kubernetes with Helm charts; confirm other container options with ownCloud |
| Storage backends | Confirm supported backends for your version with ownCloud | S3, NFS and PosixFS |
| Identity options | Confirm integration options for Classic 11 with ownCloud | Embedded LibreGraph Connect or external OpenID Connect providers such as Keycloak |
| Database requirement | Database managed inside Classic 11 images; confirm external database options | No external database needed for basic deployments |
| Kubernetes and Helm support | Not listed as a supported path in the supplied sources; confirm with ownCloud | Kubernetes-ready with Helm charts |
| Client protocols | Confirm client and protocol support with ownCloud | WebDAV and CS3 APIs with ownCloud web, Android, iOS and desktop clients |
| Office integration via WOPI | Confirm with ownCloud for your version | Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server |
What the AGPL and Apache-2.0 licenses mean for each line
The classic ownCloud Server (owncloud/core) is licensed under AGPL-3.0, and oCIS is licensed under Apache-2.0. In plain terms, the AGPL is a strong copyleft license: if you modify the server and make it available to users over a network, you must offer those users your modified source under the same terms. Apache-2.0 is permissive: you may modify and redistribute oCIS, including inside proprietary products, as long as you keep the license and notices. For a bank or public body that runs the software unmodified inside its own infrastructure, the AGPL obligations are usually light, but any custom PHP changes to Classic need a legal review before they go into production. Ask your counsel to confirm how the terms apply to your specific use, since this is not legal advice.
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. Read the ownCloud announcement and keep a copy in your vendor file. A statement of intent is not a contract, so ask the vendor in writing whether the license of each line could change in future releases, and what would happen to your deployment if it did.
Licensing does not settle who you pay for. Open-source code is free to use, but support, subscriptions, security hotfix commitments and upgrade assistance are sold separately, and no edition price list has been supplied for either line. Ask ownCloud for the paid support and subscription terms for Classic and for oCIS separately, including response windows, which versions receive security fixes, how long each release line is maintained, and whether a subscription covers your Docker images or your Helm chart deployment. Also ask whether a partner such as DeployOpen, which is not an ownCloud partner unless stated otherwise, can operate either line under a separate support arrangement.
License, support and update terms for each line
Both ownCloud lines are open source, but they ship on different license, release and support tracks. The cards below separate what the public sources confirm from what you must confirm with the vendor before you commit to either line.
Classic 11 license and release track
The classic ownCloud Server (owncloud/core) is licensed under AGPL-3.0. Version 11.0.0 was published on July 30, 2026, and the 10.16.6 maintenance release followed on October 6, 2026, so the 10.x line is still receiving releases alongside 11. Check which line you will run and how long you expect to stay on it, because the 11 line is deployed only with Docker.
oCIS license and release track
ownCloud Infinite Scale is a separate platform licensed under Apache-2.0 and written in Go. It is not a newer build of the classic server, so the license terms and release cadence differ from Classic. Plan your upgrade path with the oCIS release notes in view, and treat any move between the two lines as a migration project rather than a version bump.
2026 release dates for each line
Classic 11.0.0 shipped on July 30, 2026. The oCIS v8.2.1 release followed on October 2, 2026. Dates alone do not show support duration, so ask ownCloud for the end-of-life or maintenance policy for each line and for the versions your deployment will run.
Vendor support availability
ownCloud GmbH became part of Kiteworks, and the company said the open-source position would stay the same, with a Kiteworks Open Source Program Office operating under the ownCloud brand. Confirm in writing which support tiers cover Classic and oCIS, which versions are covered, and who answers for each product. Do not assume that support on one line applies to the other.
The 9.0.0-rc.1 pre-release status
oCIS v9.0.0-rc.1 was published on October 12, 2026 as a release candidate. Release candidates are pre-release builds, so do not place them in production or base a long-term plan on them. Test against the candidate only in a non-production environment, and wait for a stable release and its documentation before you upgrade a live system.
Where to confirm paid support terms
The public sources reviewed here do not state support windows, service levels or response times for either line. Request a written support schedule from ownCloud, covering covered versions, response targets, patch delivery and any Kiteworks-side terms. Ask DeployOpen to reflect those terms in the fixed-scope plan so the upgrade and support work is written down before it starts.
What drives the cost of running each line
This table lists the cost components of running ownCloud Classic 11 and ownCloud Infinite Scale, who is paid for each one, and whether it is one-time or recurring. No prices are published in the supplied facts, so use the rows to build the questions you ask in a written scope and quote. Read the cells as the work each line asks for, not as a cost ranking.
| Cost component | Ownership Classic 11 | Ownership oCIS |
|---|---|---|
| Infrastructure (hosts, containers, cloud accounts) | Recurring. Docker hosts sized for the ownCloud images, paid to your cloud or data center provider. | Recurring. Sized for Go microservices, which can run from small hosts to Kubernetes clusters, paid to your provider. |
| Database and runtime operations | Recurring. Web server, PHP runtime and database are managed inside ownCloud's images, so patching depends on image updates. | Recurring. No external database is needed for a basic deployment, but production setups usually add one or more managed services. |
| Storage | Recurring. Grows with user data on the storage the Docker deployment mounts, plus backup copies. | Recurring. Depends on the chosen S3, NFS or PosixFS backend, each with its own operating and backup model. |
| Identity integration | One-time to set up, then recurring to maintain. Confirm LDAP or SAML options with ownCloud for your directory. | One-time to set up, then recurring. Embedded LibreGraph Connect works for basic cases, while external OpenID Connect providers such as Keycloak are a separate system to run. |
| Kubernetes platform | Not required for Classic 11, which is deployed only with Docker. | Recurring if you run Kubernetes. Helm charts are provided, but the cluster, its upgrades and its staff time are your cost. |
| Support subscription | Recurring if purchased from ownCloud. Confirm tiers, response times and coverage in writing before you assume them. | Recurring if purchased from ownCloud. Confirm tiers and coverage for oCIS specifically, since the release lines differ. |
| Implementation services | One-time, fixed-scope work such as installation, migration and hardening. Ask for deliverables and timelines in writing. | One-time, fixed-scope work covering architecture, storage backend choice, identity setup and cluster design. Ask for each in the written scope. |
What moving from Classic to oCIS involves
The sequence turns a Classic deployment into a tested oCIS environment with users, files, shares and office editing verified before any production users move. It is a re-platforming project, not a version upgrade, so each step ends with a check the team can sign off.
Inventory users, files, shares and apps
Start by listing what the Classic server actually holds: user accounts and groups, the size and structure of stored files, external and public shares, enabled apps and any custom code or themes. Whoever administers the Classic server should produce this inventory, and the security owner should review it for shares that expose sensitive data. The step is done when the team has a written inventory that another engineer could use to rebuild the environment without access to the old server.
Map identity and storage to oCIS options
Compare how Classic authenticates users and where it keeps data with what oCIS offers. oCIS can run with its embedded LibreGraph Connect identity provider or connect to an external OpenID Connect provider such as Keycloak, and its documentation lists S3, NFS and PosixFS storage backends. Record each Classic app or integration that has no clear oCIS counterpart, because those become decisions rather than assumptions. The output is a mapping table covering identity, storage, clients and office integration, reviewed by the identity owner and the platform team.
Stand up oCIS in a test environment
Build a non-production oCIS deployment that mirrors the target design, using the documented deployment method that fits your infrastructure, including Helm charts if you run Kubernetes. Connect it to the chosen identity provider and storage backend in the same way production will use them. The step is complete when a test user can sign in, upload and share a file, and the logs and backups behave as the team expects. Confirm the supported version and deployment steps against the oCIS documentation before you begin.
Migrate data and permissions
Move file content and map permissions and shares from the inventory into the test oCIS environment. No supplied fact documents a supported in-place migration path between Classic and oCIS, so confirm with ownCloud whether a migration tool exists, what it maps, and what it does not carry over, such as certain share types or app data. Run a sample migration first and compare file counts, checksums and sharing results against the source. The step is done when a defined sample of users and folders reproduces with matching content and access rights.
Test clients and office editing
Validate every client your users rely on: web, desktop, Android and iOS, and any sync scripts or WebDAV integrations. Then test document editing through the office suite you plan to use, since oCIS supports Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server via WOPI. Use a pilot group of real but consenting users for this check and log every failure. The step is complete when the pilot group signs off on sync, sharing, editing and mobile access, and open issues have owners.
Cut over to oCIS
Schedule the production switch with a freeze on changes to Classic, a final incremental data copy, and a rollback plan that keeps the Classic server available until the new platform is confirmed. Update DNS, client configuration and any integrations to point at oCIS. The step is done when production users sign in, the final data copy matches the source on spot checks, and monitoring shows normal behavior. Agree the cutover window and rollback criteria in writing with the business owners beforehand.
Retire Classic and document the new baseline
After a hold period agreed in advance, decommission the Classic server, revoke its credentials, and securely dispose of retained copies that policy does not require. Update backup, patching and monitoring runbooks for oCIS, and record the final configuration, identity mapping and known gaps. The step is complete when the Classic environment is removed, the backup job for oCIS has been restored successfully in a test, and the documentation is owned by a named team.
Questions buyers ask before choosing or moving between ownCloud lines
Can a Classic ownCloud deployment move to oCIS without rebuilding it?
Confirm this with ownCloud before planning, because the supplied facts do not describe a supported in-place conversion. The two lines are separate products. Classic 11 is the AGPL PHP server, deployed only with Docker, with the web server, PHP runtime and database managed inside ownCloud's images. oCIS is an Apache-2.0 Go binary that supports S3, NFS or PosixFS storage, an embedded identity provider or external OpenID Connect providers, and Helm charts for Kubernetes. Because storage, identity and the runtime all differ, plan for a re-platforming project. Ask the vendor for the supported migration path, the export format for user data and metadata, and which Classic versions the path covers.
How long does a move from ownCloud Classic to oCIS take?
No supplied fact gives a duration for this move, so treat any number as something to get in writing at quote stage rather than assume. The main drivers are the number of users and the volume of stored files, the storage backend you choose for oCIS, whether your identity source changes, how many office integrations and custom apps must be reconnected, and how long your cutover window is. Each driver adds test cycles and validation work, and the migration path your vendor supports sets the baseline. Ask for a phased plan with a pilot group, a rollback procedure and explicit acceptance criteria for each phase before you commit to a date.
Is ownCloud Infinite Scale 9.0 ready for production use?
Treat oCIS 9.0 as a release candidate until ownCloud confirms a stable release and its support terms. The supplied facts show v9.0.0-rc.1 published on October 12, 2026, and the latest stable version listed is v8.2.1, published on October 2, 2026. Check the oCIS releases page for the final 9.0 release, its upgrade notes and the support window for each line. Then run your own pilot on the exact version you plan to deploy, including storage backend behavior, backups, restores, client sync and office editing through WOPI. Production readiness is a decision you base on your tests and the vendor's written support commitments.
What does our team have to run itself on oCIS?
The oCIS README says basic deployments need no external database and no external identity provider, but a production service still involves several components your team must operate:
- The chosen storage backend (S3, NFS or PosixFS), including capacity, performance and backup design
- The identity layer, whether the embedded identity provider or an external OpenID Connect provider such as Keycloak
- Kubernetes and Helm chart operation if you deploy on a cluster, including upgrades
- Office integration through WOPI with Collabora Online, ONLYOFFICE Docs or Microsoft Office Online Server
- TLS, monitoring, logging, patching and client rollout for the web, Android, iOS and desktop apps
The oCIS documentation describes each option. Compare that list with what your Classic team runs today, especially the Docker host, database and PHP components that Classic 11 manages inside its images.
Can DeployOpen plan and carry out an ownCloud line migration?
DeployOpen plans, implements, customizes, integrates, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. DeployOpen does not publish a price list. Whether a migration between Classic and oCIS is in scope depends on the written scope for your environment. DeployOpen is not an official ownCloud partner, so confirm the supported path with the vendor as well. Ongoing upgrades and support are available as retainers.
What drives the effort of moving users between ownCloud lines?
Effort depends on how much of your environment changes, not only on the number of users. The largest factors are the storage backend and the amount of data to move, the identity source (embedded, LDAP-backed or external OpenID Connect), the number and type of client applications, office editing integrations, custom apps or scripts that call the old APIs, and any compliance evidence you must keep for the change. Each factor adds test cases, approval steps and user communication. One-time costs cover the planning, the migration run and validation. Recurring costs cover the new platform's operation and any support retainer. Ask for each cost line to be itemized in the quote.
Which ownCloud line fits a new deployment today?
Choose the line that matches your operating model, not the one you already know. Classic 11 suits teams that want the AGPL PHP server and are comfortable running it as a Docker deployment, with the web server, PHP runtime and database managed inside ownCloud's images. oCIS suits teams that want an Apache-2.0 Go service with choice of S3, NFS or PosixFS storage, embedded or external OpenID Connect identity and Helm-based Kubernetes deployment. Check the current release status and support terms for each before you decide. ownCloud GmbH's Kiteworks announcement says the open-source position would remain the same, so ask ownCloud to confirm the license and roadmap commitments for the line you pick.
How a scoped ownCloud evaluation starts
A scoped evaluation starts with a written decision question, not a product choice. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work begins. For this comparison, that means naming the decisions in advance: whether the target is Classic 11 under Docker or oCIS as a single binary, which storage backend (S3, NFS or PosixFS) the data must live on, and whether identity comes from an embedded provider or an existing OpenID Connect provider such as Keycloak.
Before scoping, the team should confirm the facts that drive the work inside its own environment. Ask which Kubernetes or container platform is in use, since oCIS ships with Helm charts and Classic 11 is deployed only with Docker, with its web server, PHP runtime and database managed inside ownCloud's images. Confirm the office editing requirement, because oCIS supports WOPI-based editing with Collabora Online, ONLYOFFICE Docs and Microsoft Office Online Server. Confirm the client platforms, the user count and any migration source. Also confirm the licensing and support position with ownCloud directly, since this page does not establish which paid subscription terms apply to either line.
DeployOpen does not publish a price list, and the company does not claim any ownCloud partner or reseller status. A quote follows from the written scope, so the reader should ask for a quote that itemizes the planning, implementation, integration, hardening, backup and documentation work separately, and states which items are one-time and which recur, such as ongoing support, upgrades or testing retainers. Ask for the assumptions behind each item, including the environment, the number of integrations and the migration approach, so that a change in scope shows up as a change in the written document rather than as a surprise.
How DeployOpen scopes, delivers and supports either ownCloud line
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For ownCloud, that means choosing the line that fits your storage, identity and deployment model, then delivering it in your cloud account, data center or air-gapped network under a written scope.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which ownCloud line applies, including storage backend, identity provider and client mix.
- Quotes follow from the written scope, and ongoing support is available as a retainer.
How we build
- Classic deployments follow the Docker-only model of Classic 11, with the web server, PHP runtime and database inside the images.
- Infinite Scale builds cover the chosen S3, NFS or PosixFS storage backend and the embedded or external OpenID Connect provider.
- Office integration through WOPI is configured and tested against the editors your users need, such as Collabora Online or ONLYOFFICE Docs.
How we hand over
- Handover includes the configuration, deployment and operating documentation written for your own administrators.
- Backup and restore procedures are documented and exercised before the environment is accepted into production.
- Upgrade and migration steps between ownCloud lines are written out, so your team knows what moving between them involves.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Security testing of the deployed platform can be scoped separately, covering applications, APIs and infrastructure.
- Compliance readiness work prepares systems and evidence for your assessors, which independent auditors and certification bodies then assess.
