Baïkal: a self-hosted CalDAV and CardDAV server built on sabre/dav

What Baïkal is for, and who ends up running it

Baïkal solves a narrow problem: you have calendars and contacts that live in a client, and you want them to live on a server you control instead. The repository describes itself as "the source repository for the Baïkal CalDAV and CardDAV server", which makes it the server half of a sync pair. The clients are the usual ones: the README points to a German tutorial covering Thunderbird, Android and DAVx5, and a French guide covering iOS clients. Both are written for readers without much IT experience, which tells you the intended audience is not platform engineers. It is someone with a Raspberry Pi or a small VPS who wants their phone and laptop to agree about appointments. The project is GPL-3.0 and, per the credits section, was created by Jérôme Schneider of Net Gusto together with fruux and is now developed by volunteers. The last push to the repository was on 2026-08-13, and 0.12.1 was released on 2026-08-05, so this is a maintained codebase rather than an abandoned one.

How the code is laid out: Core, Specific and the schema files

The top level splits into Core/ and Specific/. Core holds the application, the HTML front end lives in html/, and configuration lives in config/. Specific/ is where per-installation state goes: the Makefile creates Specific/db/ and touches a .empty file inside it, which is the pattern you use to keep an empty directory in version control while the actual database file is written at runtime. The database is not abstracted away behind a migration tool. Instead, Core/Resources/Db/MySQL/db.sql and Core/Resources/Db/SQLite/db.sql are generated by concatenating SQL files shipped with sabre/dav, which the build-assets target does by cat-ing vendor/sabre/dav/examples/sql/mysql.*.sql and the SQLite equivalent into those two paths. That is the whole schema story: Baïkal inherits its tables from the sabre/dav examples rather than maintaining its own migrations. Practically, this means the upgrade path is not a sequence of numbered migration scripts you can inspect. The distribution build, produced by make dist, copies Core, html, LICENSE, README.md and composer.json into build/baikal, pins the platform to PHP 8.2 with composer config platform.php 8.2, installs dependencies with --no-dev, strips the bootstrap and font-awesome vendor directories, and zips the result as baikal-$(VERSION).zip.

Installing Baïkal and adding a first calendar

The README does not contain installation steps. It states plainly that you should "head to sabre.io/baikal for information about installation, upgrading and troubleshooting", and the upgrade section points at sabre.io/baikal/upgrade/. So the authoritative install procedure is off-repository, and anything below is the build-side workflow the Makefile encodes, not a substitute for that page. From a clone, dependencies come from Composer, and the Makefile expects vendor/autoload.php to exist before either build target runs:

composer install --no-interaction

If you want the schema files regenerated from the vendored sabre/dav examples, the Makefile has a target for exactly that. It concatenates the MySQL and SQLite example SQL into Core/Resources/Db/:

make build-assets

To produce a distributable archive rather than run from the source tree, use the dist target. It builds into build/baikal, pins PHP 8.2, installs production dependencies only, and writes a zip named after the version read out of Core/Distrib.php:

make dist

The version string is read at build time with a short PHP invocation, so the archive name tracks BAIKAL_VERSION rather than a hardcoded number:

php -r "include 'Core/Distrib.php'; echo BAIKAL_VERSION;"

There is also a clean target, and it is blunt. It removes config/baikal.yaml and Specific/db/db.sqlite, described in the Makefile as wiping all local data and returning to a clean install. Point a client such as Thunderbird or DAVx5 at the endpoint once the server is running, and the client's own CalDAV or CardDAV discovery does the rest.

The upgrade path is a link, and that is a real risk

The README's entire treatment of upgrading is one sentence pointing to sabre.io/baikal/upgrade/. There is no rollback procedure documented in the repository, no note on schema changes between 0.11.1 and 0.12.0, and no version compatibility matrix beyond the PHP 8.2 pin the Makefile applies to the distribution build. That pin matters: make dist sets the Composer platform to 8.2, so the shipped archive assumes that runtime, while composer.json in the source tree is the thing you should read before running Baïkal on a different PHP version. The second risk is the schema. Because Core/Resources/Db/*/db.sql is generated from sabre/dav's example SQL, an upstream change in those examples is a change to your database definition, and make build-assets is the step that would surface it. If you upgrade by replacing files without regenerating and comparing that SQL, you are trusting a process you cannot audit from the repository alone. Make a copy of Specific/db/db.sqlite, or a dump of your MySQL database, before any version jump. This is the point where Baïkal asks more of you than a packaged appliance would.

Where Baïkal is the wrong choice

If you need a server that manages its own schema migrations, Baïkal is the wrong tool. The project delegates that to SQL files copied out of a dependency, and the upgrade instructions live outside the code you are deploying. Teams that need an auditable change history per release will find nothing here to audit. It is also the wrong choice if you do not want to run PHP. The build targets assume Composer, a Makefile and a PHP binary, and the distribution pins PHP 8.2; there is no container image, no system package and no other runtime mentioned in the repository. And if your requirement is groupware rather than sync, Baïkal is a CalDAV and CardDAV server, which means it stores and serves calendars and contacts. Scheduling, shared resource booking and mail are outside what the README claims for it. Finally, the clean target deletes config/baikal.yaml and Specific/db/db.sqlite without a confirmation prompt, so anyone treating this Makefile as a general-purpose maintenance tool should read it first.

How it differs from running sabre/dav directly

The obvious alternative is sabre/dav itself, the library Baïkal is built on. The difference is packaging, not protocol. sabre/dav gives you a PHP library and example SQL schemas; you write the application that wires up authentication, a web interface and configuration. Baïkal is that application, already written: it ships a Core/ directory with the server logic, an html/ front end, a config/ directory holding baikal.yaml, and a Specific/db/ directory for the database. It also ships the schema files derived from sabre/dav's examples so you do not have to assemble them. The trade-off runs the other way too. Choosing sabre/dav directly means you own the upgrade path and can version your own migrations; choosing Baïkal means you inherit a fixed layout and an upgrade procedure published on a separate site. If you want a working CalDAV endpoint today and do not want to write the glue, Baïkal is the shorter route. If you need to control exactly when and how the schema changes, the library underneath gives you that control and Baïkal takes some of it away.

Licence, maintenance and what an upgrade costs you

Baïkal is GPL-3.0. If you deploy it as a service for yourself, the licence imposes little in practice. If you redistribute a modified version, the GPL's source-availability terms apply to your distribution, and that is a question for your own legal review rather than something this article can settle. On maintenance: the repository is not archived, the last push was on 2026-08-13, and 0.12.1 shipped on 2026-08-05, with 0.12.0 two days earlier and 0.11.1 back on 2025-11-30. The gap between 0.11.1 and 0.12.0 is roughly eight months, so releases arrive when they arrive rather than on a schedule. The upgrade cost is dominated by two things you must do by hand: back up Specific/db/db.sqlite or your MySQL database, and read sabre.io/baikal/upgrade/ before touching files. Because the schema is generated from sabre/dav's example SQL by make build-assets, a version bump can change Core/Resources/Db/MySQL/db.sql and Core/Resources/Db/SQLite/db.sql in ways that are only visible if you regenerate and diff them. Budget for that diff, not just for the file copy.

Editorial conclusion

Adopt Baïkal if you want CalDAV and CardDAV on a PHP host you already control and you accept that the manual is on sabre.io rather than in the repository. Do not adopt it if you need a documented rollback path or an upgrade procedure you can read from the source tree, because the README defers both to the project site. Before committing, verify that your PHP version matches what composer.json requires, that Core/Resources/Db contains the schema for the backend you intend to use, and that you have read sabre.io/baikal/upgrade/ end to end, since that page is the only upgrade procedure the project publishes.

Frequently asked questions

Official sources

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