@gobenizzle so the next release will be all about mail improvements. We will investigate this feature request as well.

Great catch! Always good to have users with resource out of the ordinary Fixed with https://git.cloudron.io/platform/box/-/commit/d504db161a839acb6742f6f7bf156e9b8a5bb0a6 but didn't made it into 9.2

@jk @james is away this week. So, he will probably get to it next week .

Hello @imc67 Apologies! I had a message written but did not press reply Yes, this is currently not possible thus I moved the topic into the @feature-requests category.

@robi Yes, I've tested the rclone before that's why I suggest this feature on Cloudron. I don't know the technical requirement on that, maybe what James said it's more a cloud file storage not for the server backup. Thank you Robi and James

@necrevistonnezr said: You got an upvote for me in any event, but for this feature: https://docs.cloudron.io/guides/community/blocklist-updates Haha, true, that’s my code (with your additions) I know that, but it’s not per app

Thank you!

@nebulon Yes, they still have ongoing problems... Even if they mark as “solved”, problem is not fixed. This can affect Cloudron installations. Just tried to install Cloudron again but... Err:75 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-firmware amd64 20240318.git3b128b60-0ubuntu2.26 429 Too Many Requests [IP: 2620:2d:4000:1::103 80] Fetched 220 MB in 5min 41s (643 kB/s) E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.26_amd64.deb 429 Too Many Requests [IP: 2620:2d:4000:1::103 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Can’t answer for their business decisions - it is a slot you backup to. I’ll feed this back to them! Thanks for the reply. Edited to add: Turns out the slot was a jailed ssh so I could just ssh-copy-id from my machine instead of going through their client portal. All good, able to use sshkeys now!

Both. I want to understand if both are correct programmatically, but I can't test them against having an existing docker image, because I find that counter-intuitive - why would I build the docker image before knowing if everything is correct?

Below are some notes on this. Supporting this would help Cloudron with eg ejabberd. https://paste.wanderingmonster.dev/?283c2adafcdddeaa#8bke4mYL5MBQNEoc3FEbvHDE6ZHEANBhT3qX9RTNcpey

I would absolutely advocate for re-adding X-Content-Type-Options: nosniff as long as we don't have a way to set headers directly in the Security Settings of Cloudron Apps (like we can with CSP headers). That header still provides meaningful protection against MIME-sniffing attacks and has widespread browser support. Afaik, X-Permitted-Cross-Domain-Policies is still used by Acrobat (which is unfortunately far from dead), but I agree it's fair to remove it from the default configuration since it's an edge-case.

Bump! Please upvote if you think a configureable timeout for Cloudron SSO would add value to the platform. Currently I am using PIN code verification via Cloudflare Access as a workaround, but ofcourse this only works if the domain is proxied by Cloudflare.

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

@girish That is fantastic news, looking forward to it. thank you cloudron team!

Hello @tobiasb Good suggestion. I ask myself, is the manifest the correct singular location for this config? Maybe we set the initial value via the manifest but also allow a custom value in the service overview from the dashboard. But at least adding this to the manifest should be doable.

The obvious is Vercel dev'd app self hosted here.

@timconsidine you can toggle visibillity for apps that have their own user management. If you use an SSO app, there is "user management" which manages access (and therefore an visible dashboard icon) but "dashboard visibility" is missing from the menu. Its well explained in the documentation. I guess what you could do is remove access for an user (within Cloudron), put the user inside a group X that has no access to said app and set up SSO manually within the app to grant access to users within group X. Basically, I want the "dashboard visibility" options to be available for all apps. To not make Cloudrons UI confusing, a "Hide for non admins/operators" checkbox would be fine.