Skip older Cal packages

[james]

Hello @jdaviescoates

@jdaviescoates said:

Just to say, personally rather than doing this, I tend to just spin up a new server with the new version on and then restore the back-up to the new server. Quicker and less prone to issues imho but also not always an option.

Indeed, that is another way of doing this avoiding the whole do-release-upgrade and the rats tail that might be attached to it.
I think adding this path to Upgrading to Ubuntu $VERSION documentations is a good idea.
With the Dry run restore when taking this path you can also ensure that everything is working as intended reducing possible downtimes.

[jdaviescoates]

@james said:

With the Dry run restore when taking this path you can also ensure that everything is working as intended reducing possible downtimes.

Exactly

[tom.westphal]

Hi again,
Quick update: I've now upgraded Cloudron to 9.2.0 and Ubuntu to 24.04 as suggested. Thank you for the guidance — that all went smoothly.
However, the Cal.com 1.14.13 update issue persists even on the fully updated stack. I did some deeper debugging today and wanted to share my findings in case it helps others or the Cloudron team.
Environment:

Cloudron 9.2.0
Ubuntu 24.04
Cal.com package 1.14.13 (Cal.com 4.7.16)

Findings:

Inside the container, curl http://localhost:3000/[username] returns 200
Via nginx proxy, curl https://meet.[company].tools/[username] returns 404
The user exists in the database (confirmed via psql)
The .next build is located at /app/code/apps/web/.next/ and appears complete
The routes-manifest.json correctly contains https://meet.[company].tools
The HTML response reveals Cal.com 1.14.13 now uses the Next.js App Router (data-nextjs-router="app"), whereas 1.14.12 used the Pages Router
The response body shows the /:username route resolves to a 404 notFound component — even though the user exists in DB
The middleware-manifest.json has no matcher for /:username

Conclusion:
The 404 is served by Cal.com itself (not nginx). The App Router in 1.14.13 appears to not correctly resolve public user booking pages (/username), even when the user exists. This seems to be a regression in the Cloudron package for 1.14.13.
I've rolled back to 1.14.12 for now. Any guidance on how to proceed to eventually reach the latest Cal version would be greatly appreciated.
Thanks!

[james]

Hello @tom.westphal
If the old version 1.14.13 is creating the issue, did you try updating past that?
Since the current version is 2.13.0 this issue might have already been resolved by a later update.
You can always clone the app from a backup and then update the clone to see if it resolves.
This way the production one keeps running.

[tom.westphal]

Hi,
just wanted to say thank you — your advice to simply update past 1.14.13 was spot on! I cloned the app from a backup and kept updating step by step. The 404 issue resolved itself after moving past 1.14.13.
Really appreciate the quick and helpful response!
Thanks!

[james]

Hello @tom.westphal
Great to read that it worked out.
Just keep Cloudron, Ubuntu (next EOL) and the apps updated and it should run smoothly.

[tom.westphal]

Hi again,
another update on my end. After identifying the root cause of the email delivery failures (Google Calendar API rate limit — 403 rateLimitExceeded on createEvent calls), I've been trying to set up Domain-Wide Delegation to fix this properly.
I've already completed all the Google-side steps:

Created a new Google Cloud project (cal-com-*****)
Enabled the Google Calendar API
Created a service account with DWD enabled
Authorized the service account in Google Workspace Admin Console
Downloaded the JSON key file

However, I'm hitting a wall on the Cal.com side. The UI route /settings/organizations/platform/delegation-credentials returns "subscription needed", and calling the API v2 endpoint directly returns a 500 Internal Server Error:
POST /api/v2/organizations/1/delegation-credentials
→ HTTP 500 Internal Server Error
Current setup: Cloudron package 2.8.4, Cal.com 5.8.6. Auto-updates are running but after so many versions to catch up on, progress is slow — so any guidance on whether this will be supported in a future Cloudron package would be really helpful before waiting through dozens more updates.
My questions:

Is DWD supported in the Cloudron Cal.com package, and if so, from which version?
Is the /api/v2/organizations/{orgId}/delegation-credentials endpoint available in the self-hosted Cloudron version?

Thanks in advance!

[james]

@tom.westphal
The message subscription needed is a red flag.
Do you have a @cal.com subscription?

[tom.westphal]

No, we don't have a Cal.com subscription — we're fully self-hosted via Cloudron. The "subscription needed" message appears in the UI, but since we're self-hosted I assumed this shouldn't apply. Is DWD simply not available in the Cloudron package without a Cal.com cloud subscription, or is there a way to enable it on self-hosted?

[jdaviescoates]

@tom.westphal said:

Is DWD simply not available in the Cloudron package without a Cal.com cloud subscription

Very likely.

As I understand it, the self hostable open source version isn't even maintained by Cal.com themselves anymore, and even before that some features were behind a paywall.

[tom.westphal]

Thanks for the confirmation! That makes sense — good to know DWD won't be coming to the self-hosted version.
In the meantime I found a workaround via the Node.js Inspector that patches the gaxios retry logic at runtime to also retry on PATCH requests and 403 errors. Running it via a cronjob so it auto-reapplies after restarts. Will see over the next few days if it holds up.