AgenDAV: a self-hosted CalDAV client that has moved into maintenance mode

A CalDAV client, and a policy statement in a badge

AgenDAV is described as a CalDAV web client which features an AJAX interface to allow users to manage their own calendars and shared ones. The project is written in PHP, licensed under the GNU General Public License version 3.0 or later, and the default branch is main with the last push on 2026-10-18. The releases are 3.2.0 in June 2026, 3.3.0 twenty days later and 3.3.1 in July, so the code is still moving.

The badge at the top of the README is the thing to notice first. It says maintenance mode, and there is a whole section of the README explaining what that means.

In maintenance mode the maintainers choose to prioritise stability and compatibility over new features for now. There is no active development, and new major features are not planned. New features may still be added through pull requests, proposed in issue tickets and sent as pull requests, with the maintainers reviewing and presumably merging them. Pull requests for bug fixes are welcome and will be reviewed and merged, and so are pull requests that keep the software compatible with new PHP versions. Critical security concerns will be addressed.

That is an unusually precise statement of what a maintainer will and will not do, and it is better than the alternative, which is a project that looks active because people are fixing things but nobody is steering it. Here you can tell exactly what the next year looks like.

The features themselves, though, are broad. Calendar views come in month, week, day and list. Events can be created, edited, duplicated and deleted, and moved by drag and drop to another time slot or day, and resized to change their duration. Recurring events use recurrence rules, reminders are per event with a configurable default for new ones, and there are calendar delegations, so a user can see calendars shared by other people, read only or read and write.

Requirements are modest, and the CalDAV server is yours to run

The requirements section is worth reading carefully, because it tells you what this application is and is not.

AgenDAV needs a web server, PHP 8.5.0 or newer, and three specific extensions, the ctype extension, the mbstring extension and the cURL extension. It needs a database supported by the Doctrine database abstraction layer, and the list given is MySQL, PostgreSQL and SQLite.

The part that shapes the whole project is the last requirement: a CalDAV server, with Baikal, DAViCal and Radicale named. AgenDAV is not a CalDAV server and it is not a calendar of its own. It is a client, and it is a client for a protocol that has several independent server implementations, which is why the feature list mentions that it works with Baikal, DAViCal, Radicale, Nextcloud and others.

That division is what makes the project worth deploying rather than merely installing. Your calendar data stays on a server you control, in a standard format, and AgenDAV is a web interface in front of it. If you already run a CalDAV server for your phone and your desktop calendar, adding AgenDAV gives you a browser front end and shared calendars without moving anything.

Node.js and npm are listed as optional, and the note explains why: they are only needed to build the assets, and the releases already include a build. So an installation from a release tarball does not need a JavaScript toolchain at all, which is a sensible choice for a PHP project aimed at small server deployments.

The Docker compose file is for development, and it says so

The installation section has an unusual pair of statements. The first is that AgenDAV offers no official Docker image. The second is that a compose file is provided in the repository for local development.

So the compose file is a development harness, and the file says the same thing in its first comment: local development stack only, and not a production deployment. The credentials in it are the defaults used when running it without an environment file, and the file explains that you can override them by creating one next to it.

The stack is started from the repository root with:

docker compose up

The stack has four services. The database is MariaDB 10.11 with a health check that waits for the storage engine to finish initialising, retried on a short interval. The CalDAV server is a Baikal image behind nginx, with its configuration and data on named volumes and its port bound to the loopback address on the host. The web application is built from its own directory, and a one-shot builder service is there to compile the assets on the first start.

The builder is the detail that shows the project has been set up by someone who runs it. It runs the npm install, the composer install and the asset build the first time, which takes a minute or two, and then it exits. Subsequent starts detect the existing build and skip it, so the stack comes up in seconds. Without that, every fresh clone would spend a minute and a half compiling assets before anything could be looked at.

The ports are bound to the loopback interface so the stack is not reachable from other hosts, and the documentation points at the installation guide for anything resembling a real deployment.

The front end pipeline dates from the previous decade

The asset scripts in the project manifest are a small archaeology of the project, and they are worth a look because they tell you what to expect when you open the interface.

The templates are compiled with a dust compiler, producing a JavaScript file from the template sources. The styles are written as LESS and compiled, and then a concatenation step joins the application stylesheet with the fullcalendar stylesheet, the jQuery UI base theme and a handful of plugin stylesheets, and the result is minified. The copy step brings in an ES5 shim, the font awesome fonts, the bootstrap fonts and the fullcalendar locale files, and the jQuery UI theme images.

So the front end is a classic server-rendered application with an AJAX layer, using jQuery UI widgets, the fullcalendar library and bootstrap fonts, with a dust template layer. There is no build step for a modern framework, no bundler configuration and no client-side application framework in the dependency list.

That is a deliberate shape for the project rather than an oversight. The application is a PHP application that talks to an external CalDAV server and stores its own data in MySQL, PostgreSQL or SQLite, and the front end is a thin layer over that. The compatibility surface is PHP, and the browser side is whatever the server sends.

The rest of the tooling is old-school in the same way and rather well set up. Linting is done with a tool that checks the editor configuration files and the line endings across the source tree, and there is a separate configuration file for the PHP code style fixer, plus a node version file and a PHP version file that pin the two toolchains the project expects. A migration manifest sits at the root, and the build output is kept in a separate directory so it is obviously not source.

What to check before you put it in front of users

A few decisions are worth making deliberately rather than discovering later.

The first is the CalDAV server. The list of backends the project names is Baikal, DAViCal, Radicale and Nextcloud, and the compose file uses Baikal, so the tested path is the one to try first. Delegated calendars are a feature that depends on the server's own support for sharing, and it is the kind of thing that works in one implementation and not another.

The second is the refresh behaviour. Calendar data refreshes automatically every five minutes, which is a sensible default for a shared calendar and a poor one if your users expect instant updates, and it is worth knowing whether that interval is configurable before you tell somebody that a change will appear.

The third is the licence, and the version of it. GPL version 3 or later means that if you modify the code and distribute it, you have to publish the modified source, which matters if you plan to run a modified instance as a service for people outside your organisation. Running it unmodified for your own team is a different question from offering it as a service, and it is worth getting that right before you deploy.

The fourth is the feature freeze, which is the real risk. The functionality is broad and the code is current, so the product is usable today. But a CalDAV client that will not receive new features means that when the ecosystem moves, you will be maintaining the difference yourself, and the README is honest that the only way that happens is through pull requests from other people. The project also states that the interface is localised with a fallback to English, and that each user can set their language, time zone, the day the week starts, whether weekends are hidden and their working hours, which is the level of detail that a mature calendar interface accumulates.

Editorial conclusion

Adopt AgenDAV if you run a CalDAV server and want a browser front end for your own and your colleagues' calendars without giving your calendar data to a hosted service. Do not adopt it if you need a project with a feature roadmap, because the project is explicitly in maintenance mode with no active development and no new major features planned, so the only growth will come from pull requests. Before you deploy it, check that your CalDAV server is one of the ones it is tested against, and note that the local Docker stack in the repository is explicitly for development and binds its ports to the loopback address, so a real deployment needs the installation guide rather than the compose file.

Frequently asked questions

Official sources

1. agendav/agendav on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases