Cloudron Forum

I think you have to run docker image prune and docker prune to clean all unused stuff

Hi @james - I also received a response today. Hope its the same group of people you talk to I let the AI compare the responses: Key differences between response I received and from your summary: Root cause: GC overload vs. synchronous unlinking of old object data. 504: Both say the proxy times out after 600s while backend processing continues. HEAD vs. GET: Response I received assumes processing may still be ongoing and no data loss; from your summary says the affected data is unrecoverable. CopyObject / MPU: Covered as under investigation in response I received; not addressed in your summary. Fix: General GC optimization vs. explicitly decoupling GC from CompleteMultipartUpload. Anyway - looks like we helped uncovering the root cause

I think you are referring to https://docs.cloudron.io/installation/home-server correct? What is the issue you are facing? Cloudron will get certificates via DNS automation, it doesn't require port 443 to get certs in that case. See https://docs.cloudron.io/installation/home-server#dns-provider

Good idea, will add to the Cloudron 10.1 list to investigate @andreasdueren . We added a concept of Default apps in Cloudron 10 (which is still "experimental") . Maybe that is a fit for this too cc @nebulon

Note: analysis for this report has been done with support of ai (claude). Environment Cloudron on Ubuntu 26.04., root partition 295 GB MySQL addon: registry.docker.com/cloudron/mysql:3.8.0 Affected app: FreeScout Image: cloudron/net.freescout.cloudronapp:202609190520200000 App ID: 0a2837d5-… DB: fc0ce74f… Problem The root partition went from roughly 50% to 89% within a few hours. The cause is MySQL binlogs inside the addon container: /var/lib/mysql 146 GB total binlog.* 145 GB (1486 files, 101 MB each) The actual databases only account for about 1 GB. binlog.000001 dates from 2026-09-01, so every binlog since initial setup is still being retained with nothing expiring. binlog_expire_logs_seconds appears not to be set in the Cloudron MySQL configuration. Write rate A new 101 MB binlog is currently created roughly every 9 minutes, i.e. about 4 GB/hour (timestamps 16:43 → 22:37 = 40 files). The source is FreeScout: its activity_log table has grown to 12 GB (activity_logs.ibd), and the nightly mysqldump for that same app is now 10 GB. Questions Is it intended that the MySQL addon ships without a binlog expiry? On installations without replication, the logs will inevitably fill the disk. What is the supported way to set binlog_expire_logs_seconds persistently, so it survives container restarts and app updates? Are the binlogs required by Cloudron's own backup mechanism, or can they be purged safely? Is the excessive logging in FreeScout's activity_log known behaviour for the package, and is there any housekeeping for it? I would expect it to be handeled automatically, like it has been for the most previous years. I assume it is a bug in the platform rather than behaivour that is expected to happen. I am not sure if this could be a bug when upgrading from Ubuntu 24.04 to Ubuntu 26.04. or because of a Cloudron change? I have activated the support login on this server, so staff can check it on their own, if they prefer. What has been ruled out Docker itself is unremarkable: container logs max 21 MB, build cache 0 B, volumes in the MB range. Journal 93 MB, /var/log 341 MB. I don't have any other idea where this could originate from.

@rstockm thank you Hoping to make it part of “work anywhere” dev cycle. I find the UI a little frustrating in places, but it’s just a case of getting used to it.

updated the screenshots in the original post to better show what it is now great ux and community version capabilities imho

@girish my last response was typed while waiting in an IKEA queue ! Better quality would be : Really appreciate your feedback and the effort put into the 300MB 'slim' version, especially when your workload is so heavy with 10.x.x. I guess the core difference is you are constructing a "platform package" while I was aiming at a "runtime only" image, with the inescapable consequence that the packager adds what they need for that specific app, even if that is more work for them. For a platform package, your comments make total sense, and of course I defer to your experience and objectives. And 300Mb is a clear win over 2.3Gb with still quite a lot of convenience 'nice to haves' included. My argument for excluding much of what you mentioned is : runtime package doesn't need much of it why include mysql and postgres when neither are needed for a specific app keeping a lean attack surface ( the less in it, the less that can be abused) it is rare that compile stuff is needed at runtime, maybe include that in a multi-stage "builder" stage then omitted in a final "runtime" stage. For example, a simple Go or Python application that doesn't perform image processing should not be forced to pull ImageMagick or gcc just to run. My cloudron-minibase does push a lot of responsibility onto the packager. That may not be popular, but they don't have to use it ! And I totally understand a bit bigger image to meet your goals about platform experience is valuable. As a test, I updated cloudron-minibase to include : tini and supervisor libssl-dev and libpq-dev yq and crudini nginx-full This gives an image size for cloudron-minibase:0.0.2 of 77Mb. (FROM tcmbp132021/cloudron-minibase:ubuntu24.04@sha256:ae1e4ab4343f9f9dff05b988db94c8936f8390b8d1e88db80a1ae7afde563aea). This keeps the base significantly smaller than the 300MB version while providing the tools that 90% of apps actually need at runtime. For the remaining 10% (the ones needing heavy compilation or ImageMagick), the package developer can simply add those specific layers to their own package, build stage or runtime stage. Or simply use your future "cloudron/base-slim" if you decide to release one. So actually I am totally with (a) following your guidance as to what is best, and (b) using a 300Mb image for simpler packages and (c) continuing to use the full cloudron/base of 2.3Gb where it is justified. I didn't intend cloudron-minibase to be a disruption or a challenge. The inital 50Mb was insane, unexpected, and I would still have been happy if it was 300Mb. So no problem at all using a 300Mb base if one becomes available.

Another thing if you activate codebase memmory on repos the search with graphql is instant and sometimes I thought models are hallucinating even Fable 5.1. But it wasn’t the case, whole repo loaded and schemas loaded in ram and results are at least 4 times faster then normal windows based same tooling and usage as no overhead of windows filesystem nor Microsoft defender