@nebulon can you enhance the docs to show how multiple versions, 2-3, look like in a versions file with updates?

Thank you, I just wanted to say that this worked!

@LoudLemur i'm working a lot with strapi, developed plugins and more So yeah, it def. has its limitations or "weird edges", but in general i'm happy with it as backend for my apps. And like you said, strapi is more for serious business depending logic (with more effort in CI/CD) while directus is more for non-technical and quick-deploy setups.

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

Thanks @girish TBH, most people don't read docs despite all this Yep, true Soon there won't be any docs. AI coding agent utility will produce some illegible binary asset "cloudron.aifood", which another agent will use. We humans won't need to know or read anything. Thanks @nebulon maybe better some https://foo.bar/changelog link nice idea, let me think about that. testing my build script which makes it a mandatory input (to overcome my lack of discipline )

Yes the format is described in https://docs.cloudron.io/packaging/manifest#changelog Using the .md extension is not really relevant, however it might render the file better in git hosting apps.

Stubborn dog-with-a-bone that I am, I did more research, and hopefully this can put to bed my diversion of the thread (sorry), and maybe help others with a similar use case / workflow objective to mine : Forgejo (official Cloudron AppStore) provides standard git source code functionality AND it has a built-in container registry functionality so no need to consider changes to the official docker registry app for public pulls forgejo supports private and public repos (which git.cloudron.io does not) forgejo supports public image pulls (like hub.docker.com) but also multiple private containers (hub.docker.com only allows 1) I can uninstall docker registry app and gitea/gitlab apps, multiple used for segregating cloudron community work from closed app dev, using Forgejo organization instead. So the answer for my bandwidth-limited brain of 1 app for (almost) everything seems to be Forgejo (available today, no dev work). However, @girish made valuable comment that hosting container images is a disk/network usage risk. Even for a small dev footprint like mine, this could be critical (let alone Cloudron scale). I need to think & test out, but maybe Forgejo actions can automate container push to hub.docker.com, and do automated cleanup in the instance. So from dev point of view it's a single answer (Forgejo) with CI/CD offloading disk/network risks to hub.docker.com (or whatever).

You already got it, but often proxyAuth is the simplest.

Hello @aaaaargzombies @aaaaargZombies said: TLDR I'm on version 9.0.17 and should try upgrading. Yes, you should update to Cloudron 9.1.3 for cloudron install to work without the need to build and push the image before installing.

@eyecreate amazing! I'll be installing this I think

@marcusquinn your prompt reminded me about it. I will take off the very dusty shelf and look at it again.

@James absolutely ! Very cool ! That was actually a break-through moment to get over blind poking and assessing output. So thank you again.

@timconsidine challenge accepted? You grow either way.

@LoudLemur late reply not sure I understand your question so this answer may not be what you want but in picture form ... [image: 1768330247721-mermaid-diagram-2026-01-13-185009-resized.png]

Hello @timconsidine I can really recommend nvm to manage Node.js and NPM versions.

I see, I think. I'll try to work the API example into the start.sh script that runs when the app is started.

i was hardening it here is the repository link and tag samcorepa/appsmith-cloudron-ce:20251230-135540 [image: 1767103309577-333dfbea-62fc-4c51-a7a3-e6629bd2e248-image-resized.png]

The only "danger" of using a production Cloudron is that you use some CLI command by mistake. Like cloudron uninstall --app <some-domain-by-typo> . The CLI command is less forgiving when it comes to mistakes like that. i.e there is confirmation .

Absolutely. That's an excellent and thorough answer, @james . Many, many thanks. Possible text: This add-on is intended for applications that already support OpenID Connect-based (OIDC) authentication. Apply this add-on to use Cloudron as an OpenID provider with an application that supports OIDC-based authentication. Possible improvement for proxyauth: The proxyauth add-on allows you to put an authentication wall in front of an application. This is useful in situations where the application has no authentication mechanisms of its own, or where there are features that you cannot easily turn off (for the general public), and you want to restrict access using Cloudron's built-in user and group management tools. I think the idea being that, in both cases, a bit more "why" might help. Either way, thank you. All of my questions are answered (including "oh, hey, there was an app packaging topic!").