Self-Hosted Calendar and Contacts: Radicale vs Baikal

Radicale and Baikal are both CalDAV and CardDAV servers, which means they speak the standard protocols every phone and desktop calendar already understands — so you point your existing calendar and contacts apps at your own server and they sync natively, no Google account required. Radicale is the lighter of the two, a Python server that stores calendars as plain files; Baikal is a PHP server with a real admin interface and a database backend.

The reason this is the most boring app in the personal-cloud stack and the one with the highest daily value is that calendar and contact sync is the quiet chain tying a household to a big-vendor account. You can self-host your files, your photos, and your passwords, but if your calendar still lives on Google Calendar, the vendor still owns the rhythm of your week and the address book of everyone you know. Killing that last dependency is unglamorous and it changes how locked-in you feel more than any other migration.

I run Radicale on the Proxmox host alongside the rest of the stack in the self-hosted personal cloud apps guide, and it is the app I forget exists — which is the highest compliment I can pay infrastructure. This is the comparison and setup that retires the last big-vendor account: what the protocols are, how Radicale and Baikal differ, how to connect a phone natively, and the migration path off Google Calendar and Contacts.

What Are CalDAV and CardDAV, and Why Do They Matter?

CalDAV and CardDAV are open protocols — CalDAV for calendars and tasks, defined in RFC 4791, and CardDAV for contacts, defined in RFC 6352 — that let a client sync calendars and address books with any compatible server. They matter because they are the reason your phone’s built-in calendar can talk to your own server instead of a vendor cloud: the protocol is standard, so any CalDAV client works with any CalDAV server.

This is the opposite of the proprietary-sync model that locks you in. Google Calendar, iCloud, and Outlook all speak CalDAV and CardDAV under the hood for interoperability, which means the protocol itself is not exotic — it is the standard the big vendors implement to play nice with each other. Running your own CalDAV/CardDAV server puts you on the same standard, speaking the same language, with no vendor in the middle. Your phone does not know or care that the server is yours; it just sees a calendar account.

The practical consequence is that you do not need a special app. The native iOS Calendar and Contacts apps, the native Android Calendar and Contacts apps (via a DAVx5-style sync on Android), and desktop clients like Thunderbird all support CalDAV and CardDAV out of the box. You add an account, point it at your server URL, and your existing apps sync to your own hardware. The standards are documented at the IETF: RFC 4791 for CalDAV and RFC 6352 for CardDAV.

Radicale: The Tiny Server That Is Just Files

Radicale is a lightweight Python CalDAV and CardDAV server with almost no moving parts — it stores calendars and address books as plain files on disk, which makes backup a file copy and recovery a file restore. It is the server I run, because a calendar server that is just files on disk is exactly the kind of thing I want to be able to rebuild in five minutes.

The appeal is operational simplicity. There is no database to run, no schema to migrate, no admin database to back up separately. A calendar is a collection of iCalendar (.ics) entries in a file; an address book is a collection of vCard entries in a file. Back up the storage directory and you have backed up every calendar and contact on the server. Restore is copying the directory back. The server itself idles at a trivial memory footprint — well under 200 MB — and runs happily in a small LXC container. The official site at radicale.org documents the configuration.

The trade-off for that simplicity is the admin experience. Radicale has a minimal web interface — enough to create users and collections, not a polished dashboard. If you want a GUI to manage users, permissions, and calendars, Baikal is the better fit. If you want a server you can fully understand by reading its config file and a storage directory, Radicale wins. For a household where the server is set up once and then forgotten, I will take the file-based simplicity every time, because the day I need to recover is the day I am glad there is no database in the way.

Baikal: The PHP Server With a Real Admin UI

Baikal is a PHP-based CalDAV and CardDAV server with a proper web administration interface and a database backend (MySQL or SQLite), which makes it the choice if you want a GUI to manage users, calendars, and address books rather than editing config files. It is heavier than Radicale for the same job, but the management experience is friendlier.

Where Radicale is a single Python process and a storage directory, Baikal is a PHP application: a web server (Nginx or Apache with PHP), a database (MySQL or SQLite), and the Baikal codebase. The admin interface lets you create users, add calendars and address books, set sharing, and view sync activity through a browser, which is genuinely nicer if you are managing multiple household members or you simply prefer not to touch config files. The trade is that there is a database to back up and a PHP stack to maintain, in exchange for the management convenience. The project lives at sabre.io/baikal.

For most households the database choice inside Baikal is SQLite, which keeps the footprint reasonable and the backup story a single file. MySQL only earns its place if you are running Baikal for many users or you already have a database server you want to share. The honest comparison is that Baikal gives you a dashboard and costs you a database; Radicale gives you files and costs you a config file. Both are correct; pick the one whose maintenance model you prefer.

How Do You Connect a Phone to a Self-Hosted Calendar?

On iOS you add a CalDAV account in Settings and the native Calendar and Contacts apps sync to your server; on Android you use a CalDAV sync app like DAVx5 because Android does not ship native CalDAV, after which the native apps sync the same way. In both cases the phone treats your server as just another calendar account, indistinguishable from iCloud or Google.

The iOS path is built in: Settings, then Mail and Accounts, then Add Account, then Other, then Add CalDAV Account. You enter your server URL, your username, and your password, and iOS pulls the calendars and contacts your account has access to. The native Calendar app shows them alongside any other calendars, and edits sync back to your server over the WireGuard tunnel. On Android, the operating system does not include native CalDAV support, so a one-time install of DAVx5 bridges the gap — it runs as a sync adapter and feeds your server’s calendars and contacts into the native Android Calendar and Contacts apps. After that initial setup, the experience is identical.

The detail that bites people is the URL and the certificate. The clients expect an HTTPS URL with a trusted certificate, and they fail quietly when they do not get one — iOS in particular will silently refuse to sync a calendar over HTTP or with an untrusted certificate, producing no error and just no events. I hit this once: I pointed my phone at the calendar over HTTP during testing, and it took me a day to realize the sync was not failing loudly but silently. The fix is a real certificate, not a workaround. My Radicale sits behind Caddy with a Let’s Encrypt certificate, the reverse proxy comparison and the Let’s Encrypt wildcard DNS-01 guide cover that, and the hostname resolves correctly inside the WireGuard tunnel through my local DNS so the phone uses the same URL at home and away.

How Do Radicale and Baikal Compare?

The table below is the decision I make when someone asks which calendar server to run. The storage model column matters most for backup, and the admin column matters most for how often you intend to touch the server after setup.

Migrating Off Google Calendar and Contacts

The migration is an export from Google and an import into your server: Google lets you download your calendar as an iCalendar file and your contacts as a vCard file, and your CalDAV/CardDAV server ingests both. It is a one-time move, and after it your data lives on your hardware.

For calendars, Google Calendar’s settings let you export a calendar as an .ics file, which is the standard iCalendar format every CalDAV server understands. You create a calendar on your server and import the .ics into it through your client (most calendar apps have an import option) or by placing it in the server’s storage. For contacts, Google Contacts exports a vCard file, which you import into your CardDAV address book the same way. Recurring events and contact photos come through cleanly because iCalendar and vCard are the interchange formats the whole ecosystem uses. The one thing to verify is timezones — make sure your server and clients agree on the timezone for events, or a recurring meeting can shift an hour after a daylight-saving change.

The part to plan for is the cutover. Do the export and import while Google is still the source of truth, verify everything landed on your server, and only then switch your phone’s default calendar account from Google to your server. Keeping both accounts on the phone briefly lets you confirm the new one is syncing correctly before you delete the Google account. Once the self-hosted calendar has been your daily driver for a week without surprises, you can delete the Google calendar data with confidence.

Where the Calendar Server Lives on My Network

The calendar server sits on the LAB segment behind the OPNsense firewall, fronted by Caddy with a real certificate, reachable over WireGuard, with the storage directory backed up to the NAS. It is a small, quiet service that follows the same deployment pattern as the rest of the stack — and it benefits from it, because a calendar server you cannot reach from your phone is useless.

In my rack, Radicale runs in an LXC on the Proxmox host, its storage directory on SSD with hourly snapshots, and Caddy terminates TLS in front of it. The hostname resolves to the server through local DNS — I run Pi-hole and AdGuard Home redundantly, covered in the Pi-hole setup guide — so the phone uses the same calendar URL whether it is on the home Wi-Fi or on cellular through the WireGuard tunnel. The home VPN and remote access guide covers the tunnel. No calendar port is forwarded to the internet; the only way in is the WireGuard key the phone holds.

The backup story is the best part of Radicale’s file-based model. The entire calendar and contact store is a directory of plain files, so the backup is a snapshot and a copy to the NAS, and a restore is putting the directory back. I test that restore periodically the same way I test the Vaultwarden vault restore — a calendar you cannot restore is a calendar you do not really have. With Radicale, the restore is trivial enough that I have no excuse not to verify it.

Sharing Calendars Within a Household

Both Radicale and Baikal support shared calendars and address books, so a household can have a shared family calendar alongside individual calendars, all on the same server. The sharing is per-collection: you grant another user access to a specific calendar, and it appears in their client as a synced calendar they can view or edit depending on the permission.

This is the feature that makes a self-hosted calendar genuinely better than a pile of individual vendor accounts. A shared family calendar that everyone reads and writes to, a shared contacts book for the household’s common addresses, and private calendars for each person — all on one server you control, all syncing to everyone’s phones natively. Radicale handles this through its rights configuration; Baikal handles it through the admin UI. The setup is a one-time grant, after which the shared calendar syncs to every authorized device automatically.

The discipline is access control. Grant the minimum permission that works — read-only for a calendar someone should see but not edit, read-write for the family calendar everyone maintains. And keep the server private behind WireGuard, because a shared calendar reveals the rhythm of a household’s life in a way an attacker could exploit. Convenience comes from the sharing model, not from exposing the server; the sharing works perfectly over the tunnel.

What I’d Do Starting Today

If I were standing up a self-hosted calendar and contacts server fresh, I would run Radicale in an LXC on the Proxmox host, put its storage directory on SSD with snapshots, front it with Caddy and a real Let’s Encrypt certificate, and reach it only over WireGuard. I would migrate from Google with an iCalendar and vCard export, connect my phone natively through CalDAV, verify the sync for a week, and then delete the Google calendar data. I would set up one shared family calendar and keep individual calendars private.

The reason this app matters more than its footprint suggests is that it is the last chain to a vendor account for most people. Files, photos, passwords, documents, notes — all of those have obvious self-hosted replacements people adopt eagerly. Calendar and contacts sit there quietly, syncing to Google, until you realize that moving them is the move that makes the self-hosted stack complete. Do it once, do it with a real certificate and a tested backup, and the rhythm of your week lives on your own hardware, behind a firewall whose rules you wrote.

More to Read

• Self-Hosted Personal Cloud Apps: The Complete Guide
• Self-Hosted Notes: Joplin vs Obsidian vs Trilium
• Vaultwarden: Running Your Own Bitwarden-Compatible Vault
• Pi-hole Setup Guide for a Home Network
• Home VPN and Remote Access: The Complete Guide