I finally got mine...weird though; I had to go into settings to turn it on. Forget where exactly, since I did that a couple days ago, but super appreciate the idea, love the thread, and happily continuing to package several more things (OpenSlides is complete, and I've resumed work on Zammad). Just for the sake of interesting trivia, I've also done a fully custom build that actually builds & deploys itself when a GH release is tagged on its repo, as well as a spike on a fully custom multi-protocol SSO tool (read IdP) intended for Cloudron-only deployment...more on that someday in the future if it lives on.
Definitely want to build the same deployment pipeline you have. And also, I look forward to hearing your SSO ideas in the future. ☺️
@micmc ah I was referring to the deprecation label description in the docs. Not the actual documentation as a whole. I think this might be too much for the moment to start translation that. Also we have no infrastructure currently to support multiple languages there.
I see, yeah.
I guess I could fork the docs and start translating from my side then?
the cloudron CLI needs to be installed on your local machine (not the server)
yes you can put app.otherdomain.com as the location providing otherdomain.com has been added to Domains & Certs
Docker needs to be installed on your local machine for the app building/packaging process
custom builds can use cloudron's MySQL if you specify it as an add-on in the CloudronManifest.json for the app you are building. You will need to reference the credentials in the Dockerfile you are building.
@thetomester13 Fair enough. Yeah it moved around too much. Ultimately what's most sustainable is having them on my git (gethub.ca or git.atridad.dev) and mirroring them on Cloudron git. I just work on them in my own corner of the internet and they auto-magically update on Cloudron git.
For a while it was fully open source. I agree that it would make more sense for it to be fully open source again and so far I've yet to hear any good reasons from @staff or others about why it isn't, see:
The only reason I can fathom is a fear that making Cloudron open source again would somehow mess up their business model due to the potential for copycats to offer the same service for cheaper.
Personally I don't see that fear as having that much risk as Cloudron has a strong community and that is something much much harder to simply copy.
But also, as you mention yourself, I think there are a bunch of people out there who don't contribute to Cloudron because it's not open source, and a whole load of people who don't subscribe because it isn't too.
A crazy scheme I just came up with:
Take a percentage of Cloudrons' sales and re-distribute back to either:
a) existing apps on Cloudron based on popualarity
b) or as a bounty for apps not already on Cloudron. For best quality, add preference for the original developers of the project to bid on the bounty and provide support.
Interesting proposal. Cloudron does already support some upstream projects with both code and money, but I'd love to see it do so systematically!
I'd also love to see more transparency about the finances, how much is coming in and going out and on what. Buffer are a really great example of this, see https://buffer.com/transparency
@samir Those are the main solutions that stood out to me for varying reasons. Its nice to have choice and it kinda sucks that they are all missing a key component to be "Ideal" in one way or another lol I do have faith that these will all get better and one will come out on top though
A new not-what-I-was-looking-for-but-it-works-solution:
I'm mirroring the Dockerfile/project from my local Gitea to Gitlab.
I've set up Gitlab as my registry for the project.
(The project in this case is a Grocy package for Cloudron.)
This arguably gives me a private-enough repo for what I'm exploring, but I was hoping to be able to entirely leverage my Cloudron for this.
I'm just plain confused why, at some point in the past, my locally-hosted registry worked, and now, it does not. This is why I believe there is "crufty" config laying around, somewhere, and things therefore don't work.
(But... this makes almost no sense, because I have uninstalled and reinstalled the registry, so it is not clear how any state could persist.)
Anyway. This remains a mystery, and I would need some explicit guidance as to where I should dig around in the backend of Cloudron to figure out why things are not behaving. (It could also be that there's still some port that I don't have open, or... 🤷)
@grienauer we started out initially with a rocket.chat instance which is still alive and used mostly for internal communication though. Once we had this forum, we essentially wanted the community to move here, since the chat turned out to not be very helpful with issue and solution search-ability. Of course also no public indexing of the channels.