Skip older Cal packages

[tom.westphal]

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!

[james]

Hello @tom.westphal

I understand your predicament.
Taking over a black-box which you had no access to before is always a struggle.

Ensure Cloudron Backups are working and you have the encryption password

Cloudron Documentation: backups

The first thing you should do is ensure that the Cloudron backup is working correctly.
If the Cloudron backup configuration has an encryption password configured, make sure you have that encryption password.
Otherwise, restoring from a Cloudron backup is not possible, since without the encryption password Cloudron will not be able to decrypt the backup.
If no encryption password is set you can ignore this.

Create a full Cloudron backup from the dashboard and download the backup configuration of the just created backup.
Save this file to your computer and make sure it is saved in a place where you remember it.
In case anything breaks, you can restore the full Cloudron server with this downloaded configuration file.

Upgrade Ubuntu 20 to 22

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-22

If everything worked out upgrade to 24

Upgrade Ubuntu 22 to 24

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-24

If everything worked out, perfect.

Update Cloudron

Update Cloudron from the dashboard.
Each Cloudron update can take some time depending on the version.
Some Cloudron versions have to re-create all docker containers which can lead to a downtime.
The downtime I can not estimate for your set-up since I have no knowledge about all the apps installed, at least there is one @cal.com

After each successful Cloudron update you can do some minimal testing if your apps still work correctly.

Update the @cal.com app

When Cloudron is updated to the latest version you can start updating your @cal.com app.
Each app update should create an app backup which you can jump back to if something goes wrong.
Please ensure that Automatic backups is not disabled for your @cal.com app.

---

If you might need some help from a Cloudron partner, I could get you in contact with one of our partners that offer paid support for cases such as yours.

[tom.westphal]

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!

[sparkwise]

We've seen inconsistent email delivery even on the latest release, which I believe was due to issues specific to Google Calendar (our primary calendar service.) I filed an Issue and I saw a few PRs referencing this with a fix, but nothing was merged. Even if it had been merged, there hasn't been a new release issued on this repo in almost three months (down from multiple per week prior to the strategy change.) Hope to see it revived, but not counting on it.

[jdaviescoates]

@james said:

Upgrade Ubuntu 20 to 22

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-22

If everything worked out upgrade to 24
Upgrade Ubuntu 22 to 24

Follow the guide https://docs.cloudron.io/guides/upgrade-ubuntu-24

If everything worked out, perfect.

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.

Also the standard "hack" to skip versions (you can't) is to set auto-updates to happen ever hour until it's caught up.

[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.