Cloudron Forum

@User123456 the demo being a demo is by nature very publicly accessible, making it prone to things like this. Unfortunately, there's not very much the team's able to do without locking a lot of the features, which in turn would make the demo unpleasant.

@sparkwise According to their blog post, back in April, the maintainers are "former Cal.com interns".

Anyhow, it's been ~15 days since any commit was pushed, and all the commits since their announcement were almost exclusively changes to remove code from their "now" closed source version.

Not to be pessimistic, but I wouldn't expect a new release any time soon, if ever.

@joseph practicality, probably. GitHub's free offering is still very attractive.

@nebulon They migrated to GitHub. Might want to update OP.

• https://github.com/mrmn2/PdfDing

@msbt I'm using 8.2.0 just fine with these options. The regression most certainly comes from a minor in between that version and 8.2.3

@girish I would be surprised if they were to backtrack that move. The developers were always one step towards that direction, they simply used AI scanners as an excuse to close the code earlier (which was arguably pretty much already closed).

It's only a matter of time before the "new" https://github.com/calcom/cal.diy repo gets archived.

@james Thanks for the insight. As this is a production server, I'll wait for the update.
Regards.

@james Indeed, the second curl times out.

But does the original issue from my topic really come from this? I dare have a doubt about it.

As mentioned in a previous reply, the original issue for that other server was solved with the Ubuntu 24 upgrade.

On the other hand, the problem is very much still present on the Cloudron.
Feel free to ask for more debugging cmds.

@james

6.8.0-110-generic

My server's = 110. The other server, without the issue, has the same kernel.

@james Done.

@robi Yes

Cloudron Container Registry 2.6.0 (registry 3.1.0)

@nebulon

I have another Cloudron server for which I did the upgrade too. Though, it didn't fix it for this one.

No outstanding errors in cloudron-support's output.

I'm pretty much at a dead-end here

@james said:

@robi said:

It would be nice if they could be hosted by the local registry app.

The docker images? That should already work and is close to my above suggestion with a private registry. You'd just need to configure the docker registry in the Cloudron dashboard under /#/docker.

I believe what @robi meant is to be able to store the CloudronVersions.json in a registry, much like what authentik does with blueprints.

@robi That'd be a great solution

The convenience and the standardization benefits of using CloudronVersions.json and its features shouldn't be restricted to publicly accessible URLs.

Whether be it manually pasting a CloudronVersions.json's content in my dashboard, I'd like to be able to install my private custom applications this way.

@mazarian Agreed, this feels unusual as "shutting down" isn't as destructive as an uninstallation.

@nebulon I did the upgrade from Ubuntu 22 to 24 today. I confirm that it fixed the issue for me as well.

Updating the Cloudron CLI did the trick.

I was using npm install -g cloudron, believing that'd update to the latest version. Turns you should use npm install -g cloudron@latest to get the most recent version.

On Cloudron 9.1.5, along with Cloudron's CLI version 6.0.0, attempting to install an application systematically results in a 404. This makes it impossible to install an application.

❯ cloudron install --image ghcr.io/lanhild/sh.atuin.cloudronapp:1.0.1                      
Location: atuin
Failed to install app: 404 message: No such route

The error occurs on the demo server as well, ruling out a configuration error.

This might be a regression that appeared since the new cloudron versions feature.

@klawitterb said:
Probably not related I've also noticed that the logs on the docker registry container get spammed with this error:

Mar 28 08:46:32 time="2026-03-28T07:46:32.467979729Z" level=error msg="traces export: Post \"https://localhost:4318/v1/traces\": dial tcp [::1]:4318: connect: connection refused" go.version=go1.23.7 instance.id=401bc88b-1bfe-4713-ae09-1cffdf628884 service=registry version=3.0.0

I'm also encountering these.