keeper.sh
Keeper.sh is an open-source calendar aggregation and sync tool that pulls events from multiple calendar sources (Google, Outlook, iCloud, CalDAV, ICS) and synchronizes them across destinations. It also functions as an MCP (Model Context Protocol) server for AI agent integration and is designed to be self-hosted or used via a paid cloud tier.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | ridafkih/keeper.sh |
| Owner | ridafkih |
| Primary language | TypeScript |
| License | AGPL-3.0 — OSI-approved |
| Stars | 1.2k |
| Forks | 38 |
| Open issues | 82 |
| Latest release | v2.12.0 (2026-06-30) |
| Last updated | 2026-07-06 |
| Source | https://github.com/ridafkih/keeper.sh |
What keeper.sh is
TypeScript/Bun-based service with a React web frontend, PostgreSQL backend, Redis queue, and microservice architecture (API, web, MCP, cron, worker). Uses event UID mapping and metadata flags to track synced events across providers and detect stale or orphaned calendar entries for cleanup.
Get the keeper.sh source
Clone the repository and explore it locally.
git clone https://github.com/ridafkih/keeper.sh.gitcd keeper.sh# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- AGPL-3.0 license requires legal review for commercial or network-service use; modifying or hosting for others triggers copyleft obligations.
- Self-hosting mandates Bun v1.3.11+, Docker, Docker Compose, PostgreSQL, Redis, and TLS certificate management (Caddy reverse proxy included).
- Event sync logic relies on UID-based mapping and provider-specific metadata (suffix `@keeper.sh` or category flags); non-standard calendar fields may require custom logic.
- Free tier limited to 2 sources and 1 destination; production use typically requires $0 self-hosted or $5/month cloud Pro plan.
- 82 open issues indicate active development; latest release v2.12.0 dated 2026-06-30 with final push 2026-07-06 (stable but monitor for breaking changes).
When to avoid it — and what to weigh
- Proprietary software requirements — AGPL-3.0 licensing requires any modifications or network service use to release source code; not suitable for closed-source derivative work without review.
- Minimal operational overhead — Self-hosted deployment requires PostgreSQL, Redis, Docker Compose, and active infrastructure management; cloud tier available but adds subscription cost.
- Enterprise SLA/support expectations — Single-maintainer open-source project with 82 open issues and no stated SLA, incident response, or commercial support team.
- Calendar-agnostic real-time event capture — Free tier syncs every 30 minutes; Pro (self-hosted or cloud) syncs at 1-minute intervals. Real-time webhooks or sub-minute cadence unknown.
License & commercial use
AGPL-3.0 (GNU Affero General Public License v3.0). Requires source disclosure if modified or deployed as a network service. Use for internal, unmodified deployments is generally permissible; commercial or SaaS use, or derivative products, require legal review.
AGPL-3.0 imposes copyleft obligations on network services and modifications. Internal deployment and use (self-hosted, unmodified) likely permissible, but commercial resale, SaaS offerings, or closed-source integrations require attorney review. Cloud-hosted tier (keeper.sh) offered by maintainer as a compliant commercial option.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | High |
| DEV.co fit | Good |
| Assessment confidence | High |
Project handles OAuth credentials, calendar API tokens, and event data from multiple providers. No explicit security audit, penetration test, or vulnerability disclosure policy stated in provided data. AGPL source availability aids peer review but does not guarantee secure implementation. Self-hosted deployments inherit responsibility for PostgreSQL, Redis, and network security. TLS via Caddy in dev environment; production TLS configuration depends on deployment method.
Alternatives to consider
Zapier/IFTTT
Managed, no-code calendar automation with no infrastructure overhead; lacks fine-grained event sync control and MCP/AI integration.
CalDAV server (e.g., Nextcloud, Radicale)
Open-source, self-hosted calendar server; focuses on unified CalDAV endpoint rather than cross-provider aggregation and sync.
Google Calendar delegation + manual sync
Built-in, zero-cost; limited to Google ecosystem and no automation; does not solve multi-provider or AI agent access.
Build on keeper.sh with DEV.co software developers
Assess feasibility by reviewing AGPL-3.0 compliance, estimating self-hosted infrastructure, and testing multi-provider sync in a staging environment. Contact Devco for enterprise deployment guidance.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
keeper.sh FAQ
Can I use Keeper.sh commercially without legal review?
What is the minimum self-hosted infrastructure?
How are calendar events tracked across syncs?
Does Keeper.sh support real-time sync?
Software development & web development with DEV.co
From first prototype to production, DEV.co delivers software development services around tools like keeper.sh. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source devops and beyond.
Evaluate Keeper.sh for Your Calendar Stack
Assess feasibility by reviewing AGPL-3.0 compliance, estimating self-hosted infrastructure, and testing multi-provider sync in a staging environment. Contact Devco for enterprise deployment guidance.