Cloudron Forum

@nebulon At times I see that the Cloudron is not responsive (browser timeouts, which could be something other than a busy Cloudron server). I am also having an issue when using external monitors to check the health of my Cloudron (Uptime Robot, BetterStack). Attempts to use the API health check to return Cloudron version sometimes fails (causing Uptime or BetterStack to issue an alert). The same problem happens using the appid API call to check my Kuma instance. Again, I am not sure why this is happening or if it relates to the swapfile and performance. The GET failures are intermittent, but frequent enough to cause me to disable these alerts. Given the CPU/RAM/Disk of this server, I would not expect any of this to be an issue. I am not seeing anything in the box log that might suggest a problem. An article I was reading prompted me to look at the swapfile and utilization. Inside Cloudron, the monitoring chart seems to show a 50/50 split between RAM and swapfile. Ideally, Cloudron would use close to 100% RAM, but if subsystems dictate a 50/50 split, then perhaps I should increase from an 8GB swapfile to something much larger (I have enough disk to accommodate this easily). Theoretically, suppose I allocate 1GB to /apps.swap? How would that impact Cloudron performance? Would applications crash? Wait for available swapfile RAM? Just trying to figure out how to best allocate extra resources to get better performance.

@bartmathijssen said in Forgejo: @ruihildt I found some time, and was able to create a working package based on the Gitea package. The source code can be found on my Codeberg profile. https://codeberg.org/bart/forgejo-app I tried to take a look but got 404'ed. The page you are trying to reach either does not exist, has been removed or you are not authorized to view it. Is there a different place ? Or private ?

@jdaviescoates Thanks - Not the I have not though about this, but, at last, this could only be a temporary solution following our infrastructure setup. It also does not solve the underlying OIDC issue, which I very much find intriguing.

@scooke I use Google Analytics

Thanks @girish . I can confirm that the bug has been addressed.

@fbartels holy cow, you're right! [image: 1769087471311-screenshot-2026-01-22-at-20.07.52-2.png] I used this before to sort of keep track of which apps needed manual updates, or to press the Reboot button if I wasn't ready to do it at the moment of reading the Notification.

That is true, no server is required for sqlite, however to make a correct and consistent backup, one cannot just copy the sqlite file on disk, as data might not have been flushed fully to disk. This is why the localstorage addon in Cloudron has a way to signal the system, which file is an sqlite database and the backup will spin up a container to make a proper database dump. See https://docs.cloudron.io/packaging/addons#localstorage

I am happy to add -x if that helps. I think the intent was to keep results to the filesystem. -x, --one-file-system skip directories on different file systems

Hello @dleidert Cloudron does use docker-ce version 28.1.1-1. That the package is still from the Ubuntu 20 source is not bad. I would like to know how you noticed this. Did you inspect the apt packages after the upgrade?

My thoughts on profiles: Regular app installation = tlsserver (classic as fallback) App cloning for rapid testing or a development staging setup = shortlived

Hello @nerdrelaxo I have inspected a @traccar installation that has been running since 12.06.2025 with a default Android Client. This setup has no issues. I have looked into the traccer documentation and the RutX50 uses the teltonika protocol default at port 5027. Have you enabled the Teltonika Port and how is the client configured to send to that port? [image: 1769078342335-b9240940-e4e5-44e4-a24f-c9e725344c5a-image.png]

The latest update seems to have fixed it. Patience is a virtue xD