Cloudron Forum

@james nice

The GitLab 19.3.2 image cloudron/com.gitlab.cloudronapp:202609150645580000 occupies 18.5 GB on my server, with 16.1 GB reported as unique size. This is image storage, separate from repositories and other application data.

docker history shows these large layers:

• yarn install --production --pure-lockfile: 5.08 GB
• Gitaly and bundled Git build/install: 4.40 GB
• Workhorse compilation: 2.25 GB
• GitLab Shell dependencies and compilation: 1.28 GB
• Frontend asset compilation: 1.26 GB

The GitLab Shell build also explicitly includes the development test Bundler groups.

Would it be possible to review whether build caches, intermediate files and build-only dependencies could be excluded from the final image, using multi-stage builds or cleanup within the same build layer? Some of this may be required at runtime, so these figures are not necessarily reclaimable space.

Unused-image pruning is already complete. Reducing the installed image’s footprint would be helpful on servers running many Cloudron apps.

@creative567145 Those are maintained by me. There was a problem with my GitLab instance which got them disconnected from the community App Store. This is now resolved and all should work again.

Since CI/CD is really taking care of most of the work, I’m not planning on discontinuing these any time soon unless upstream changes require work I’m not able to put in. In that case I’d inform the community and ask if anyone is interested in taking over. Installed apps would continue to function regardless of maintaining updates. These repos are also public so anyone can clone them and continue the work whenever they want.

@creative567145 thanks for bringing this to my attention, this was a problem on the gitlab level which is now resolved.

Cloudron appears to match my private registry against Docker Hub because both hostnames contain .docker., selecting the private registry’s credentials for public image pulls.

For example, the failed Matomo update logged:

docker: pullImage: will pull registry.docker.com/cloudron/org.piwik.cloudronapp:202609212321130000. auth: yes

The pull failed, followed by a Quay fallback that returned manifest unknown. Existing apps continued running, but their updates remained in an error state.

Temporarily moving the registry to registry-docker.tld.com and updating its configured address, without changing credentials, changed the same Docker Hub pull to auth: no. All 20 pending official updates then succeeded.

The registry-matching code in src/docker.js appears to use .includes('.docker.') to recognize Docker Hub aliases. Could this be restricted to an explicit list of Docker Hub hostnames, while requiring exact hostname matching for private registries? Private-registry credentials should not be selected for unrelated registries.

@gir just putting this back on your radar since you mentioned you might look into this after Cloudron 10 was released

@humpty v0.3.32 moved the package image from Docker Hub to the new Cloudron Container Registry as part of the Cloudron 10 build-system migration. Cloudron intentionally requires manual confirmation whenever a community package changes its image repository, as a security precaution. This should be a one-time manual update; later versions from the new repository will update automatically again.

@micmc Thanks for the detailed log. This isn’t intentional, I simply don’t use the web UI and didn’t catch it. I traced it to the dashboard’s WebSocket origin check: the browser connects through the public Cloudron URL, but Hermes only recognizes its internal loopback address. That explains why terminal access works while web chat keeps disconnecting.

While working on this, I found that upstream provides a public-URL setting specifically for reverse-proxy setups. Using it also requires native dashboard authentication, so I’ve implemented the upstream Nous OAuth login flow in the package rather than bypassing the origin check.

The changes are implemented in 0.4.91. I haven’t been able to verify the complete login and browser-chat flow. This will introduce a Nous login and a one-time OAuth client registration for the dashboard, which I documented with the update.

Agree but duplicate

I looked into this further. The missing token is a consequence of upstream Hermes deliberately filtering credentials from subprocess environments, rather than a Cloudron-specific environment issue.

Upstream does offer general environment passthrough, but it explicitly prevents that mechanism from overriding its protected credential blocklist. It also does not currently provide an operator-controlled, per-script credential allowlist for cron jobs.

I’m trying to keep this package as close to upstream as possible, so I won’t be adding a package-specific workaround for that filtering. Maintaining a separate credential-passing mechanism would add complexity and behavior that could diverge from upstream’s security decisions.

A scoped way to give trusted cron scripts access to selected credentials seems like a reasonable upstream feature request. I’d prefer to use an upstream-supported solution if one becomes available, rather than implement a parallel mechanism in the Cloudron package.

@alpheus

@jdaviescoates personally I found the internal turn server to be highly unreliable. But others may have better experiences.

@LoudLemur honestly it’s not that resource intensive. We used to run the HPB on a fairly small hetzner VPS but since switched over to the Cloudron package with cloudflare turn. Highly recommend.

@nostrdev I have successfully used NC Talk with the HPB and 30+ users

@WiseMetalhead Please update to 0.4.88. It should work now.

@alpheus I pushed 0.4.87 which should resolve this

@james yes looks like you need to implement a sandbox environment in the package

@msbt this looks like a community package and probably should not be included on the Hermes package. Adds extra complexity, package churn and attack surface.

@humpty mollysocket is needed if you want to use a different push provider like ntfy with Molly (Sognal) on android as opposed to Google Firebase

@msbt I’ll look into it

@MiroTalk said:

which parts are unclear to you and what you would expect to see improved in the explanation of each project

My main confusion is that several projects appear to solve almost the same problem. C2C, P2P and CME all cover one-to-one calls; P2P and SFU offer largely the same meeting experience – and their UI and used terminology are almost identical – at different scales without any end-user distinction; BRO overlaps with SFU’s webinar and broadcasting features.

The overview lists many features and architecture terms, but it does not make the choice simple. People are used to Zoom: they start a meeting and it works, regardless of participant count. I would expect one clear decision guide and clearer terminology on each homepage shipped with the application, explaining who each project is for, its practical limitations, and why I should choose it instead of the overlapping alternatives.