Nextcloud Calendar: a CalDAV frontend that keeps the backend elsewhere
📆 Calendar app for Nextcloud
At a glance
- What is it?
- Nextcloud Calendar is the JavaScript frontend for calendars on a Nextcloud instance, built on c-dav-library, ical.js and fullcalendar. It is worth adopting when the CalDAV server is already Nextcloud, and it is the wrong layer to reach for if you need a standalone calendar service.
- Who is it for?
- Adopt Nextcloud Calendar if you already run a Nextcloud instance and want calendars inside it, with Talk, Tasks, Deck and Circles integration and WebCal subscriptions. Do not adopt it if you need a calendar server that runs without Nextcloud, or if you need the frontend to own CalDAV bug fixes, because the README states this repository manages only the frontend.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem it solves: calendars inside a Nextcloud instance
The README frames the app in one line: a calendar app for Nextcloud that lets you sync events from various devices and edit them online. That is the whole scope. It is not a calendar server. It is the web client that sits on top of the CalDAV endpoint your Nextcloud server already exposes, and it assumes that endpoint exists.
The audience follows from that assumption. If you run Nextcloud for files and want calendar data in the same account, sharing model and permission system, this is the app you enable. The integration list in the README is the real argument: Contacts, Talk, Tasks, Deck and Circles. A meeting can carry a Talk room, a task with a due date appears in the calendar view, and sharing follows Nextcloud's own user and group model. None of that is portable to a calendar product that does not know what a Nextcloud circle is.
So the decision is not really about the calendar UI. It is about whether your identity, sharing and file storage already live in Nextcloud. If they do, the app is the shortest path. If they do not, installing it means installing Nextcloud first.
How the frontend talks to CalDAV
The README names three libraries: c-dav-library, ical.js and fullcalendar. The split tells you where the logic lives. c-dav-library handles the CalDAV conversation, ical.js parses and serializes iCalendar data, and fullcalendar renders the grid. The topics list on the repository adds rfc-5545 and caldav-sharing, which matches that division: the app is a client of a protocol, not an implementation of one.
That has a practical consequence for debugging. If an event fails to save, the fault can sit in the browser client, in the CalDAV request, or in the server that answers it. The README is explicit about where to take each kind: this repository only manages the frontend, and problems with the CalDAV backend belong to the Nextcloud server team. For anyone filing an issue, that sentence is the first thing to read, because a backend bug filed here will be redirected.
The feature list also shows what the frontend is expected to do beyond drawing events. Attendees, free/busy lookup, reminders in the browser and by email, search, attachments, WebCal subscriptions and appointment booking links all run through the same client. Free/busy in particular is a scheduling query against other users' calendars, so it depends on the server exposing availability correctly. The app renders the answer; it does not compute it.
Installing it and building it from source
The normal path is the app store. The README states the app is distributed through the Nextcloud app store and can be installed right from your Nextcloud installation, following the admin manual's apps management page. Release tarballs are hosted in the nextcloud-releases/calendar repository. For most administrators, that is the entire installation procedure, and no build step is involved.
Building from source is a separate workflow, and the README gives it plainly. You need Node.js and Composer. Then: composer install for PHP dependencies, npm ci for JavaScript dependencies, and one of three build commands. npm run dev produces a development build, npm run watch rebuilds on changes, and npm run build produces the production build. Tests run through composer test for the back end and npm run test for the front end.
Note that npm ci, not npm install, is the documented command. That matters if you are scripting a build: npm ci expects a lockfile and installs exactly what it pins, which is the behaviour you want in CI and the behaviour that will fail loudly if the lockfile and package.json disagree. The README also points at the Nextcloud server manual's prerequisites page for manual installs, which is where PHP extension requirements live rather than in this repository.
Supported browsers are listed as Chrome/Chromium 76+, Edge 40+, Firefox 60+, Internet Explorer 11 and Safari 12.1+. The Internet Explorer 11 entry is a signal about how old the support matrix is. It does not tell you whether current releases still hold that line, only what the README claims.
Where the app stops and the server starts
The most important limitation is architectural, and the README states it without hedging: this repository only manages the frontend. Everything below the HTTP layer, including the CalDAV endpoint, authentication, storage and sharing enforcement, is Nextcloud server code. If your calendar data is corrupted, if a sync client cannot authenticate, or if a sharing rule is applied incorrectly, upgrading this app will not fix it.
The release history in the supplied material reinforces that this is a client with its own cadence. The listed releases are v3.3.2 from June 2022, v3.0.0 from November 2021 and v2.4.0-rc2 from November 2021. That list is incomplete relative to the last push date of September 2026, so it should not be read as a statement about current release activity. What it does show is that the app is versioned independently of the server, which means compatibility between a given app release and a given server release is something you check rather than assume.
The wrong-tool case is straightforward. If you want a calendar server with no Nextcloud in front of it, this is not it. The app cannot create the CalDAV service it depends on, and its most distinctive features (Talk rooms, Deck cards, Circles sharing) are meaningless outside Nextcloud. Choosing it for a non-Nextcloud deployment means adopting Nextcloud as a side effect.
Radicale and Baikal solve the other half
The natural comparison is a standalone CalDAV server. Radicale and Baikal both provide the server side: they store calendars and expose CalDAV to clients, and you point a desktop or mobile client at them. Nextcloud Calendar provides the client side and expects someone else to have provided the server.
That difference decides the deployment. With Radicale or Baikal you get a small service whose only job is calendars, and you use whatever client you like. With Nextcloud Calendar you get a browser client, sharing tied to Nextcloud accounts, and the integrations the README lists, but you also get the full Nextcloud server as a dependency, with its own upgrade cycle and its own PHP and database requirements.
Neither is a drop-in for the other. If your users already log into Nextcloud, adding a second calendar service means a second account and a second set of sharing rules. If your users do not use Nextcloud at all, this app gives them nothing they can reach. The honest framing is that these are different layers, and the choice is about which layer you are missing.
Licence and the cost of keeping it current
The repository is AGPL-3.0, and the README's SPDX headers show AGPL-3.0-or-later on the source files, with copyright split between Nextcloud GmbH and, for older files, ownCloud, Inc. The AGPL matters most if you modify the app and let users interact with it over a network, because that is the situation the licence addresses. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read the licence or ask someone qualified.
Maintenance cost splits along the same frontend/backend line. On the app side, you track app store updates or rebuild from source with the documented commands. On the server side, you track Nextcloud server releases, because that is where CalDAV behaviour lives. A calendar problem that appears after a server upgrade is a server upgrade problem.
For contributors, the README sets two conventions worth knowing before opening a pull request: commits follow the Conventional Commits specification, and the project carries a REUSE status badge, which means file-level licence and copyright headers are checked. A patch that adds a file without an SPDX header will not pass that check. Support runs through the Nextcloud forums, and bugs go to GitHub, with the caveat that backend bugs belong in the server repository.
Editorial conclusion
Adopt Nextcloud Calendar if you already run a Nextcloud instance and want calendars inside it, with Talk, Tasks, Deck and Circles integration and WebCal subscriptions. Do not adopt it if you need a calendar server that runs without Nextcloud, or if you need the frontend to own CalDAV bug fixes, because the README states this repository manages only the frontend. Before committing, verify the Nextcloud server version your instance runs against the app store listing, and check whether the CalDAV backend you depend on is maintained in the server repository rather than here.
Community notes