I'm currently looking for such a feature. We want to block any request to applications as a security measurement. It would hinder any unauthenticated request to any resource which would create a significant barrier for any application which is not supposed to be publicly accessible. No request would reach the application if the client does not have a valid Cloudron SSO token. Nice and practical feature on top of that: create an allow-list for resources or path-patterns which may be excluded from the proxyAuth requirement. This would allow us to selectively publish certain parts of an application.

I do ! I just sent you a PM

Yes, is something in .NET, but runs on many plattforms (Linux, Windows, Docker, macOS, RasPi...)

I have implemented this in Cloudron 10 . You can set the maxmemoryPolicy in the manifest.

Hello @james, this is great to hear! If it turns out that this cannot be added in time for the Cloudron 10 release, it would already be very helpful to at least have an option to disable the platform password for mail login, so users are required to use app passwords instead.

@ekevu123 This was the idea suggested here, I think: https://forum.cloudron.io/topic/8745/my-apps-dashboard-ux-tailoring-apps-category

@alwynispat https://docs.cloudron.io/server#default-data-directory

Thanks - I see where you are coming from, but this is not directly what I aimed for with my initial post as a cheeky attempt to get consideration for a mail archiving app officially packaged for Cloudron. nonetheless, I see both as valuable topic of discussion: Legal compliance with business email archiving, especially in transactional email scenario - as a Cloudron feature tight to cloudron email server Email archiving app, possibly providing the above functionality by delegation of the feature but also enabling the archive of other emailing solution not residing on Cloudron (e.g. gmail, outlook etc..). Selfishly, the later is what is most attracting to me due to the need of archiving emails from various email solutions / providers as well as cloudron ones.

@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