Self-host or hosted
Self-host it, or let us run it
The worst way to find out that a product has a paid tier is to hit it. So here is the whole picture, including the part that is not in the repository.
Every sync feature is in the free version
MT-CalSync's engine is AGPL-3.0, and it is not a reduced community edition. Both providers, both directions, recurring events, all-day events, shared calendars, full-detail and busy-block fidelity, the provenance stamping that stops mirrors echoing, the stamp-verified teardown, the dead-letter queue, the admin portal and the command-line worker. It is .NET 8 and MySQL, it runs happily on a small VM, and this site runs the same engine, built from the source you can download.
We do not withhold sync features, for a straightforward reason: withholding them is what gets a project forked, and we do not need to. The hosted product has something a self-hoster cannot install their way out of.
What you actually pay for
A machine that is awake when yours is not. Sync is only worth having if it happens while you are asleep, on a flight, or moving between laptops. Self-hosting means a server that stays up, a database, TLS, backups and upgrades, for a job whose entire value is that it runs unattended.
OAuth apps you do not have to register. This is the part people underestimate. To self-host you create your own Google Cloud project and OAuth consent screen and your own Microsoft Entra app registration, keep two sets of client secrets alive, and, if you want the Google consent screen to stop warning your own users, take your app through Google's verification review, demo video and all. Ours are already registered and maintained. Google's review of ours is still to come, so until it clears, Google's consent screen shows a notice that the app is unverified.
| Self-hosted | Hosted | |
|---|---|---|
| Two-way and one-way sync | Yes | Yes |
| Recurring, all-day and shared calendars | Yes | Yes |
| Full detail or busy blocks, per pair | Yes | Yes |
| No attendees, no notifications, ever | Yes | Yes |
| Stamp-verified teardown | Yes | Yes |
| Secrets encrypted at rest | Yes | Yes |
| Runs while your machine is off | Only if you rent a server | Yes |
| Google and Microsoft apps registered and maintained | Yours to create and maintain | Yes |
| Upgrades, backups and TLS | Yours to run | Yes |
| Someone watching for an expired token | No | Yes |
| Price | Free, for ever | $4/month |
What is not in the repository
The shop, not the product. Sign-up, subscriptions, card handling, the trial clock and the transactional email around them live in a private layer that sits beside the engine and is not published. None of it touches a calendar, and none of it is a sync feature being kept back: a self-hoster has no use for a billing system that charges them on our behalf.
The seam between the two is deliberately narrow: two interfaces. One asks whether a pair is
allowed to run, and the open-source build answers "always". The other decides who is told when a
connection breaks and how, and the open-source build sends a plain alert to the operator. That
is the whole of it. If you want to see where the line falls, both are in
SyncSeams.cs in the code you can download.
Moving either direction is real
The hosted product runs the same assemblies as the download, a different composition root, not a different build. So starting self-hosted and moving to us is not a migration onto a different product, and leaving us for your own box is not an escape hatch we have quietly made impractical. Both sides talk to the same calendars through the same code.