Cloudron Forum

Ah so essentially this: https://forum.cloudron.io/topic/1977/platform-data-and-other-disk-usage/26

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

I like the idea for both, but would consider the trash can to be a little more important than the versioning.

@LoudLemur said: @tempinou We have just updated wger and hope your training schedule wasn't interrupted. Hail Victory! @LoudLemur thanks but finally it's not enough to work. Android Mobile app need powersync for offline sync to launch.

still all working well for me, but then i might not be touching all features important to everyone keep any feedback coming, want this to be the perfect setup for anyone wanting a private mesh network — which is very handy for offloading ai work to various other machines in your world, regardless of where you are exit-node feature is also handy, and nicely implemented — really impressed with their ease-of-use for clients if we can get cloudron to allow this as one of the vpn-protection options, i can see this being ideal for making cloudron corporate-friendly for anyone offering those kinds of services or wanting for yours and your family's locked-down access to apps

I think I've hit what looks like either an undocumented restriction or a bug in how community app updates are validated, so I'm looking for clarification. Summary For an already-installed community app, changing only the title in CloudronManifest.json (same id, new version, same everything else) causes the update in app UI updates to fail. The docs describe title as display-only and describe id as the app's identity, so a title-only change should not break an update. Reproduction Community app installed on an instance from a CloudronVersions.json URL. In CloudronManifest.json, bump version and change only title (keep id identical). Publish the new version to CloudronVersions.json / host it. Attempt the update from the dashboard (or cloudron update). Expected: update succeeds; the app's displayed name reflects the new title Actual: the update fails. Reverting title to its previous value and publishing again lets the update proceed. I removed and reinstalled the app afterwards, so I no longer have the original task/box log. What the docs say The title field is documented purely as: "The title is the primary app title displayed on the Cloudron App Store." Only id is documented as identity: "The id is a unique human friendly App Store id." https://docs.cloudron.io/packaging/manifest/ Questions Is title intended to be immutable/identity for an already-installed app, i.e. is the effective key id + title rather than just id? If so, the manifest docs should state that plainly — they currently present title as display-only. If it's not intended, is this a validation bug? The update appears to reject a manifest that differs only in a display field. Is there a supported way to rename an existing community app via the manifest? Using the dashboard app label is a workaround, not a fix — the manifest title is what new installs and the App Store use, so the installed app and the package listing then diverge. Want to clarify before I attempt more renames via CloudronManifest.json title. EDIT : This is not about ca.cloudron.io which accepts the title change. It's about installed app dashboard, Updates / Check for updates / update.

@jayonrails great idea but no idea how one manages continents, countries, cities ! Berlin / DE seems Cloudron's home. [UK, south, could consider Europe]