Cloudron Forum

@james I tried installing the app on a different name and the issue was still there, but now it's not for some reason. Will try what you suggest if it happens again and report back.

The fixed cli version is published now

Just tried updating the CLI via npm install -g cloudron@8.2.1 and it seems to work now Thanks for looking into it.

Similarly described in Unusable application: Pushing/pulling an image from a remote works correctly. However, attempting to pull an image from the same server doesn't work at all. I tried upgrading to Ubuntu 24.04 and it seems to work as expected now (versions file + icon on the same server without issue).

I have pushed a new cli version now which supports showing more help info for cloudron build --help now

@nebulon said in Point arbitrary domains to a cloudron app?: is there a reason to not make that domain known by Cloudron? Sort of as fbartels described: you might think of it as a 'customer' domain, so they use the service running on Cloudron and not Cloudron itself, therefore you might want to provide a way to add domains within your deployed app. I've noticed that DNS misconfigurations can stall or block deploys because it just keeps retrying, and I would like to avoid exposure to that; would the 'manual' provider change this? But I realize I'm a bit self-contradictory because of course I also would try to automatically configure certificates for their domains so they don't have to.

Could be. Cloudron uses the default URL size - https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers If you want to experiment, edit the file in /etc/nginx/applications/*conf and then systemctl restart nginx .

The code is at https://git.cloudron.io/apps/surfer . Contributions are welcome

Deleting all executions still didn't move the database down from 500mb, but after running VACUUM FULL execution_data; it's now 13mb. I''ll take it.

@girish Works thank you. I see you already updated the docs!

@shrey there's some cases where the backup code forgets about older backups. For example, if you switch backup providers (even temporarily). We are trying to improve the whole situation in 9.0 . For a start, with multiple providers, we can track/cleanup more accurately. BTW, if you paste the filename of the backup in your Eventlog, does it find it there? I will look into making this more clearer i.e what is getting deleted and why not getting deleted.

@nebulon said in "fatal: not a git repository": Have you tried to use a subfolder in /app/data/ for this? This is where data is kept persistently in Cloudron. Been using this folder and seems like it has had no issues for a week or two now thanks for clarifying

@rosano interesting. I guess this is a way to beat CNAME cloaking for analytics. This is indeed not the purpose of the App Proxy (i.e it's not meant to proxy external sites).

@girish said in multiple static sites on one app: A "hack" if you really really really want a single app would be to use the LAMP app. You can add any number of alias domains. After that , yu have to then configure apache there to serve up different folders based on the request domain. Indeed, though you need to have a bit of Apache server knowledge and you can configure all your virtual hosts inside the Apache configuration file, which is named app.conf on Cloudron. As a matter of fact DO offers a pretty decent Apache configuration tutorial. It's relatively easy, you don't need to know everything, just how to host multiple static pages on once instance. Have fun.

There is a bug in Cloudron that it parses swap info incorrectly when there are no swaps in the system. This is fixed in https://git.cloudron.io/cloudron/box/-/commit/b66e77a2d8930381c95153b041d7c3edd331364a

@rosano woo hoo! Thanks for this not having to learn much of Docker tutorial!

@rosano that's actually very small. I was thinking maybe it was some GBs in size. How is the general free memory situation on your server? The kernel just chooses some process at random and nukes it. (random from user's point of view, I am sure kernel has some heuristic).

@rosano instead of deleting /apps.swap , just keep it 0 size and remove the fstab line. Cloudron recreates the swap file on reboot (since that is the recommended setup for linux). so truncate -s0 /apps.swap is good enough.