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

[girish]

@d19dotca The closest we have to what you are asking for is the 'clone' feature. Install the 'baseline' image the first time, take a backup and stop the app. Then you can just clone new apps from there.

I think this is how many people create app templates right now. For example, create a properly configured WP installation installing many plugins and customizing theme. And then just clone from there.

[d19dotca]

@girish yes that’s what I do already, but it’s be nice to not have so many template apps laying around as it starts to grow. Would be nice to hide that and deploy the template from the App Store area of Cloudron. Maybe a tab in the App Store for custom local apps or something.

[marcusquinn]

@d19dotca App Tags?

[d19dotca]

@marcusquinn App tags don't really solve the problem I'm describing though. If you think they do though, can you please elaborate? In general I've refrained from using app tags except for my primary infrastructure apps, because it's just a PITA to manage them when I'm managing so many apps.

[girish]

Extending an appstore is an option but it's a bit of work. 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).

[fbartels]

Hi @d19dotca,

while I think your use case could also be satisfied (maybe even better?) with some sort of CI, I have been thinking about 3rd party stores for a while as well.

But getting back to the CI. When its just a single server where you want to update/deploy to then this could be relatively trivial. I did spent a bit of time on packaging up the cloudron cli for Drone some weeks ago, but paused because of having troubles with docker in docker.

[d19dotca]

@girish Yes I think that’d work well. In some way, it could be as simple as making an app with the intention of being a custom app template, marking it with some feature tag called maybe “custom app template” or something like that, which then just moves it out of the main Cloudron dashboard display and into the App Store deployment page. This would keep the dashboard cleaner (imagine several template apps taking up two rows, all removed with this feature), and force more of the mindset in deploying apps using the App Store page. That’s one idea anyways.

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