Cloudron Forum

@nebulon That's where it becomes confusing - you don't need to.

When trying to reach a published bot via a new tab, a client gets the error Failed to load resource when loading the page. Trying it out on multiple other networks and devices, I cannot replicate this error.

This led me to believe it is a network error on the client side. Though, when trying the same steps over at Typebot's SaaS, the client doesn't get any errors, and the connection is successful.

I'm thinking there's a quirk hidden somewhere in Cloudron's app configuration leading to this behavior.
Any clues, I'm pretty lost.

@girish Yes please, this'd be appreciated.

@joseph Ah, I see. I was trying to add the oidc extension to use my own external IdP. Now I understand why.

When uploading an extension's .jar to /app/data/extensions, restarting the application deletes the extension file. Thus, configuring an extension is impossible.

@robi was actually a parameter in the startup file. It's all updated in my repo that I've linked previously in this topic.

@Lanhild I'm still having issue with the healthcheck, though.

Solved it by removing an unused param

@Lanhild

This last point has to be done before the initial startup, as the daemon of the binary cannot run without a valid .runner registration file.

I have solved this issue by checking if the registration file exists. If it doesn't, I simply start the runner's cache-server. The instruction to register the runner is explained in the post install message.

https://git.cloudron.io/packages/uptime-kuma-app/-/merge_requests/8

Used in the context of Gitea Actions, their version of GitHub Actions.
From the fact that Cloudron is used by many to reduce costs (by renting less VPSs), it'd be pretty useful to be able to host such an application on Cloudron.

I've made a package of the binary @ https://github.com/Lanhild/act-runner-cloudron. Though, some aspects that bring issues:

• Can't have a proper healthcheck (I have no idea what the binary uses as a port)
• 2 runtime options; Docker or binary. They suggest to use the docker option. Though, it needs access to the docker socket.
• Runner registration to Gitea instance; the runner has to "register" to a Gitea instance using a token provided by the latter. Then the runner pings the instance and checks to validate the response.

This last point has to be done before the initial startup, as the daemon of the binary cannot run without a valid .runner registration file.

https://gitea.com/gitea/act_runner

@girish thank you for the clarification. As a maintainer of apps, I had seen the changes but didn't fully understand all of them.

@girish Dependencies to install are specified in each pipelines or filters frontmatters. (the scripts that the actual software ingests)

I've already made the package @ https://github.com/Lanhild/pipelines-cloudron and dependencies installation works.

@nebulon mostly, I want to override Cloudron's OIDC for this app.

@nebulon This

and also this https://help.penpot.app/technical-guide/configuration/#frontend

I've taken a quick look at the app's Cloudron package, and it seems like it simply needs a symbolic link from /run/penpot/env.sh

@girish I've docker login'ed on the root account of my VPS. Pulling an image from the CLI as root works well, but I'm still hitting the same error when installing/updating an app from the dashboard. Should I docker login on another user?

How am I supposed to configure the application's environment variables?

@Lanhild Looks like this solved it. I'll open a new topic if this were to happen again at the same volume.

@girish said in Recent app updates error:

@Lanhild are you also using that IP address (maybe via your home network) for other development/hosting ? Are you using Private docker registry against dockerhub with your credentials ?

I am not.

Cloudron pays for DockerHub , but reading https://www.docker.com/pricing/ . https://docs.docker.com/docker-hub/download-rate-limit/ has a wide range of limits. It's all very complicated ...

Indeed, I had foudn this documentation page, but it is very confusing to read.

I read a suggestion somewhere that you can "docker login" with your credentials on the server and this helps the rate limit.

I'll try this and report.

@Lanhild That's an issue for any Cloudron server that have multiple copies of the same app installed. Any app with automatic updates activated will face this issue. That's pretty critical.

@girish I have found the issue:

sudo docker pull cloudron/org.apache.guacamole.cloudronapp:202412061725490000
[sudo] password for sysadmin: 
Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit