Great, and thanks girish. Cloudron is brilliant!

@huehner a workaround for now is to use ?username=xx&password=yy . I have fixed the issue that you reported in any case and it will be part of the next release. With the fix you can pass username:password in the URL .

@girish thanks for the reply! That's the thing, I'm not a 100% sure yet. It's a custom app that sends out 100+ emails (and growing) every few weeks/months and it hit twice the Connection denied. recipient rate limit exceeded and once Connection denied. connection rate limit exceeded. It wasn't great, because it wasn't clear which mails went through and which didn't (other than manually combing through the logs). My guess would have been [rate_conn] and [rate_rcpt_host] for starters, but the quick fix (other than building a queue/delay/throttle which adds a lot of complexity) was to use Postmark directly instead of Cloudrons mail-server, so for this specific project this is "solved", but would still be a nice to have feature to adjust the limits in the settings.

@girish Thanks. The graph was able to do what I wanted, I just didn't realize it. It does show the usage per application each in its own colour. Great!

@James Thank you!

@necrevistonnezr good find. @staff please could we replace SnappyMail with this? Thanks!

@fbartels it was a joke.. app pw acting like an api key

+1 - Great idea! Even the ability to automatically pull an IP list into the blocklist on a set cron schedule would be extremely beneficial.

Yes, we used to have this, and I think/ hope they'll be back (along with other improvements) in the next release, see this thread https://forum.cloudron.io/post/117521

@girish said: The messages are fixed now Does that include colours coming back too?

Great suggestion, this is implemented now for next version with https://git.cloudron.io/platform/box/-/commit/0223d50bf9f6bc01f53a75815dbe86f4cb5acb86

Hello @ekevu123 I understand the request but in my opinion adding "advanced" sections to the Cloudron dashboard will only lead to issues. Someone who is less skilled will see the button and use it. "Don't press the red button, it will wipe the DB server!" "Oh! A red button!" In your case, since you still need to use the terminal anyway, why not use the cloudron cli directly and have a bash alias ready to execute the interactive DB shell directly for an app? This would even reduce your time spend getting there even further. Instead of your mention steps 1>4 or future 3-dot sub menu, moving the mouse, clicking moving again yada yada, one command from the local shell, and you got what you need. For example: cloudron exec --tty --app $APPID -- sh -c 'mysql --user=${CLOUDRON_MYSQL_USERNAME} --password=${CLOUDRON_MYSQL_PASSWORD} --host=${CLOUDRON_MYSQL_HOST} ${CLOUDRON_MYSQL_DATABASE}'

Fantastic! Thanks so much, @james

@m3pilot it's not a problem. Cloudron periodically checks (everyday) if the namecheap credentials are working. If not working, it will give you a notification that DNS credentials are not working. As part of the check, a DNS entry is created and deleted immediately .

Yes, that's correct.

If the image still isn't found, the Docker daemon fetches the image from the canonical repository on Docker Hub. that's a feature of docker daemon itself. Fallback through the list of configured registry-mirrors. The key here is that docker pull docker.io/cloudron/base is treated exactly as "docker pull cloudron/base" (implicit hub.docker.com) whereas docker pull registry.docker.com/cloudron/base is ignoring registry-mirror list because it is an explicit registry image ref. quay.io would also fail in a "restricted" network environment. One of the other solutions I considered is to allow a "cloudron base registry" option in the installer.

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.

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.

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