I have a server where it seems to stop responding and generates timeouts in monitoring which come back a few minutes later. Perhaps it's this pattern.

True, there are limitations. I withdraw my class names suggestion On third look, only very few inline styles are set (e.g. width for grid-item). As to class + data attribute selector, it'd be easy to use higher specificity, try: .grid .grid-item { border-radius: 50%; } or .grid .grid-item img { object-fit: contain; }. And there are a bunch of possible declarations that need not even override anything (e.g. filter, border, box-shadow).

aidevops now has cloudron app packaging skills, based on the latest docs, best-practice, and forum knowledge — so should make it easy for anyone to package apps now getting the best results from gpt-5.6-sol on medium thinking

I have a new offline solution with llamafile that runs on n M1 really well. Should see how it runs on CPU only VPSs.

Attention: I have made a few tweaks to my release pipeline and as a result of that the url of the CloudronVersions.json has changed. The shop listing has the updated url, but I don´t think there is an automated upgrade so the app needs to be removed and reinstalled.

Hello @inibudi I am not sure what your VPS provider is even displaying with this graph. It is just labeled Memory and has no other indication. Is it whole system memory, memory used, memory and swap combined? When you connect to your server and run free -h you can see the memory values. Maybe compare that to Cloudron and your VPS to figure out what the VPS graph is trying to show. We took this topic as feedback to improve our graph for memory. The graph is showing memory used. We now added a % scale to the right Y-axis and to the tooltip. Note that the lines are stacked, so they align in addition of each other. [image: 1784281410685-1cf5350a-5181-444f-a589-96d58a457278-image-resized.jpeg] In this screenshot 1.23 GiB + 0.89 GiB = 2.12 GiB at the left Y-axis and 15.40 % + 11.14 % = 26.54 % at the right Y-axis.

Hello @sean-abbott and welcome to the Cloudron forum Yes, you can run Cloudron at home, see https://docs.cloudron.io/installation/home-server and https://docs.cloudron.io/installation/intranet. With the upcoming release of Cloudron 10 we have implemented VPN protection for apps, see: https://forum.cloudron.io/post/126100 That could already provide some relieve to your needs. There are already many other forum topics about Cloudflare tunnels and similar set-ups as you describe. @sean-abbott said: the cloudron admin interface accessible on the internet That is the default but can be changed with a firewall and VPN app. Since how this should be done is very dependent on what 'flavor' one admin prefers, Cloudron does not impose one strict route but leaves it open to the admin.

Hello @humpty Agreed. Deleted the user.

Thank you

@timconsidine we're at the point where it's questionable if it's even safe to comment or have a public online opinion on these things — hopefully that tells you enough as to how bad all this stuff is adjust to avoid, if you can, or care to if you have to, expect to have an increasing amount of attacks on infrastructure from those that seek to utilise those "verified" accounts

@girish thank you, and thanks for confirming the fix ships in Cloudron 10. Adding one data point for anyone who finds this while still on 9.x: we hit the same crash again on 2026-07-06, on 9.2.0 (a build from before commit 33f3ca3), so it recurs exactly as expected until the v10 upgrade: tasks: setCompleted - 4900: {"result":null,"error":{"message":"Cannot read properties of null (reading 'sort')","reason":"External Error"},"percent":100} Same app (Langfuse), same place: the task died at app 31 of 73, so the roughly 40 apps after it were left on the previous snapshot again. The du precondition logged the vanished directories first, this time a delete_tmp_tmp_merge_* variant alongside the usual tmp_merge_* ones, and then readTree threw during the upload. Until we are on 10 we have excluded the ClickHouse apps from the automatic schedule so a single mid-merge app cannot abort the whole run, and we re-run on the rare miss, which clears it. Glad to confirm the fix here once we upgrade, we have a reliable reproducer under merge load.

@layuso we've discussed many of these in other threads. Today the APi is there, the 3rd party dashboards have been made and you can build your own. We also have Cloudron hosted partners who made their own management systems for their needs. What would you like to make first?

Hey James, Sorry been a bit busy here - but per your comment I can def share some insights. I went into the main cloudron dashboard, and navigated to Users > LDAP to configure my internal AD config (Dashed out some sensitive info for security) [image: 1782476078381-48d9bf82-9176-460d-8cd3-bbc4cc5f647a-image.jpeg] After the data began syncing properly, I manually went into my container and adjusted the authentication protocol to utilize OpenID instead of MySQL auth by adding the highlighted entity - [image: 1782476394053-13d291db-2501-4a5e-9fe6-c9c6c0f36d6f-image.jpeg] All seems to be working out, outside of the one tidbit I mentioned previously. But it's manageable for now and my users are having no issues logging in and accessing resources using their AD credentials

Right, the check is simply hardcoded to check for a: entry in the SPF. To check all the possibilities would be quite complicated, since we will have to implement the full SPF spec just for diagnostics. (What you see on the dashboard is just a diagnostic. The mail server Haraka has a fuller SPF implementation).

Has anyone experienced admin dashboard slowness? Front end is fine, but clicking on management has the browser wait for 5-10secs. Logs show: Jun 11 18:59:03 172.69.67.20 - - [11/Jun/2026:23:59:03 +0000] "POST /studio/edit-link HTTP/1.1" 302 390 "https://l.toldyouso.com/studio/edit-link/121242148" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:04 [Thu Jun 11 23:59:04.258485 2026] [access_compat:error] [pid 72] [client 162.159.106.71:59436] AH01797: client denied by server configuration: /app/data/public/.env Jun 11 18:59:04 162.159.106.71 - - [11/Jun/2026:23:59:04 +0000] "HEAD /.env HTTP/1.1" 403 - "-" "-" Jun 11 18:59:04 [Thu Jun 11 23:59:04.412636 2026] [access_compat:error] [pid 74] [client 172.68.27.182:56976] AH01797: client denied by server configuration: /app/data/public/database/database.sqlite Jun 11 18:59:04 172.68.27.182 - - [11/Jun/2026:23:59:04 +0000] "HEAD /database/database.sqlite HTTP/1.1" 403 - "-" "-" Jun 11 18:59:10 - - - [11/Jun/2026:23:59:10 +0000] "GET / HTTP/1.1" 200 33462 "-" "Mozilla (CloudronHealth)" Jun 11 18:59:15 172.69.67.20 - - [11/Jun/2026:23:59:03 +0000] "GET /studio/links HTTP/1.1" 200 34944 "https://l.toldyouso.com/studio/edit-link/121242148" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:15 172.69.67.20 - - [11/Jun/2026:23:59:15 +0000] "GET /@rob HTTP/1.1" 200 76669 "https://l.toldyouso.com/studio/links" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:16 172.69.67.20 - - [11/Jun/2026:23:59:15 +0000] "GET /@rob HTTP/1.1" 200 76669 "https://l.toldyouso.com/studio/links" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" Jun 11 18:59:16 - - - [11/Jun/2026:23:59:16 +0000] "OPTIONS * HTTP/1.0" 200 - "-" "Apache/2.4.58 (Ubuntu) OpenSSL/3.0.13 (internal dummy connection)"

Update: All apps in error state after Cloudron restore After restoring Cloudron, all my apps ended up in an error state. I've been digging into the logs and wanted to share what I found in case it's relevant to my setup or helps others. The key error from the app task log: Error: ENOENT: no such file or directory, scandir '/mnt/managedbackups/<uuid>/2026-06-10-000001-121/app_<myapp>.<mydomain>_v3.12.2' So during the restore, Cloudron tries to download the app backup from /mnt/managedbackups/..., but that path doesn't exist. This then causes the task to crash with an AssertionError rather than a clean BoxError, which is probably also worth flagging as a minor bug. I suspect this is related to my specific setup: I have an external backup location that is no longer mounted (as described earlier in this thread). Cloudron appears to be pointing the restore at that unmounted path. Resolution that worked for me: Explicitly restoring each app from its most recent backup (rather than letting the automatic restore run) resolved the error state. Ideally, this should be the default behaviour during a Cloudron restore anyway, restoring from the most recent available backup, so this might be worth looking into. Happy to provide more details if useful.

@james Thanks so much! I'll do that