Cloudron Forum

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.

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?

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!

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!

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!

Hi, thank you so much for the detailed breakdown – this is exactly what I needed! It's great to have a clear step-by-step path forward.
I'll follow your guide and work through the upgrades carefully. Good to know about the backup configuration file – I'll make sure to secure that before doing anything else.
For now I'll try to handle this myself, but I'll definitely keep the partner support option in mind in case I run into trouble. I'll report back once I've gone through the steps!

First of all, thank you so much for your detailed and helpful answers!
I recently gained access to our company's server and I'm trying to tidy things up. There have been over a hundred notifications on the Cloudron dashboard that had been ignored for a long time. I'm working on getting everything up to date, but since I don't have much practical experience and am fairly new to server administration, I'm being rather cautious and taking things step by step.
Based on your feedback, I now understand the correct order of operations. My plan going forward is:

Upgrade Cloudron to the latest version first
Then upgrade Ubuntu 20.04 to 22.04 (or 24.04)
Then sequentially update Cal.com through each package version

Could you advise whether it is safer to upgrade Cloudron first or Ubuntu first? And is there anything specific I should watch out for given that Cal.com booking pages are currently breaking on update to 1.14.13?
Thank you again for your patience with a newcomer!

Hi everyone,
I'm running Cal.com on Cloudron and I'm trying to update to the latest package version (2.13.0 / Cal.com 6.2.0) but I'm running into issues. I'd appreciate any help.
Current setup:

Cloudron version: 9.0.17
Cal.com package version: 1.14.12 (Cal.com 4.7.14)
Server: Ubuntu 20.04 on Hetzner

The problem:
We are experiencing intermittent email delivery failures. Booking confirmations are only sent to attendees in roughly 90% of cases — the other 10% never arrive. The issue is not consistently reproducible. We are hoping that updating to the latest package might resolve this.
What we tried:
The Cloudron update button only offers us package 1.14.13 (Cal.com 4.7.16) as the next step — not 2.13.0 directly. We tested updating to 1.14.13 multiple times today, but every time the public booking pages returned a 404 error after the update (e.g. meet.example.com/username/30min). We had to restore from backup each time.
Questions:

Is it possible to skip directly from 1.14.12 to 2.13.0? If so, how?
Is there a known issue with package 1.14.13 breaking public booking pages (404 on /username/eventslug)?
Are there any additional manual steps required for the 2.x major update beyond the new API subdomain?

Thank you in advance!