Installing custom Apps on Cloudron
-
Why not just make a new forum category "CustomApps" ?
One post for each custom app a dev wants to make available
Some 'house rule' that custom apps must be maintained by the original dev, and if that ceases, to update the post accordingly.This totally prevents the use cases of private custom apps.
@Lanhild err yes ... and no
Feature rather than a bug/omission.
It wasn't designed for private custom apps.
It was designed to help those users who hate or are not familiar with terminal and docker building to deploy public custom apps.It doesn't prevent use of private apps - just install them manually.
I could look at extending it for private apps, with more logins / auth to the repos.
Maybe I thought wrongly, but I worked on the basis that the priority is public custom apps, and those with private custom apps were probably ok with building and deploying in the traditional way.
If I got that wrong, happy to review.
-
@Lanhild err yes ... and no
Feature rather than a bug/omission.
It wasn't designed for private custom apps.
It was designed to help those users who hate or are not familiar with terminal and docker building to deploy public custom apps.It doesn't prevent use of private apps - just install them manually.
I could look at extending it for private apps, with more logins / auth to the repos.
Maybe I thought wrongly, but I worked on the basis that the priority is public custom apps, and those with private custom apps were probably ok with building and deploying in the traditional way.
If I got that wrong, happy to review.
@timconsidine My point was mainly about the would be final implementation in Cloudron. If such a feature were to be added to Cloudron, I believe that private and public custom apps should both be prioritized for it. Cloudron is very facilitating on the infrastructure part of deploying code apps, thus why I think this. Your POC demonstrates this aspect clearly.
-
Understood
You got me thinking about how private repos could be supported.
I guess itβs just another login.
But not sure about the pre-built docker image. -
For those not wanting to spend time on installing or using deployed instance, here's a 2min video showing the process.
https://ccai-demo.appx.uk -
@timconsidine very nice! Thanks fo posting notes/progress here. I will comment on this a bit later after our current release, I am all too consumed by it ... I am sure we can steal some of your ideas and maybe even integrate this into Cloudron itself.
-
@timconsidine very nice! Thanks fo posting notes/progress here. I will comment on this a bit later after our current release, I am all too consumed by it ... I am sure we can steal some of your ideas and maybe even integrate this into Cloudron itself.
@girish
I haven't made it into a App Wishlist because it started as proof of concept.But latest version 4.0.9 has been polished and some edge cases (Gitea support, detecting main/master, etc.) have been addressed.
Now it also has a simple catalogue (not in video - I will update it).
Not quite 1-click install, but close.
So it could become an App Wishlist item.You should even be able to use the hosted ccai.appx.uk to install CCAI on to another Cloudron for private deployments !
Yep, stay focussed on your release - much more important.
When you're ready, I think there is mileage in this approach, even if it is re-written from scratch on similar approach.Features not yet addressed :
- support private repos
- discovery of custom apps
-
I've been wrestling with an internal dialogue about strategy or positioning from Cloudron's perspective.
Official apps in the official App Store carry maintenance burdens for cloudron staff, and a significant support burden, so I totally get that Cloudron might want to take/continue a black/white stance on custom apps.
Not supported, not maintained, you're on your own.And by extension Cloudron might want nothing to do with CCAI or something like it, because it facilitates users going in a direction which is not endorsed.
Even though it actually does nothing that a user can't do manually by themselves.But there are some good custom apps from good developers, and an installer might take the pressure off cloudron staff to consider some App Wishlist requests.
"You're still on your own, but we have made it a bit easier for you to try it out if you want to."As I said, potential dilemma, but an interesting one, no doubt with different opinions.
-
@timconsidine this is just my personal view and I haven't discussed with the team yet... I think it's a good idea to have a mechanism to add custom appstores/repos. Say, one can add TimsRepo to Cloudron. You (as a 3rd party) can then offer whatever apps you want there to others. This way Cloudron team is also not burdened with all sorts of specialized apps. I think this is an interesting concept to be explored because it allows service providers to provide custom and private apps.
For example, say Agate/Renato which you have packaged to some extent. You could provide this to others. Maybe even some monetization mechanism for your effort. Atleast, I am quite open to exploring if this model would work
-
@timconsidine this is just my personal view and I haven't discussed with the team yet... I think it's a good idea to have a mechanism to add custom appstores/repos. Say, one can add TimsRepo to Cloudron. You (as a 3rd party) can then offer whatever apps you want there to others. This way Cloudron team is also not burdened with all sorts of specialized apps. I think this is an interesting concept to be explored because it allows service providers to provide custom and private apps.
For example, say Agate/Renato which you have packaged to some extent. You could provide this to others. Maybe even some monetization mechanism for your effort. Atleast, I am quite open to exploring if this model would work
sounds great! for app support you could maybe add a "support" entry for each app in the "configure app" settings which displays the contact information (mail or link to support page) of the maintainer.
something to keep in mind of course is to make it clear who support what.
cloudron system issues -> cloudron.
app updates or issues of the app running on cloudron -> maintainer
issues with the app itself -> app developersmarking the apps with a little icon to indicate who is maintaining it or maybe if the maintainers are somehow "verified"/"trusted" would be nice.
alternative is ofcourse to allow custom apps but make it abundantly clear that cloudron will not support any issues. could be a red indicator in the "support" tab like "not officially supported by cloudron. please contact
support@maintainer.com
for assistance or ask in the forum."either way i would love to see custom app support!
maybe hiding the option for custom apps/app repos under "developer options" or something similar could be a start, so it has to be explicitly activated. here you could also add the info "activate at your own risk. custom apps are not supported by the cloudron team.
-
sounds great! for app support you could maybe add a "support" entry for each app in the "configure app" settings which displays the contact information (mail or link to support page) of the maintainer.
something to keep in mind of course is to make it clear who support what.
cloudron system issues -> cloudron.
app updates or issues of the app running on cloudron -> maintainer
issues with the app itself -> app developersmarking the apps with a little icon to indicate who is maintaining it or maybe if the maintainers are somehow "verified"/"trusted" would be nice.
alternative is ofcourse to allow custom apps but make it abundantly clear that cloudron will not support any issues. could be a red indicator in the "support" tab like "not officially supported by cloudron. please contact
support@maintainer.com
for assistance or ask in the forum."either way i would love to see custom app support!
maybe hiding the option for custom apps/app repos under "developer options" or something similar could be a start, so it has to be explicitly activated. here you could also add the info "activate at your own risk. custom apps are not supported by the cloudron team.
@chmod777 said in Installing custom Apps on Cloudron:
something to keep in mind of course is to make it clear who support what.
NO no no no. This already has "failed" in that the apps that are being custom built and hosted are not done so by their actual app developer! It's being done voluntarily by existing Cloudron users and Forum participants.
Look, Cloudron ALREADY allows use to use apps not in their own official app store. And because most of it is being done by committed users, it's working. @girish, you are dreaming if you think "This way Cloudron team is also not burdened with all sorts of specialized apps." is really going to happen. What WILL happen are people who can barely do sysadmin and can't even install WP on a bare server will start accessing these and blame Cloudon when it doesn't work.
What @timconsidine has written is current and ideal, "Not supported, not maintained, you're on your own." But even that isn't true because here we are on the Forum with the Cloudron team discussing this, "supprting' this, not leaving us on our own. So imagine if something more concrete is attempted? The concern about "maintenance burdens for cloudron staff, and a significant support burden" will materialize. There's no way around it.
When "a user has to be educated about the implications of installing from external sources. " is true, then external appstores and whatnot might be possible. But, good luck with that! As it stands, those who do know and understand are figuring out ways to get this or that app acessible in a given Cloudron. Good. Let's keep it at this level. Let's be happy with a successful Cloudron, and happy with our own tinkering.
-
There is also this topic Proposal: The CUR - Cloudron User Repository
What do you people think of the following?
Adding an input field in the app-store view to directly upload aCloudronManifest.json
.Mockup:
To make this work, a new optional
'key': 'value'
in theCloudronManifest.json
would be needed to add the Docker Image information so Cloudron knows where to pull the image from for this custom app.
Example from @BrutalBirdie custom FounderyVTT app => https://forum.cloudron.io/topic/8296/foundry-virtual-tabletop // https://github.com/BrutalBirdie/cloudron-foundryvtt{ "id": "foundryvtt.cloudron.app", "title": "FoundryVTT", "author": "Elias Hackradt ", "tagline": "FounderyVTT", "upstreamVersion": "13.345", "version": "1.2.0", "healthCheckPath": "/", "icon": "file://logo.png", "tags": [ "game", "multiplayer" ], "memoryLimit": 1342177280, "httpPort": 30000, "manifestVersion": 2, "minBoxVersion": "5.3.0", "addons": { "localstorage": {} }, "dockerimage": "brutalbirdie/foundryvtt.cloudron.app:1.2.0" }
This would make the barrier relatively small in my opinion.
Looking forward to reading your opinions.
@james Nope! Leave Cloudron pure.
If this were to go ahead, I suggest including one of those pop-up notices which require a check-box where the user agrees and understands that maintenance and support ARE NOT provided bym NOR WILL BE sought from the Clourdon team. This could be futher enhanced by not even making it a visible choice unless explicitly requested for by a user via email, who then restarts their Cloudron, gets the drop-down menu, agrees and understands that maintenance and support ARE NOT provided bym NOR WILL BE sought from the Clourdon team, THEN it is activated.
Please do not turn Cloudron into another messy Yunohost.
-
@scooke raises some valid points about user expectations, and I will freely admit that I am not sure where or how the line should be drawn.
Conceptually there is indeed some friction between :
- user is not comfortable installing CLI tools and docker and using them, effectively setting a competence bar and edging them out of this activity
- making it easier to do what they're not comfortable with, effectively lowering that bar and inevitably encountering support requests if/when it becomes normal/easy to install unsupported apps (via @Kubernetes scripts, my tool or an official way)
However I am clear on these points :
- installing custom apps should be easier (hence my app) : on one level, it's purely and simply a timesaver, e.g. for a user who is competent in installing apps, at least that's how I am using my tool currently
- nothing wrong in concept with Cloudron providing an official GUI for installing custom apps (Cloudron has already provided the CLI and know-how for non-gui)
- support line must be clear : Cloudron as a team/business are not responsible for custom apps (not supported, not maintained)
- if properly handled, easier installation of custom apps can reduce forum pressure on Cloudron team for new apps into the AppStore
I like @scooke idea of a pop-up confirmation box or similar : clarity and disclaimer is good.
Whether it goes as far as requiring a reboot of the Cloudron instance, I'm not sure.
But I will add a disclaimer box to my app.Beyond that, it gets a bit unclear for me :
- does the packager provide support (my view : only optionally / voluntary / reasonable efforts)
- do packagers need a reputation score (my view : nice but not viable as a formal rating, who has time and authority to set these, instead maybe some unofficial star rating 1-5 from users with successful deployment of a custom app)
- can an installer for custom apps provide a monetisation mechanism (comment from @girish) which effectively incentivises packagers to work through the AppWishlist (my view : yes, it could, but it's another layer on-top)
- should support for installed custom apps be channelled (a) into an UNSUPPORTED category of existing Cloudron forum, or (b) very deliberately into a different forum (my view : B makes a point but A is easier and more natural)
@scooke said in Installing custom Apps on Cloudron:
Please do not turn Cloudron into another messy Yunohost.
I agree 100% on this.
It must definitely be the goal of any efforts in this area.
Equally, IMHO, standing still is not an option.
We have too many well-intentioned but actually not-our-business "lectures" about how Cloudron should expand, and also too many "please please please" requests, pointing to unmet user demand.
We cannot be like King Canute trying to push the waves back.