8 phút đọc
Trong kỷ nguyên làm việc hybrid, việc phải quản lý cùng lúc nhiều loại lịch trình—từ lịch cá nhân, lịch công việc tại công ty cho đến lịch điều hành dự án riêng—đã trở thành cơn ác mộng với không ít người. Sự chồng chéo lịch hẹn không chỉ gây phiền toái mà còn làm giảm uy tín cá nhân. Để giải quyết triệt để bài toán này, nhà phát triển ridafkih đã cho ra mắt Keeper.sh, một công cụ đồng bộ hóa lịch trình mã nguồn mở mạnh mẽ và là một máy chủ MCP (Model Context Protocol) toàn diện. Dự án hiện đã thu hút được 1.252 stars và 45 forks trên GitHub, viết hoàn toàn bằng TypeScript và vừa có bản cập nhật mới vào ngày 19/08/2026.
Giải pháp đồng bộ lịch toàn diện từ nỗi đau thực tế của nhà phát triển
Tác giả của Keeper.sh chia sẻ rằng dự án này ra đời xuất phát từ chính nhu cầu thực tế của bản thân. Kể từ khi khởi động dự án Sedna (nền tảng quản trị AI), anh đã phải làm việc trên ba cuốn lịch khác nhau: một cho doanh nghiệp, một cho công việc chuyên môn và một cho cá nhân. Tình trạng các cuộc họp đè lên nhau diễn ra với tần suất cao đến mức gây ức chế. Khi tìm kiếm các giải pháp thay thế trên thị trường, tác giả liên tục vấp phải hai rào cản lớn: các sự kiện bị xóa ở lịch nguồn vẫn tồn tại vĩnh viễn ở lịch đích, và không có cách nào tiếp cận mã nguồn để kiểm tra cách dữ liệu lịch trình nhạy cảm của mình được xử lý.
Keeper.sh được thiết kế để giải quyết trọn vẹn cả hai vấn đề này dưới giấy phép mã nguồn mở tự do AGPL-3.0. Công cụ cho phép người dùng kéo các sự kiện từ Google Calendar, Outlook, iCloud, Fastmail, máy chủ CalDAV hoặc các liên kết iCal/ICS từ xa, sau đó đẩy chúng tới một hoặc nhiều lịch đích để sắp xếp các khoảng thời gian trống đồng nhất trên tất cả các nền tảng.
Cơ chế vận hành thông minh và an toàn dữ liệu
Điểm độc đáo của Keeper.sh nằm ở cơ chế theo dõi và dọn dẹp sự kiện thông minh. Các sự kiện do Keeper.sh tạo ra ở lịch đích sẽ được đánh dấu bằng cách thêm hậu tố @keeper.sh vào UID từ xa. Đối với các nền tảng không hỗ trợ UID tùy chỉnh như Outlook, công cụ sẽ xếp sự kiện vào một danh mục riêng mang tên “keeper.sh”.
Khi có một sự kiện bị xóa ở lịch nguồn, Keeper.sh sử dụng một dòng ánh xạ (mapping row) có tuổi thọ lâu hơn chính sự kiện đó để theo dõi. Nhờ vậy, bản sao trên lịch đích vẫn sẽ bị xóa bỏ trong lượt đồng bộ tiếp theo. Quan trọng hơn, trình dọn dẹp của hệ thống chỉ can thiệp vào những sự kiện do chính Keeper.sh tạo ra, hoàn toàn không chạm đến bất kỳ sự kiện nào do người dùng tự tay thiết lập.
Hệ thống đồng bộ của Keeper.sh hoạt động thông qua hai tiến trình chạy trên các lịch trình độc lập:
- Ingestion (Nạp dữ liệu): Tiến trình này kéo dữ liệu từ các nguồn về cơ sở dữ liệu riêng của Keeper.sh với tần suất 1 phút/lần cho mọi gói dịch vụ. Với Google và Outlook, hệ thống sẽ tải tăng cường (incremental) bằng cách sử dụng sync token và delta link của chính nhà cung cấp, nghĩa là mỗi lượt chạy chỉ yêu cầu những thay đổi phát sinh kể từ lần quét cuối cùng. Với CalDAV, iCloud, Fastmail và các liên kết ICS, hệ thống sẽ tải lại và thực hiện so khớp (diff) với trạng thái đã lưu.
- Pushing (Đẩy dữ liệu): Tiến trình này sẽ đồng bộ hóa dữ liệu tới các lịch đích. Tần suất đẩy dữ liệu được quyết định bởi gói dịch vụ (1 phút/lần đối với bản Pro/Self-host và 30 phút/lần đối với tài khoản miễn phí trên Cloud). Quá trình này sử dụng cơ chế kiểm tra định kỳ (polling) từ phía máy chủ của Keeper.sh thay vì nhận thông báo đẩy từ nhà cung cấp, giúp hệ thống hoạt động ổn định mà không cần mở cổng kết nối từ bên ngoài vào thực thể (instance) của bạn.
Tác vụ đồng bộ cũng có thể được kích hoạt thủ công thông qua API
POST /api/v1/synchoặc lệnhtrigger_syncqua giao thức MCP, giúp rút ngắn thời gian chờ đợi nhưng vẫn được giới hạn tối đa 1 yêu cầu/phút cho mỗi người dùng để tránh làm nghẽn máy chủ dịch vụ của bên thứ ba.
Khả năng tích hợp AI thông qua MCP Server
Không chỉ dừng lại ở một công cụ đồng bộ thông thường, Keeper.sh còn hoạt động như một máy chủ MCP (Model Context Protocol) toàn cầu. Điều này mở ra khả năng tương tác mạnh mẽ với các trợ lý AI (AI agents). Người dùng hoặc các tác nhân AI có thể dễ dàng truy vấn, quản lý và kiểm soát toàn bộ hệ thống lịch trình tích hợp từ một giao diện API duy nhất, biến Keeper.sh thành một trợ lý ảo quản lý thời gian thực thụ.
Lựa chọn triển khai: Cloud-hosted hay Self-hosted?
Nhà phát triển cung cấp hai lộ trình tiếp cận rõ ràng cho người dùng:
- Bản Cloud-hosted (keeper.sh): Đây là phiên bản được khuyến nghị cho hầu hết người dùng, kể cả những người có khả năng tự vận hành kỹ thuật. Với mức phí 5 USD, bạn sẽ có toàn bộ tính năng mà không cần lo lắng về việc duy trì máy chủ, cấu hình tên miền, cập nhật phiên bản, sao lưu dữ liệu hay tự đăng ký ứng dụng xác thực OAuth với Google và Microsoft. Bản miễn phí trên Cloud giới hạn tối đa 2 tài khoản kết nối và 3 ánh xạ đồng bộ (sync mapping).
- Bản Self-hosted (Tự vận hành): Đây là một lộ trình được hỗ trợ chính thức và không có sự phân biệt đối xử. Khi tự vận hành, bạn mặc định sở hữu toàn bộ các tính năng của gói Pro mà không phải trả phí thuê bao định kỳ. Hệ sinh thái tự vận hành cung cấp 7 image Docker khác nhau, trong đó khuyến nghị sử dụng
keeper-standaloneđặt sau một reverse proxy để tối giản hóa các thành phần chuyển động. Môi trường phát triển nội bộ được chạy dưới giao thức HTTPS thông qua Caddy reverse proxy tại địa chỉhttps://keeper.localhost, tự động phân giải về IP 127.0.0.1 theo chuẩn RFC 6761 mà không cần chỉnh sửa tệp hosts.
Tuy nhiên, việc tự vận hành đòi hỏi bạn phải tự trang bị máy chủ, tên miền, thiết lập sao lưu và tự tạo các ứng dụng Google OAuth/Microsoft OAuth để cấp quyền truy cập các phạm vi bảo mật như calendar.events hay userinfo.email.
Những điểm cần lưu ý thêm
Mặc dù tài liệu kỹ thuật của Keeper.sh mô tả rất chi tiết về kiến trúc đồng bộ hóa hai nửa (Ingest/Push) và cơ chế dọn dẹp an toàn, người dùng vẫn cần lưu ý một số điểm mà tài liệu hiện tại chưa làm rõ. Cụ thể, hiệu năng thực tế và độ trễ của hệ thống khi phải xử lý đồng thời hàng chục lịch trình có mật độ sự kiện dày đặc chưa được công bố chi tiết. Ngoài ra, tài liệu cũng chưa đề cập sâu đến cách hệ thống xử lý các xung đột phức tạp hơn—ví dụ như khi một sự kiện bị chỉnh sửa đồng thời ở cả lịch nguồn và lịch đích trong cùng một khoảng thời gian ngắn trước khi tiến trình đồng bộ diễn ra. Người dùng tự vận hành cũng được khuyến cáo nên ghim (pin) các image Docker ở một phiên bản cụ thể (ví dụ: tag 2.13) thay vì sử dụng tag latest để tránh các lỗi không tương thích đột ngột khi cập nhật.
Nguồn tham khảo: Xem bài gốc
