SYNCDATE vs Keeper: Features, Pricing & Architecture Compared

> Quick Answer: Both are real calendar sync engines. SYNCDATE reacts to provider push notifications, so a change lands on the other calendar in roughly 4 seconds. Keeper refreshes on a fixed schedule — its published table lists 30 minutes on Free and 1 minute on Pro and self-hosted. Keeper is AGPL-3.0 and you can run it yourself; SYNCDATE is managed SaaS with two-way CalDAV. Pick on those two axes, not on feature counts.

SYNCDATE and Keeper are the two most architecturally similar tools in this category. Both connect calendars over OAuth, both speak CalDAV, both strip event details to busy blocks by default, and both are built around a sync engine rather than a scheduling suite. Keeper describes itself as "a pull-compare-push sync engine" and uses incremental sync tokens for Google and Outlook — the same technique SYNCDATE uses.

So this comparison is not "real sync tool versus feed aggregator." It is a comparison of two competent engines that made two different bets: push versus pull, and managed versus self-hosted.

> Correction (July 2026): an earlier version of this article described Keeper as an iCal/ICS feed aggregator and understated its Pro price. Both were wrong. Keeper is a full OAuth + CalDAV read/write sync engine, and Pro is $5/month. We have rewritten this page against Keeper's own documentation and repository.

What Keeper actually is

Keeper (keeper.sh) is an open-source calendar sync tool built by Rida F'kih, licensed AGPL-3.0, with the source on GitHub. It is actively developed — the most recent release at the time of writing was v2.12.2 on 11 July 2026.

Its documentation lists four connector types:

On direction, Keeper's own documentation is precise: "iCal feeds are pull-only. OAuth and CalDAV calendars support both" — that is, a Google, Outlook or CalDAV calendar can act as a source and as a destination. It also states that "a single source can push to multiple destinations. A single destination can receive from multiple sources."

What SYNCDATE is

SYNCDATE is managed SaaS. It connects to Google Calendar and Microsoft Outlook over their APIs, and to iCloud, Fastmail and Nextcloud over CalDAV — all two-way. iCal feed URLs are supported as read-only sources.

The distinguishing design choice is that SYNCDATE does not run on a schedule as its primary path. It registers for Google Calendar push notifications and Microsoft Graph change notifications, so the provider tells us the moment something changes. A 15-minute poll runs behind that as a safety net, because Google itself warns that "notifications are not 100% reliable. Expect a small percentage of messages to get dropped under normal working conditions."

Push versus pull: the real difference

This is the axis that matters, and it is worth being precise about what each vendor claims.

The Keeper column comes from Keeper's own pricing table and homepage ("Every 30 minutes" / "Every 1 minute"). The ~4-second figure is SYNCDATE's own published propagation time. Both tools also ship an MCP server so you can connect an AI client: Keeper's published tools are read-focused (list_calendars, get_events, get_event_count, over OAuth 2.1), while SYNCDATE's MCP also writes — it can create, update and delete events and manage syncs — on paid plans.

We also read Keeper's repository to understand the mechanism, and want to be clear that this part is our inference rather than a vendor statement: the only webhook route in the codebase handles billing (Polar), there are no Google push channels or Microsoft Graph change-notification subscriptions, and the sync job is declared as a cron poll. The one real-time element is a WebSocket that streams sync progress to the dashboard. That is consistent with the published refresh intervals.

When the interval matters

If a tool reads your calendar to offer bookable slots — Calendly, Cal.com, or a colleague eyeballing your free/busy — the question is how stale the mirrored copy can be. On Keeper Pro that window is about a minute, which is fine for most people. On the Keeper free tier it is up to half an hour, which is long enough to hand out a slot you have already filled and cause a double booking.

If you want a longer explanation of why push and pull behave differently, we wrote one: how calendar sync works.

When it doesn't

Plenty of workflows do not care. If you are mirroring a work calendar into a personal one so evenings look blocked, a 30-minute lag changes nothing. Do not pay for latency you will not notice.

Privacy: the same default, different guarantees

Both tools hide event details by default, and both say so plainly.

Keeper: "By default, only busy/free time blocks are shared. Event titles, descriptions, locations, and attendee lists are stripped before syncing." Keeper also documents "encrypted credentials at rest: CalDAV passwords and OAuth tokens encrypted with configurable key."

SYNCDATE shows synced events as "Busy" unless you deliberately turn on detail copying for a sync. OAuth tokens are encrypted at rest with AES-256-GCM, and the service runs on Hetzner infrastructure in Germany, inside the EU.

The meaningful difference is not the default — it is what backs it. With Keeper you can read the code that implements the default, and if you self-host, the data never leaves your machine. With SYNCDATE you are trusting a hosted service and its published infrastructure description. For a security team that requires source review or on-premises data residency, that is a decisive difference in Keeper's favour.

Open source and self-hosting

Keeper ships a standalone Docker image, ghcr.io/ridafkih/keeper-standalone:2, which its README describes as containing "the cron, worker, web, api services as well as a configured redis, database, and caddy". Keeper states that "self-hosted instances get Pro-tier features by default" and that "by hosting Keeper yourself, you get all premium features for free."

That is a genuine advantage and we are not going to talk around it. SYNCDATE is not open source and cannot be self-hosted. If auditability, forking, or data sovereignty is a requirement, Keeper is the tool between these two.

What self-hosting costs you is the usual: a server, a domain, updates, backups, and being the person who gets paged when it stops. For a developer comfortable with Docker that is an evening. For someone who wants calendar sync to be someone else's problem, it is the wrong trade.

As Peer Richelsen, co-founder of Cal.com, put it about the open-source scheduling ecosystem: "Governments, healthcare, and other highly regulated industries not only prefer but are often required to self-host, which open source makes possible in the most secure and trusted manner." — Peer Richelsen, Co-founder of Cal.com (Cal.com Blog)

Pricing

Keeper

Keeper's published free-tier limits are "2 linked accounts, 2 calendars per account, 30-minute sync intervals, aggregated iCal feed."

SYNCDATE

Annual billing is two months free on both paid plans. Prices are charged in EUR (USD equivalents are $8.99 and $16.99); see the pricing page for the live figures in your currency, and the calendar sync pricing guide for the wider market.

Which is cheaper

At the free end the two are close and the shape differs: Keeper gives you 2 accounts with 2 calendars each on a 30-minute refresh; SYNCDATE gives you 2 accounts and 2 calendars in one sync, event-driven. At the paid entry point, price isn't the deciding input either way — pick on push-vs-poll sync and managed-vs-self-hosted. And self-hosted Keeper costs nothing at all, if your own time is also free.

Where the money question actually turns is scale. SYNCDATE Pro covers 20 connected accounts and 100 calendars for €16.99/month. Keeper's published limits describe its free tier; check their current pricing page for what Pro allows before you plan around it.

Self-hosting Keeper: what it involves

If you are weighing the self-hosted route, here is the shape of it based on Keeper's README.

You run ghcr.io/ridafkih/keeper-standalone:2, which brings up the web app, API, cron scheduler, background worker, Redis, database, and a Caddy reverse proxy behind a single port. On first run it generates an environment file with session and encryption keys.

What you need:

• A server or VPS with Docker
• A domain name, for HTTPS via Caddy
• Comfort with Docker and environment variables

What you own afterwards:

• Uptime and monitoring
• Updates and security patches
• Backups
• Scaling, if it ever comes to that

Caddy handles certificates automatically in the common case, so the ongoing burden is mostly patching and backups. Note that the pinned tag is :2 — the separate component images use :latest, but the standalone convenience image does not.

Who should choose SYNCDATE

• You want changes to land in seconds rather than on the next scheduled pass
• You want two-way sync across Google, Outlook, iCloud, Fastmail and Nextcloud without running anything
• You need scale: up to 20 connected accounts and 100 calendars on one plan
• You want EU-hosted infrastructure with published encryption details and no servers of your own
• You want someone else on call when a provider changes an API

Who should choose Keeper

• You want source code you can audit, fork, or hand to a security reviewer
• You want to self-host, and the free-forever Pro-grade self-hosted tier is worth an evening of setup
• A one-minute refresh interval is fast enough for your workflow
• You are on Keeper's free tier and 30-minute freshness genuinely does not bother you
• You want zero recurring SaaS spend and already run infrastructure

Both defaults protect your event details. That is not the deciding factor here — speed, hosting model, and scale are.