Feature request: Add custom app to App Store for local Cloudron

[d19dotca]

@nebulon said in Feature request: Add custom app to App Store for local Cloudron:

I do wonder though, why the current approach of cloning such a git repo locally and just using cloudron build && cloudron install on the cli is not sufficient? In the end it seems this then is just a UI bit to those three steps. Maybe an official list of such git repos is lacking mostly?

That’s an option too. However where I think that falls short is it’d require me to be at my desktop anytime I wanted to deploy a new custom app like that, wouldn’t it? Where-as if I already have the custom app installed / loaded from a repo to Cloudron, I could easily be remote and launch a new app instance from my phone or another persons computer if needed.

[robi]

Would not having Portainer as an App allow us to manage containers and allow for trying any new unpackaged apps straight from dockerhub or other repos?

This works well having tried the demo in Runtipi.

This would solve the single DB App needs, custom LAMP setups and all the cool new stuff we want to try.

Another option would be to have an empty Appless App where one can manually install any other app, managing things oneself.

A nifty option is using Docker-in-Docker via Nestybox where in one container you can run further docker images nested and more isolated with better security.

All these need a way to configure the ports, via App settings or during install, so it's accessible via the system Nginx reverse proxy.

One app solving many requests, yes?

[infogulch]

The main issue is that a "Cloudron App" is both 1. A Docker image, and 2. Metadata that includes CloudronManifest.json, thumbnails, screenshots, etc. For official apps this metadata is hosted in an index on Cloudron.io servers, and for the cli metadata is uploaded from the current directory. If there was a good way to host and retrieve the metadata, one might imagine a "local app store" which the owner could add to their instance by simply entering its docker registry image uri.

Note that this metadata hosting problem is non-trivial. For example, if the Cloudron team allowed third parties to list their own apps on the cloudron store then they would be responsible if the apps contained something bad (regardless of any waivers to disclaim responsibility), so that's a nonstarter. Alternatively, dropping the metadata files in the image would require the server to download the whole image just to list the metadata -- not very practical.

To that end, last year I started developing docker artifact (hosted with Gitea on my cloudron! ) which I believe will be able to treat individual image layers hosted on a docker registry as a generic 'artifact repository' which would allow you to precisely and efficiently download just the docker layers that contain the files you specify (say, CloudronManifest.json and images...). I believe this would make alternative 2 from the previous paragraph practical to implement as long as you take some care when you build your image. Currently it's stalled on technical issues (see issue 10 with my notes), but check out the README for my aspirations for the project.

[robi]

@infogulch

One option would be to include all the Metadata as a layer for the image, making it self contained and having its own layer ID.

That way we're tagging what is needed.

JFrog did this in a similar way, see https://jfrog.com/knowledge-base/what-is-the-docker-image-layer-marker/

Much simpler than tagging files across multiple image layers, etc.

[infogulch]

@robi Yes that's the idea, the docker artifact tool is a mechanism to identify and tag the layers so that the layer that contains the metadata is queryable via the docker registry api.

[robi]

@infogulch that's a bit odd IMO to have to find them, as they should be explicitly defined.

Perhaps make a post in App Dev section to get assistance with the solution you're working on, as a step in the right direction.

[tennox]

Am I reading this topic right that there is currently no way to install an app from a git repo apart from either:

• submitting to official app store
• using CLI
  ?

Would love to make our app available to install in an easy way, but not ready for app store publication (yet)

[marcusquinn]

Hi @tennox, welcome to Cloudron! What's your app? Does it have a Wishlist post?

• https://forum.cloudron.io/category/5/app-wishlist

[tennox]

Hi there @marcusquinn

I'm working on packaging a ready-to-roll IPFS node with:

• kubo (which was requested in this wishlist ... by you )
• a ucan proxy to enable an authenticated upload API

See this ipfs forum post for the origin story

I have successfully packaged it & deployed it to our cloudron, with a few open questions left (like configuration), and when it's ready I would submit it to the cloudron app store - but I would love to be able to give users an option to install it without needing to clone the repo and running CLI

[robi]

@tennox said in Feature request: Add custom app to App Store for local Cloudron:

I would love to be able to give users an option to install it without needing to clone the repo and running CLI

I think you can build a custom webUI to do just that with the Cloudron API, perhaps coopting n8n for any initial testing.

This is a greater need in general, and could include other useful features like migrating apps from one Cloudron to another leveraging the App install/restore process.

[robi]

@girish said in Feature request: Add custom app to App Store for local Cloudron:

I am trying to see if we can do some trick to make this less work. What is you could download a "template" and then we had a button in appstore view that says install from "template" ? I know this is not as cool as integrating with appstore but will it get the job done for now?

(Reason I ask is we already have the backup config download feature. If we add the docker image id or appstore id to it, it's already a template at this point).

How difficult would it be to make this happen in a few hours? Like in a separate DEV section of the App Store view?

Option 1: accept backup templates link from custom running apps for install

Option 2: accept valid git repos link of custom packaged apps for install

This doesn't disturb the release box code, need separate registries or cli installs.

[bmann]

I think git link / image registry link is the most flexible.

Essentially it could run the code that Cloudron CLI runs anyway.