Davis: a translatable admin interface for a sabre/dav calendar and contact server

The problem is that CalDAV has no user interface, only a protocol

A CalDAV or CardDAV server is unpleasant to administer from the command line. Creating a user means writing a principal into the database, creating a calendar means another row, and sharing one with another user means a third. The protocols themselves work well, which is why macOS, iOS, Thunderbird and a dozen other clients talk to them without trouble, but the setup path is designed for an administrator, not for the person who just needs a shared family calendar.

Davis is the answer to that gap. It is a modern, simple, feature-packed and fully translatable DAV server, admin interface and frontend based on sabre/dav, built with Symfony 7 and Bootstrap 5, and it was initially inspired by Baikal. The description is careful to say it is inspired by that project rather than a fork of it, and the documentation treats migration from a Baikal managed MySQL database as a supported path.

The audience is a self hoster or small organisation running a calendar and contacts server for people who are not technical. The homepage points at the author's project list rather than a dedicated site, and the project lives under the MIT licence with releases published as v5.x tags.

The dashboard does users, calendars, sharing and address books

The web admin dashboard is the visible part of the project. It provides user edition, calendar creation and sharing, and address book creation, and the interface is described as simple, straightforward and responsive, with a light mode and a dark mode. The screenshots in the repository show the dashboard, a user creation page and a sharing page, plus a setup information panel and a colour mode switch.

The features that go beyond plain administration are worth naming. There are public calendars available to anyone with the link, which is how you share an events page without creating an account for the reader. There is an automatic birthday calendar that is updated on the fly when birthdates change in your contacts, which is a small thing that removes a recurring chore. And subscriptions are supported, added from the client side, with the macOS calendar given as the example.

That last point reflects how the server is meant to work. The client does the subscription, the server serves it, and the admin interface is not involved. The same is true of the DAV layer generally, which is where the distinction between what Davis adds and what sabre/dav already does becomes important.

The DAV server underneath supports CalDAV, CardDAV, scheduling and notifications

Below the interface sits a sabre/dav based server, and the project describes its capabilities as a non-exhaustive list: CalDAV, CardDAV, WebDAV, calendar sharing, scheduling, mail notifications and server-side subscriptions, depending on the capabilities of the client.

That dependency is the architectural fact to keep in mind. Davis is not implementing CalDAV scheduling or CardDAV queries, it is configuring and fronting sabre/dav, which means the protocol behaviour, the interoperability with third party clients and the security history of the DAV server all come from that library and its version, not from this project. The composer.json and composer.lock in the repository pin those versions for any deployment.

The extra features on top of the raw protocol are the ones Davis owns. The dashboard, the user management, the sharing workflow, the birthday calendar, the public calendars and the translation layer are all in this repository, along with the templates/ and translations/ directories that make the interface translatable. The repository also carries migrations/, config/, src/, tests/, a phpunit configuration and a .php-cs-fixer configuration, which is the layout of a normal Symfony application.

Installing it: composer, environment file, migrations, done

The install path is short and the documentation is explicit about the difference between development and production. Clone the repository, then retrieve the dependencies. For a local development install, composer install, and for production, composer install --no-dev, with APP_ENV set to prod in your .env.local file.

The database credentials go in the same .env.local file, and the driver is chosen there.

DATABASE_DRIVER=mysql # or postgresql, or sqlite
DATABASE_URL=mysql://db_user:db_pass@host:3306/db_name?serverVersion=10.9.3-MariaDB&charset=utf8mb4

Then the schema is created with the Doctrine migration command.

    bin/console doctrine:migrations:migrate

The admin account for the backend is set with two more variables, and the documentation shows the placeholder values you are expected to replace.

ADMIN_LOGIN=admin
ADMIN_PASSWORD=test

Requirements are PHP above 8.2 with the pdo_mysql or pdo_pgsql or pdo_sqlite extension, plus gd and intl, and Composer 2. The imap and ldap PHP extensions are only needed if you use those authentication methods, and the documentation notes they are not enabled or compiled by default except in the Docker image. MySQL or MariaDB is the recommended database, with PostgreSQL and SQLite marked as not extensively tested yet.

AUTH_REALM is baked into the password hashes, so changing it locks everyone out

The authentication settings are the part of the configuration with a real trap in it, and the project documents that trap in detail. The realm and the method are two environment variables.

AUTH_REALM=SabreDAV
AUTH_METHOD=Basic # can be "Basic", "IMAP" or "LDAP"

The warning is that you must not change AUTH_REALM on an existing installation. Davis stored passwords as md5(username:AUTH_REALM:password) until v1.10.0 in September 2021, and a database imported from Baikal uses the same scheme. The realm is part of those hashes, so changing it makes every one of them stop working, with no error beyond a failed login. The accounts are still there, they simply cannot authenticate any more.

The method can also be IMAP or LDAP, which delegate authentication to an external provider, and there is a section in the documentation with the specific environment variables for those. Separately, the whole dashboard can be opened up with ADMIN_AUTH_BYPASS set to the string true when a third party authorisation provider such as Authelia sits in front, and the documentation is careful to say this does not change the behaviour of the DAV server itself.

Deployment is a Docker image, a NixOS module, or a normal PHP host

The project is described as easily containerisable, with a Dockerfile and a sample docker-compose configuration file in the repository, and two prebuilt image flavours on the GitHub container registry. The standalone flavour includes a Caddy reverse proxy, and the barebone flavour does not, so you can put your own proxy in front.

There is also a NixOS package and a NixOS module, which is the option that removes most of the configuration work for anyone already running that distribution. Otherwise the application is a conventional Symfony deployment behind Apache or Nginx, and the documentation notes that in that case the environment variables can be set directly in the web server configuration instead of in the .env.local file.

One production setting is called out as a caution rather than a suggestion. In a production environment the APP_ENV variable must be set to prod, because otherwise sensitive data can leak. The version support table gives the same care to the branches, with main as the development branch on PHP 8.2 and above, v5.x as stable, v4.x receiving security fixes only on PHP 8.0 through 8.3, and v3.x marked unmaintained on PHP 7.3 through 8.2.

Editorial conclusion

Adopt Davis if you need to give non technical people a way to create users, calendars and address books on a CalDAV or CardDAV server, because the dashboard removes the need to teach people the protocol and the configuration files. Do not adopt it as a calendar server in its own right, since the DAV behaviour comes from sabre/dav underneath, and do not expect the same support depth across database backends, with PostgreSQL and SQLite described as not extensively tested. Before you deploy it, set APP_ENV to prod in .env.local, choose an AUTH_REALM once and never change it, because the realm is part of the stored password hashes, and set ADMIN_LOGIN and ADMIN_PASSWORD to something other than the defaults.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tchapi/davis on GitHub