owncloud/core: the PHP server behind ownCloud Classic

What problem owncloud/core solves, and for whom

owncloud/core is the server-side component of ownCloud Classic. The README describes it as providing file storage, synchronization and sharing, and it bundles three protocol servers in the same codebase: WebDAV for files, CalDAV for calendars and CardDAV for contacts. That combination is the reason the project exists as a single repository rather than a set of services. If you need a place where a desktop client can sync a folder, a phone can subscribe to a calendar and a script can PUT a file over HTTP, one install covers all three.

The audience is narrower than the topic list suggests. This is not a library you import. It is a PHP application you deploy, and the README states that the server runs on PHP with support for MySQL, MariaDB, PostgreSQL and SQLite. The people who get value from it are administrators running a self-hosted share for an organization, and developers building apps against the plugin architecture. The README names Activity, Calendar and Contacts as examples of apps that extend the core, which tells you the intended extension model: separate repositories that hook into this one.

One distinction matters before anything else. This repository is ownCloud Classic, and the README says so directly, pointing readers to ownCloud Infinite Scale (oCIS) for the next-generation platform. Anyone evaluating owncloud/core should decide first which of those two lines they are committing to, because the answer changes the deployment story, the app ecosystem and the upgrade path.

How the server is put together

The repository layout tells most of the architecture story. At the top level there is index.php and public.php for web entry points, remote.php for the DAV endpoints, ocs/ and ocs-provider/ for the Open Collaboration Services API, ocm-provider/ for cloud federation, console.php and the occ script for command-line administration, and cron.php for background jobs. lib/ holds the framework code and apps/ holds the bundled applications. That is a conventional PHP application with several front controllers, each serving a different protocol or API surface.

The plugin architecture is the second structural fact. Apps live in apps/ and are loaded by the core, which is why the README can describe the repository as the foundation that other repositories extend. A DAV request does not go through a generic router and then a plugin; the DAV server is part of the core, and apps add behaviour around storage, sharing and user management. The config/ directory and db_structure.xml indicate that schema and configuration are managed by the application rather than by an external migration tool.

Federation is worth calling out because it is easy to miss. The ocm-provider/ directory implements the Open Cloud Mesh side of sharing between separate ownCloud instances, and the topic list on the repository includes federated. For an administrator this means sharing is not limited to users inside one install. The README does not document the federation setup steps, so treat that as a feature to verify against the admin manual rather than something you can configure from the repository alone.

Installing owncloud/core and running a first command

The README does not contain production install steps. It says plainly: for installing ownCloud Classic, see the official installation manual at doc.owncloud.com. It also notes that the server is available as a Docker image on Docker Hub under the owncloud/server repository. Those are the two supported routes the README gives you, and you should follow the manual rather than improvising from the repository.

The repository does document the development build, and that is the part you can reproduce from the files here. The prerequisites listed are Composer v2, plus Yarn and Node.js v14 or higher. With those in place, the README gives a single target:

make

The Makefile header confirms the same requirements and lists what make does: it prepares everything, with make clean, make test-php and make test-js available as separate targets. The Makefile also defines the tooling paths it uses, including vendor-bin/phpstan/vendor/bin/phpstan, vendor-bin/phan/vendor/bin/phan and the php-cs-fixer binary under vendor-bin/owncloud-codestyle. If you are contributing rather than deploying, those are the commands you will run.

For a first real interaction with a running instance, the administration entry point is the occ script at the repository root. The README does not list occ subcommands, so the honest position is that the script exists and is the console entry point, and the manual is where the command reference lives. One contribution rule is stated explicitly and is worth knowing before you send a patch: every commit must carry a Signed-off-by line, produced with:

git commit -s -S -m "your commit message"

The README requires PGP/GPG-signed commits in addition to the DCO sign-off, and states that translation changes go through Transifex rather than pull requests.

Where owncloud/core is the wrong choice

The clearest limitation is stated by the project itself. owncloud/core is the Classic line, and the README directs readers to ownCloud Infinite Scale for the next-generation platform. If you are standing up a new deployment in 2026 and you have no existing apps or clients tied to this codebase, choosing Classic means choosing the older of two platforms the same organization maintains. That is a strategic decision, not a technical defect, but it belongs at the top of your evaluation.

The second constraint is the delivery model. This is a PHP application with a documented dependency on a separate installation manual. The README gives no supported upgrade procedure, no rollback instructions and no backup guidance. The CHANGELOG.md file exists and releases are tagged, including v11.0.0 and a v10.16.4 maintenance release, but the repository does not tell you how to move between them safely. An administrator who needs a documented, self-contained upgrade path will not find it here.

The third is the contribution surface, which hints at operational complexity. Signed commits, DCO sign-offs and a workflow the README summarizes as rebase early, rebase often. Those rules apply to contributors, not operators, but they signal a project that has accumulated process over a long life. Combined with the KDE heritage review mentioned in the licensing section, this is a codebase with history, and history costs time when you need to understand why something behaves the way it does.

ownCloud Classic compared with Nextcloud

The comparison people actually search for is ownCloud against Nextcloud, and the README supports one honest observation rather than a verdict. It describes owncloud/core as the server-side component of ownCloud Classic and points to ownCloud Infinite Scale as the next-generation platform. That means the ownCloud side of the comparison is itself split: Classic, which is this repository, and oCIS, which is a different repository and a different architecture. Anyone comparing ownCloud to Nextcloud should first decide which ownCloud they mean, because the answers differ.

On the mechanism, what the README shows is a PHP application with WebDAV, CalDAV and CardDAV servers, a plugin architecture, user and group management, encryption support, external storage backends and a REST API, running against MySQL, MariaDB, PostgreSQL or SQLite. The repository also implements OCS and OCM providers, so both the app API and cloud federation are in scope. The README does not benchmark this against anything, and it would be wrong to invent a performance comparison. The real difference to evaluate is governance and release cadence: this repository is stewarded by the Kiteworks Open Source Program Office, which the README says launched on May 5, 2026, and it carries an announced relicensing plan that Nextcloud does not share.

A second alternative sits inside the same project family. If the PHP architecture is the thing you are trying to avoid, ownCloud Infinite Scale is the alternative the README itself names, and it is a different codebase rather than a fork or a configuration of this one. Choosing between them is the decision that matters most, and the README is explicit that both exist.

Licence status and the relicensing plan

The current licence is AGPL-3.0, and the README is emphatic that this is the current state rather than a target. The COPYING file is the licence text, and the README notes that the LICENSE file in each repository reflects current status, not the intended destination.

The intended destination is Apache 2.0. The OSPO is driving a relicensing of ownCloud repositories toward the Apache License 2.0, following the Apache Software Foundation's third-party licence policy, and repositories migrate as their audits complete. The README lists the prerequisites for this repository specifically: CLA or DCO coverage from all past contributors, an audit and replacement or isolation of copyleft dependencies, a KDE heritage review for code carrying KDE-era copyrights, and complete relicensing of every file rather than a header change. It also states the reason the last point matters: AGPL-3.0 is a strong copyleft licence, and the README classifies it as Category X under Apache policy, meaning it cannot be included in Apache-2.0 works.

For a team evaluating owncloud/core, the practical implication is that the licence you receive today is AGPL-3.0 and the licence you receive later may be Apache 2.0. If you redistribute the software or embed it in a product, that difference is material, and the migration has no announced completion date in the README. This is a description of what the README says, not legal advice. If the licence terms affect your product, that is a question for your own counsel, and the README provides [email protected] as the contact for licensing questions.

Maintenance, releases and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-10. That is recent enough that the codebase is receiving changes, and the release list supports the same reading: v11.0.0 was tagged on 2026-07-30, with v11.0.0-rc3 on 2026-07-29, and a v10.16.4 maintenance release also on 2026-07-29. Two active lines, a current major and a maintenance branch, is a normal pattern for a project with an installed base that cannot move quickly.

What the README does not give you is the cost of an upgrade. It points to CHANGELOG.md for release history, and the repository has a changelog/ directory, but there is no documented migration procedure, no supported rollback and no statement about database schema changes between versions. The presence of db_structure.xml at the repository root suggests schema is versioned with the application, which is a good sign for consistency, but it is not a substitute for an upgrade guide. An administrator planning a move from v10 to v11 should treat the manual as the source of truth and budget time for reading it, because the repository will not tell you what breaks.

The contributor-facing cost is different and better documented. The README sets out signed commits, DCO sign-offs, a rebase workflow, Dependabot-managed dependency updates, and a GitHub Actions policy restricting workflows to actions owned by owncloud, created by GitHub, or verified in the Marketplace. Those rules are specific and enforceable, which is more than many projects offer. They also mean a first contribution has a setup cost before any code is written.

Editorial conclusion

Adopt owncloud/core if you need a self-hosted file sync and share server with WebDAV, CalDAV and CardDAV in one PHP application and a plugin surface that existing apps already target. Do not adopt it if you are starting fresh and want the next-generation platform: the README points to ownCloud Infinite Scale (oCIS) for that, and this repository is explicitly the Classic line. Before committing, verify three things: which database you will run (the README lists MySQL, MariaDB, PostgreSQL and SQLite), whether the apps you depend on are maintained against the v11 line, and how the announced relicensing to Apache 2.0 would affect your own redistribution plans, since the LICENSE file still says AGPL-3.0.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. owncloud/core on GitHub
3. Project website
4. README
5. Releases