calrs 2.0.0-beta.4: a tour of 2.0, and a call for testers

[olivierlambert]

calrs 2.0.0-beta.4 is out, and it is the last beta planned before a release candidate: everything agreed for 2.0 is now in. This thread is the place to tell us how it behaves on your instance. Below is a tour of what 2.0 brings compared with 1.23, then what we would most like you to test.

Release notes: https://github.com/olivierlambert/calrs/releases/tag/v2.0.0-beta.4
Docker: ghcr.io/olivierlambert/calrs:2.0.0-beta.4 (or :next). :latest stays on 1.23 until 2.0 is final.

Back up your database before upgrading, and keep the backup if you may want to go back to 1.23. Then read the upgrade notes in the release notes: a few behaviours changed on purpose (see the end of this post).

What's new in 2.0

Your calendars, wherever they live

• Microsoft 365 and Outlook.com, natively (Microsoft Exchange (EWS) replacement to Microsoft Graph API #229, feat: native Microsoft 365 / Outlook calendars via Microsoft Graph (#229) #290, by @adeg): busy times, write-back of bookings and per-calendar selection through Microsoft Graph, no CalDAV bridge needed.
• Organization-wide Exchange (Global Exchange (EWS) via Impersonation #138, by @huntervcx): an admin sets up one EWS service account with impersonation, and every user gets a managed busy-time source without entering a password. Only busy times are stored, and only for addresses the admin or the identity provider vouches for.
• Google out of office and Meet (Block Google out-of-office events #240, Fix Google Meet status checks and duplicate invitations #237, by @chetan): out-of-office events in Google Calendar block your slots, and guests without a Google account join Meet without waiting in the lobby.
• A write calendar per event type (feat: choose write-back calendar per event type (not just globally) #47): send the bookings of one meeting type to a calendar of its own (sales demos in one, interviews in another), each team member choosing their own.
• Sturdier sync: CalDAV and Exchange answers are read with a real XML parser (Switch to real XML parser #325, Move EWS SOAP parsing onto the shared XML parser #369), and background sync now copes with thousands of sources (Background sync: one source per minute does not scale to auto-provisioned Exchange sources #388).

For you and your guests

• New public pages (feat(ui): landing pages as a timetable, with next-free hints #406, Landing pages: sections, host facts, usual hours, one duration formatter; next-free removed #416): your page reads like a business card. Your photo, title and bio sit next to your usual hours ("Mon to Thu, 09:00 to 17:30"), where you are based and the languages you speak, and a "My time" button converts the hours to the visitor's timezone. Meetings are grouped in sections you name and order yourself, each showing its length, how you meet (video, phone, in person) and whether you confirm requests by hand.
• Booking questions (Important feature missing: Forms on the Bookingpage #210): ask guests what you need to know before the call (text, choices, a consent checkbox with a link to your policy). Answers show in your emails and your calendar event, and you choose which ones go into the calendar.
• Time off (feat: global "unavailable" override that propagates to all event types #46): block a holiday or a conference once, and every meeting type you host is closed for it, team round robins included.
• Private host notes (Add internal host-only booking notes (separate from guest notes) #173): notes on a booking that only its hosts see, never the guest.
• A guest email footer (SMS footer and/or templates #223): a short line of your own (legal mention, links) at the bottom of every email your guests receive.
• Lengths of time in your guests' language: "1 h 30", "2 Std.", "at least 1 day of notice", in all nine languages calrs speaks.

A dashboard you will want to open

• Redesigned dashboard and admin panel: your next meeting first, a week view, a sentence about your day, and every page laid out in cards with its search where you expect it.
• Ready for large instances (Booking directory: paginate or bound queries on large instances #340, Admin panel: paginate the users list and cache the overview figures on large instances #343, feat(web): server-side pagination for every growing dashboard list #415): bookings, meeting types, invite links, teams and the admin lists are paged and searched on the server, so an instance with thousands of users or bookings stays fast.
• Branding: a second logo for the dark theme (feat(branding): optional dark theme company logo (#356) #404, by @optimistic5), and embeds that can fix the 12h/24h format and show times in the event's own timezone (feat(embed): let the owner fix the time format and timezone #347, by @optimistic5).

For developers and automations

• REST API (Add minimal REST API for event types, slots and bookings #169): JSON under /api/v1 with personal access tokens or OAuth, an OpenAPI 3.1 document, and an interactive reference at /api/docs for signed-in users. Bookings created through the API can carry answers to booking questions (feat(api): send booking question answers with POST /bookings #398).
• Booking webhooks (Add outgoing webhooks for booking events (created, cancelled, rescheduled) #168): signed JSON POSTs on every booking change (created, confirmed, cancelled, rescheduled, claimed...), queued and retried in the background.
• MCP over HTTP with OAuth (Add MCP over Streamable HTTP with OAuth #273, by @chetan): connect an AI assistant to calrs to list your meeting types, read busy times or create invite links, never more than your account may do, and nothing that books, cancels or emails anyone.

Security

Outbound calendar requests now connect only to the addresses they checked (#363), X-Forwarded-For is believed only from trusted proxies, and the remaining items of the 2026 security audit are closed (#85).

Upgrading from 1.23: what changed on purpose

The full list is in the upgrade notes; the ones most likely to matter:

• Behind a reverse proxy? Caddy or Nginx on the same host or Docker network needs nothing. A proxy on a public address must be listed in CALRS_TRUSTED_PROXIES, and with nothing in front of calrs set CALRS_TRUSTED_PROXIES=none.
• Calendars on a private IP address (for instance http://10.0.0.5/) now need to be on the private-host allowlist (CALRS_ALLOW_PRIVATE_HOSTS or Admin panel, System settings), or they stop syncing.
• Webhooks and API tokens are admin-only by default. An admin can open them to every user with a switch in the admin panel.
• The SMS daily limit counts billed segments, not messages.

What we would love you to test

• Your calendar server: Microsoft 365, Exchange with impersonation, Google, Nextcloud, BlueMind, Fastmail, iCloud... Does sync keep up, do bookings land in the right calendar, do cancellations remove them?
• The upgrade itself, on a copy of a real 1.23 database: did anything look wrong after the migrations?
• The new public pages in your language, on a phone and on a large screen.
• Large instances: if you have many users or bookings, how do the dashboard and admin pages feel?
• The API, webhooks and MCP, if you automate anything around your calendar.

@adeg, @chetan, @huntervcx, @optimistic5: your features shipped in this beta. If you can run it against your own setups, your feedback is the most valuable we can get.

How to report

Reply in this thread with what you tried and what happened, or open an issue for anything that looks like a bug. Please include your calrs version (shown at the bottom of the sidebar), how you run it (Docker or binary) and your calendar server, plus relevant log lines. Logs never need to include passwords or tokens: remove them if you see any.

Thanks to everyone who has tested the betas so far!

[chetan]

@olivierlambert I've already tested MCP support on the latest build and it looks great so far. Oauth worked well and I ran some smoke tests from my agent, no issues so far. Will test Google meet and calendar changes and let you know if I see any issues.

[huntervcx]

double tests : one direct one exchange 2019 and one to exchange via an sso from authentik (ldap on the active directory linked to exchange)

Fresh install (112 migrations) and upgrades beta.2 → beta.4 and beta.3 → beta.4: OK, data kept, pre-existing users start untrusted, calrs user trust-email works (exit 1 for an unknown address).

beta.3 → beta.4 delta: a new SSO user with email_verified=false still gets HTTP 500 + a generic page (reason only in logs). After a server/endpoint change, existing bookings now keep their link to the Exchange event (cancel still removes it), but after “Remove managed sources” the link is still lost, as documented.

SSO (Authentik, email_verified driven by a user attribute through a scope mapping): true ⇒ trusted + provisioned; false ⇒ trust dropped and source deleted; claim absent ⇒ admin confirmation kept while the address is unchanged; address change handled; a verified IdP owner takes a shared mailbox over from an admin-confirmed holder (“Taken over from” shown).

No issues, so everything lgtm 👍

[optimistic5]

Tested beta.4 on a real instance: Docker, behind a Cloudflare Tunnel, one CalDAV source (Baikal), 2 users, SMTP through Resend.

Upgrade path: 1.22.0 to 2.0.0-beta.3 to 2.0.0-beta.4. Each hop ran first on a restored copy of the production database, then on the real one.

• All migrations applied cleanly each time: 28 from 1.22.0 to beta.3, then the 8 new ones. No errors or panics in the logs, and PRAGMA integrity_check is ok.
• After the upgrade the container is healthy with no restarts, and the CalDAV sync completes without errors.
• SMTP from env still applies, and the embed page (?embed=1) still renders. I keep a small template override for it.
• Guest footer (SMS footer and/or templates #223 / feat(email): guest email footer with admin default (#223) #350): tested end to end on a throwaway event type. The footer is in the confirmation email, and the cancel link from the email still works.

A note for people who proxy calrs: 2.0 adds routes that should not be public on a site that is otherwise a guest booking page: /api/* (including /api/docs), /mcp, /oauth/* and /.well-known/*. They are token- or login-protected, but I put an allowlist in front: only /u/*, /booking/*, /t/* and the page assets are reachable without authentication. It might be worth a short note in the upgrade notes or the reverse-proxy docs.

Thanks for the release.