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

[d19dotca]

@fbartels Would CI/CD tooling work well from a mobile device or tablet, do you think? If so, then this is an option too. The main reason I didn’t want to use any tooling that requires installs or CLI is because there may be times where I need to do something like that from someone else’s computer, or a tablet, and places where I wouldn’t have access to those tools without having to install them. This is what I am hoping to avoid by sort of using the App Store deployment model. That way it’s only needed for the very first deployment of the custom app, then it can all be done from the Cloudron GUI. Will also save a bunch of “template” apps in the dashboard from clogging up display space.

[fbartels]

@d19dotca I guess that depends exactly on what you want to use the cloudron cli for. A workflow could look like the following:

• change/update version of a package in the app
• commit the change to git (you could edit and commit directly in e.g. gitea or gitlab)
• this automatically triggers the ci platform
  • this one could do some verification
  • create the updated docker image
  • deploy it to your cloudron

The simples form of this could be a post-commit hook in your git hosting tool.

[d19dotca]

I know a long time has passed now, but I'm re-wondering about this again... any update on if we could get our own private sort of app-store such as we can with Portainer (we can use Portainer to point to our own Github of Docker scripts for example) and others? Would really love to see this in the future to avoid needing to make a bunch of template apps.

In my mind, I almost see a good workflow being someone pointing Cloudron to a Git repo somewhere where there's a particular expectation of folder hierarchies and files, and we can use that to build our own Cloudron apps from there.

One thing that made me wonder about this was perhaps trying to make my own small tweaks off existing app packages, but wanting to have them deployed no different than the Cloudron App Store as it is today. Would this be something we could consider in the future?

[girish]

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

One thing that made me wonder about this was perhaps trying to make my own small tweaks off existing app packages, but wanting to have them deployed no different than the Cloudron App Store as it is today. Would this be something we could consider in the future?

For this one, in 7.2, there is a way to give backups a name and to preserve them forever. So, you can clone with that backup for future apps. I understand the UI is maybe not that ideal like an appstore view but maybe something you can use already.

[girish]

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

In my mind, I almost see a good workflow being someone pointing Cloudron to a Git repo somewhere where there's a particular expectation of folder hierarchies and files, and we can use that to build our own Cloudron apps from there.

A totally custom app store is a lot of work but maybe having a way to import a specific app is doable. This has some security implications, running random docker images on your server is always a security risk. Cloudron's sandboxing is not perfect and it's mostly reliably only because we have a bit of control over the packages.

[d19dotca]

Ah yes, I know the various workarounds such as cloning from backups, but ideally I'd love to see the ability to actually install an app we write (not in the App Store) via the same method we install all other Cloudron-packaged apps.

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

A totally custom app store is a lot of work but maybe having a way to import a specific app is doable.

I don't think a "totally custom app store" is really needed here. I'd think it could be something similar to what already exists out there that Cloudron can model off of such as Portainer's additional scripts feature where you can point to your own GitHub repo for example for custom apps, and it's simply in addition to the existing ones baked into Portainer. I believe CapRover does the same type of thing too. I don't think we need to totally re-invent the wheel, just need to define a structure that anyone can throw into a Git repo and have their own apps merged into the list with the official ones too.

Of course I get that it's way easier said than done so I appreciate that it'll still be a lot of work, but I don't think it needs to be overly complicated and can re-use parts of what already exists out there which should help keep the work down a bit.

[robi]

@girish what about adding another category to the existing app store, where a collection of unpackaged apps can be browsed and installed based on the contributed configuration by someone who got it to work as such.

Maybe the requirement is it must be a functional git repo and minimal script/dockerfile to get it up and running.

This feels like 10% on the road to packaging already.

Later if there was a UI to accept incremental changes to the script to bump up that % completion, apps as they are used would end up self-progressing towards being fully packaged by user need.

[nebulon]

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?

[timconsidine]

@nebulon I kinda agree, but for some (many?) they are not too comfortable with terminal and git clone concepts, or it is just a hassle if you don't do it regularly.

I certainly confess to some 'fear / ignorance / laziness' until I overcame. Maybe tutorials (discussed elsewhere, especially the terminal screen cast) can help overcome this for some.

Having said that, the Cloudron one-click deploy is a pure joy, so it cannot do other than help Cloudron's adoption to have a GUI type process.

Personally I'm happy with current situation, but I can understand others would welcome a GUI.

[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.