把日历和协作功能搬进Docker容器，意味着你不再需要为每一台服务器手动安装依赖、处理版本冲突或者担心系统升级后服务突然失效。对于个人或小团队来说，一台低配VPS配合几个轻量容器就能跑起完整的CalDAV日历、CardDAV通讯录和任务同步服务。下面这张图展示了一个常见的自托管架构：反向代理作为入口，后端分别连接日历服务和协作套件，数据统一存放到宿主机挂载的卷里。
选型时首先要理解CalDAV和CardDAV协议的作用。CalDAV负责日历事件、待办事项的增删改查和同步，CardDAV则处理联系人信息。只要设备支持这两个协议——无论是手机上的系统日历、Thunderbird邮件客户端还是各种第三方应用——就能直接接入你的私有服务。Docker生态中最常用的日历服务镜像有两个：Radicale和Baikal。Radicale用纯Python编写，配置极简，单文件存储所有数据；Baikal基于PHP和MySQL或SQLite，提供Web管理界面，适合不习惯手改配置文件的用户。
Radicale与Baikal：两个日历服务镜像怎么选
Radicale的容器镜像通常只有几十MB，启动后监听一个端口，所有配置都可以通过一个config文件和一个rights文件完成。它的优势在于足够透明：日历数据和用户权限直接对应文件系统上的路径，备份就是复制整个数据目录。默认情况下Radicale会把事件保存为.ics文件，每个日历一个文件，用文本编辑器打开就能看到原始数据。这种设计让迁移变得异常轻松，你甚至可以把整个数据目录打包后扔到另一台服务器上重新启动容器，所有日历立刻恢复。
但Radicale的Web界面比较简陋，几乎没有图形化的管理功能，创建用户、设置权限都需要编辑配置文件后重启容器。对于只需要一个日历后台、不经常变更用户结构的场景来说这完全够用。而Baikal提供了完整的Web后台，管理员登录后可以创建用户、分配日历、查看同步状态，甚至支持邀请码注册。Baikal默认使用SQLite数据库，也支持MySQL，但SQLite版本就已经能满足绝大多数个人和小团队需求，并且备份时只需要保留数据库文件和日历数据目录，同样简单。
从协议兼容性来看，两者都实现了标准的CalDAV和CardDAV，但Radicale对RFC的遵循更严格，在某些旧客户端上可能出现兼容性小问题，而Baikal得益于SabreDAV库的长期维护，兼容性通常更好。资源占用方面，Radicale运行时内存占用通常不到20MB，Baikal配合PHP-FPM和SQLite大约需要80到120MB内存。如果服务器本身就运行着其他PHP服务，Baikal可以利用已有的PHP环境；如果追求极致轻量，Radicale是明确的选择。
version: "3.8"
services:
radicale:
image: tomsquest/docker-radicale
container_name: radicale
restart: unless-stopped
ports:
- "5232:5232"
volumes:
- ./radicale_data:/data
environment:
- TZ=Asia/Shanghai
command: ["--config", "/data/config"]
上面的compose片段展示了Radicale最基本的部署方式。端口5232是Radicale的默认端口，数据卷挂载到宿主机的radicale_data目录。首次启动后容器会自动生成配置文件模板，你可以进入该目录修改config文件来调整认证方式、存储路径等。注意Radicale 3.x默认使用htpasswd文件管理用户，需要通过命令行工具生成密码哈希。
把协作套件整合进同一个Docker网络
如果团队需要的不仅是日历，还包括文件共享、在线文档、聊天等功能，单独部署一个日历服务就不够用了。Nextcloud是目前自托管协作领域最成熟的方案之一，它内置了日历、联系人、任务、文件同步等功能，并且完全支持CalDAV和CardDAV协议。Nextcloud的Docker镜像体积较大，但它把Apache、PHP、数据库都打包在一起，配合一个外部的MySQL或PostgreSQL容器就能快速启动。另外一个值得关注的选项是SOGo，它更偏重邮件和日历集成，适合已经搭建了邮件服务器的团队。
在Docker中部署Nextcloud时有一个关键决策：使用官方镜像还是LinuxServer.io维护的镜像。官方镜像更贴近上游发布，但需要自己处理cron任务、配置调整等细节；LinuxServer镜像则提供了更友好的环境变量和默认配置，适合新手。无论选择哪个，都建议把Nextcloud的数据目录和配置目录放在宿主机上，不要依赖容器内部存储。如果后续需要扩展或迁移，挂载卷是你唯一的保障。
version: "3.8"
services:
db:
image: mariadb:10.11
container_name: nextcloud_db
restart: unless-stopped
volumes:
- ./db_data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: your_root_password
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: your_db_password
app:
image: nextcloud:stable-apache
container_name: nextcloud_app
restart: unless-stopped
ports:
- "8080:80"
volumes:
- ./nextcloud_data:/var/www/html
environment:
MYSQL_HOST: db
MYSQL_DATABASE: nextcloud
MYSQL_USER: nextcloud
MYSQL_PASSWORD: your_db_password
depends_on:
- db
Nextcloud启动后，你需要在浏览器中完成初始化设置，然后进入日历应用。它会自动创建一个名为“个人”的日历，你可以在设置里获取CalDAV地址，格式通常为https://你的域名/remote.php/dav/。手机端添加CalDAV账户时输入这个地址和你的Nextcloud用户名密码即可开始同步。如果团队内部还使用邮箱，SOGo可以通过ActiveSync协议同步邮件、日历和联系人，不过SOGo的Docker部署相对复杂，需要同时运行memcached、数据库和SOGo本体三个容器。
数据持久化、备份与安全配置
日历和协作服务的核心价值在于数据，任何一次容器重建都不应该导致数据丢失。Docker的卷挂载机制让我们可以把数据统一放在宿主机目录下，但仅仅挂载还不够，定期备份才是防止误删、硬件故障的最后手段。对于Radicale，备份只需要复制整个数据目录；对于Baikal，需要同时备份SQLite数据库文件和日历数据目录；对于Nextcloud，除了文件数据，还需要导出MySQL数据库。你可以写一个简单的shell脚本配合cron定时执行，也可以使用更专业的备份工具如restic或borg。
安全方面有两个重点：认证和传输加密。日历服务默认可能使用HTTP明文传输，如果你的服务器暴露在公网上，必须通过反向代理启用HTTPS。常用的方案是Nginx或Caddy，Caddy可以自动申请Let's Encrypt证书，配置非常简洁。另外，日历服务的弱口令是常见入侵点，尤其是Radicale默认允许所有用户读写所有日历，务必在配置文件中限制访问权限。建议为每个用户设置独立的日历目录，并只允许用户访问自己的数据。
# 以root身份备份Radicale数据目录的简化脚本 #!/bin/bash BACKUP_DIR="/backup/radicale" DATA_DIR="/opt/docker/radicale_data" TIMESTAMP=$(date +%Y%m%d_%H%M%S) mkdir -p "$BACKUP_DIR" tar -czf "$BACKUP_DIR/radicale_$TIMESTAMP.tar.gz" -C "$DATA_DIR" . find "$BACKUP_DIR" -name "radicale_*.tar.gz" -mtime +7 -delete
这个脚本会把Radicale的数据目录打包成带时间戳的归档文件，并自动删除7天前的旧备份。你可以把它加入crontab每天凌晨执行。对于Nextcloud，官方推荐使用维护模式配合备份，避免在备份过程中数据被修改。操作顺序是先进入维护模式、备份文件和数据库、再退出维护模式。如果不方便进入维护模式，至少要在数据库低峰期进行，并且使用数据库的在线备份工具如mysqldump的--single-transaction参数保证一致性。
最后要提醒的是容器版本更新。日历服务偶尔会发布安全补丁，你需要关注镜像的更新情况。定期执行docker compose pull并重启容器可以快速升级。但升级前一定要确认数据目录的兼容性，尤其是大版本升级（如Radicale 2.x到3.x）可能需要调整配置文件。把升级操作放在测试环境验证后再应用到生产，能避免很多意想不到的故障。
常见问题排查与性能调优
部署完成之后，客户端很可能遇到同步失败、重复事件或者认证错误。最常见的问题是URL路径写错。Radicale的CalDAV地址通常是https://域名/用户/日历名/，而Baikal的地址则是https://域名/dav.php/calendars/用户/日历名/。可以在浏览器中直接访问这些地址，如果返回401认证框说明服务正常，如果返回404则需要检查服务器配置和路径大小写。另一个常见问题是时区设置不正确导致事件时间偏移，检查容器环境变量TZ是否设置为你所在的时区。
性能方面，轻量日历服务对CPU和内存的要求很低，瓶颈往往出现在数据库和磁盘IO上。如果使用SQLite作为Baikal或Nextcloud的数据库，当并发写入增多时可能会出现锁等待，导致同步变慢甚至超时。此时切换到MySQL或PostgreSQL是直接有效的解决方案。对于Nextcloud，启用PHP的OPcache和Redis作为缓存可以显著提升页面加载速度和API响应时间。在Docker中，你可以为Nextcloud添加一个Redis容器，并在配置文件中指定缓存和锁机制使用Redis。
如果团队规模超过几十人，建议把日历服务和协作平台拆分成独立的容器甚至独立的服务器，避免Nextcloud的重负载拖垮日历同步。同时考虑使用对象存储或分布式文件系统来保存大量附件，减轻本地磁盘压力。对于跨地域的团队，可以在多个地区部署只读日历副本，通过CalDAV的订阅功能实现单向同步，但要注意事件冲突的处理策略。
整个自托管过程中，Docker的角色更像一个打包和隔离工具，真正决定稳定性的还是你对协议、数据结构和网络架构的理解。从Radicale到Nextcloud，从单机备份到多容器协作，每一步都可以根据实际需求做取舍。自托管日历和协作平台并不复杂，但需要你花一点时间把认证、备份和更新这三件事做好。