@nebulon If I understand the dynamics introduced by an open source licence like AGPL, someone having the access to the source code, and in fact having the source code, does not make them a "user" of Cloudron. They simply have the software and can install it and do whatever. But when they have problems, as they surely will because of Docker, where will they turn to? Most likely the original creators of the software... and when you and @girish can't help because of other time constraints, I can imagine the complaints and badmouthing that would follow. This would potentially have the effect of Cloudron (the subscription service) getting a bad name, losing customers, and eventually going out of business. So it makes sense to me that you've tightened up the licence so that the amazing user experience can remain intact and manageable.

I am not an open source purist, starting from the fact that I have no control over the VPS I rent on which I run Cloudron. It is, as someone in your chats said, a compromise for a purist. For the rest of us who don't want to pay an opaque behemoth company anything, Cloudron is simply the best. And it has the open source spirit, if not the correct licence on every bit of code. And importantly, the software actually works, a theme that I've repeated a few times on different threads. I applaud the Cloudron team for making decisions to enable them to keep the software open AND working.

You already have the option to install apps from others in a general sense because of Docker.

I pay for Cloudron not just because it is Docker-based, but because of how easy the devs and admins and owners have made it to use. I think adding unsupported apps to the mix even more will distract from the appeal of Cloudron. The extra apps that are available are there because the app is in the pipeline to being added to the official Cloudron store; they have been/are being worked on by people who like the Cloudron approach and want to add to that, and not to a Docker-experience in general.

The price jump from no-support to support with nethserver is a huge jump from 48€ to 250€! I think Cloudron has a good pricing structure because they have limited what they have to support. To address one of your first points, I left Yunohost exactly because of how many low level quality apps that they have, and all the hassles and problems that approach introduced. I wouldn't want to see Cloudron go that route. I like the line being thick! I am already receiving all that I hope for from Cloudron.

All that being said, I think we already have a pretty good 'community repository' of helpful users and super helpful admins. For anything that I want to do that is beyond what Cloudron offers, I just tinker away on my other VPS.

Yes, and no. I followed Digital Ocean tutorials, and others from different sites, and conceptually there was a lot I didn't understand. This was challenging when something broke and I didn't even know what happened. But over time the tuts made more sense, the terminology was sticking, the concepts became clearer, but the amount of work and time needed to maintain and monitor the server didn't decrease much. The new Ghost works really really nice compared to how it started, and if that is all you will have running on the $5 server then you should be fine. Just always make backups of the Ghost app and assume at some point something will go wonky, or you will even get hacked, and learn from the experience. Restore from a backup and get back at it.

On top of the server though you have domain/DNS issues to understand and maintain. This can be tricky too, but over time it all gets clearer.

That said, using Cloudron is such a treat. Because I tinkered around on my own for awhile, I now better understand what Cloudron is doing, and how and why, and so it makes it that much nicer to use. But if you are starting from zero, then it is still a great way to get your Ghost site up and running. You could always familiarize yourself with webserver things locally while using MAMP or LAMP on Linux or...XAMPP (or whatever the windows version is called); and get used to servers locally with VirtualBox or VMWare and spin up an Ubuntu image and use it as a test server.

I will add that using Cloudron to run a Ghost app is advantageous in that you will also have the option for the built-in email server, and the option to install other apps that use Apache rather than nginx, or for that matter, php instead of nodejs; I still find it challenging to run php apps that would usually run well under Apache on an nginx server if the main app is a Ghost app, and vice versa, getting a Ghost app to run under Apache so that the other php apps can remain undisturbed. Cloudron makes this mixing of apps seamless.

As I've been looking for WhatsApp replacements I came across Beeper. Now, it doesnt' actually replace WA; it is however a pretty nifty looking unified chat hq, built on Matrix, and it self-hostable. They even provide a great Ansible playbook over at github - https://github.com/spantaleev/matrix-docker-ansible-deploy.

Just to repeat myself - this doesn't replace any chat services, but it provides a way to use many different chat services in one interface. I've tried things like this back in the day and never really liked it, but for some reason this one looks promising, probably because it's based on Matrix, which is something I'd like to use more anyway, and see wider adoption.

Looks like it is pretty much ready to plug in to Cloudron too, but those with the skillset!

I love Cloudron. I love the increasing number of apps offered. But will there eventually be too many for the Cloudron team to manage? I'd hate to see Support quality, or quality in general, decrease just for quantity. If there is to be a limit, how will it be determined? By install number? By usage? By active maintenance by the git repository/project owners (not Cloudron)?

You could install LimeSurvey and give it a try for all of us!

The replies seem to be coming more from developers lately, people who have skills enough to contribute, who also hold strong beliefs about open source. This is good, and by and large it is pleasant to see an overall positive approach to Cloudron.

I am a non-developer, but am also someone who likes the idea and principle of open source. I want to get away from proprietary apps and data lock-in. From my perspective, Cloudron has been an incredible way for me to learn about and access a plethora of open source apps, the delivery of which just works! I hope the various principled devs out there can appreciate a users perspective like mine, and just how radical Cloudron is. I've tried other open source attempts, and frankly they are all lacking in deliverability; checking out their forums reveals not even the devs can figure out what went wrong when something does; and rarely it seems are the project heads in the forums, like the Cloudron Team is, since the resolution of any problem relies on the upstream devs pushing fixes that may or may not come in time. What a mess for a user like myself, and I think there are many many users like myself. I think we are one mid-layer that will help make open source more understandable, reachable, and friendly, to all our non-techy families and friends, they who think only of Skype, Word, Facebook, but themselves are increasingly becoming disgruntled. They will never read certain /r/ nor news.ycombinator.com articles, but they will listen to me when I set up an open source chat instance, using a vanity domain, with email, on Cloudron, and it just works!

Another positive aspect of Cloudron's approach is that they don't try to cloak the open sources apps they offer as though they are something the Cloudron team created. I've come across a few such endeavours, and it worries me when I think there are regions and countries that think ****blog, *****forms, *****pad are all made by *****soft! It verges on deception, even though, after some digging, a user can find out that the software is actually made by other open source efforts. I hope this means that as more people hear about Mastodon, or Element, or booktype, etc., and look for options, they will be led to Cloudron. I for one came because I couldn't for the life of me get Rocket.Chat, Taiga and SOGo all running on the same server, by hand. Not a problem for Cloudron!!

Keep it up!!

@jdaviescoates I went back and read a link you shared, a convo in a Mastodon instance, by someone who seemed to brush away Cloudron's approach and mindset automatically. I wouldn't take that opinion expressed in such a way seriously, especially since they didn't in any way outline exactly how they can see Cloudron managing or limiting access. I mean, the first and most important part of Cloudron is that we host it ourselves on our own servers and backup things to destinations we control.

Somehow the negative viewpoint (not saying this is yours) that Cloudron has benefited off the back of open source projects ignores all that it conversely has done to broaden each projects exposure, without (I assume) asking for financial renumeration from those projects for doing so, nor excluding projects if they won't pay up. I think if Cloudron went that way then a negative view of Cloudron would totally understandable.

I can take a step back and look historically at all the times I tried to self-host something, and got stuck, with minimal help from said-project's forums, and came away with nothing, and remember thinking, "I'd pay some one to help me with this!"... voila, that is the role Cloudron has played. I share your enthusiasm for this project!

Like you (in the mastodon thread), I tried Yunohost and Sandstorm and the like... just too many complicated problems that no help from forums could provide. They always forced me back to doing it myself: I've had a heck of a time trying to get nginx and apache running on the same server; I've never successfully gotten docker or docker-compose to seamlessly add services or apps to an existing two-app setup (mysql and wordpress) even though it is supposed to be so incredibly easy (even with the promised answer of portainer). I can setup and run a basic VPS running LAMP... going beyond that.... I am soo thankful for Cloudron!

I wonder if the licencing can play a role in how much ownership @girish and @nebulon and the Cloudron team feel toward their code and their subsequent "responsibility" to keep it running well. I mean, if it were as open as can be, and others started forking it and running it and offering their own specialized subscriptions for their version of Cloudron, I could see that there would be some run-off of problems and complaints back to the Cloudron team that this or that isn't working on Fork A or Subscription Service D, and then they end up maintaining code for ideological reasons rather than offering and improving a service for productivity and (user-)independence reasons.

@jdaviescoates Do you mean selling the web service as Cloudron software, meaning, the client knows that they are paying for a Cloudron installation? Or do you mean selling webservices based on a self-hosted Cloudron? I have about 4 clients Wordpress sites hosted on my Cloudron, but none of them know how their Wordpress site is live, nor do I think they'd be interested necessarily to know about Cloudron, per se. I do have another client whose Wordpress site I've set up on a Cloudron install that will likely remain dedicate to just their site (because they may want email and chat options), so at some point I think I'll introduce them to the Cloudron backend.

Personally, I've been aiming to promote self-hosting, and totally see Cloudron as being an integral part of that to the clients I'm working with now, and and future ones. In some ways I might be losing income in that I'm trying to empower these users to eventually run with their Cloudron install on their own, but I also see that the service/maintenance/training side of things will probably still be needed.

Last week I was about to ask anyone their recommendations for an audio app. A quick search of the forums didn't turn up anything specific. So, I thought I'd install the 4 above and give them a try, and report back.

I did not try Jellyfin this time as I had previously tried it out on my cloudron and it slowed everything down (about 6 months ago?). Who knows if its better now; I just want something that works.

That is the gist of my requirements: Does it work? Can I install it, and then move my music into it, and play it, with minimal hassle. Features weren't necessarily the most important. Here is what I found.

• Ampache: I was actually looking forward to this being the winner. I've known about it for a long time, and was excited to see what it could do. Alas, despite several tries, and even checking out a few posts on the forums here, I could never just upload my 31 files (30 songs and a playlist file) and get them to play. I couldn't even get them to appear in the library! Sure, more troubleshooting may have solved the problem. But, my criteria was not, "Which app will take up the most time troubleshooting and consequently result in the greatest satisfaction that I persevered and made it work." So I turned off Ampache.

• Emby: This one seemed promising. The First Time Usage clearly showed me where to place my files. Like Ampache, I made sure the files were owned properly. I uploaded my 31 files... but they also never appeared in the Emby dashboard. Give me a break. Why should this be so hard? Sure, there is probably some "trick" to get this to work, but I'm not looking to become a magician just for my music.

• Koel: Cool logo. Cool history. Seems less cluttered than the previous two... maybe this would be the one. Like Emby, I could see where the files are supposed to go. I put them there. Unlike Ampache and Emby, I could actually see my individual songs. BUT, they weren't playable per album! Surely not?! But yes, even though there was a view for Album, I never figured out how to play one entire album. I could have made a playlist, but hello, I'm pretty sure Play by Album is a thing in the music app world. I did not have time for this. So, I turned off Koel. Bye bye slick interface. I just want to install an app, upload my music, and play it (by album). Is this so hard??

• Navidrome: The last contender. For some reason I kept thinking of Mel Gibson and Tina Turner in their seminal Mad Max movie, Beyond the Navidrome. I was expecting yet another battle, in a navidrome, to get my music uploaded, visible, and then playable (by album). I installed it, read the First Time Use, uploaded the music, fixed ownership, started a rescan in the app, and what do you know... there was my music. I could view the 30 songs in various ways. When I wanted to play the entire album I just clicked on the recognized playlist file, then pressed PLAY and all the songs played! Hallelujah! Navidrome was the winner. Everything just worked. I listened to my music for hours. I will be uninstalling the other three and sticking with Navidrome.

NOTE. I did this a few days ago. I have quit my browser, obviously, and just went back to my navidrome install to resume my music heaven... but it was asking me to (re)make an admin account? What? I already did that, it was already working. Fortunately there is a solution in the Cloudron forums, and I had to login with an incognito window, but, it was all there and it was all working.

I should also add, to be as clear as possible, that "Play by Album" actually doesn't seem to be a feature in Navidrome. At least, not the way I arranged my album. My album is a collection of songs downloaded from an auto-generated YouTube playlist using 4K Video Downloader. 4K includes an option to generate a m3u file when downloading a playlist. So it was this m3u file that Navidrome recognized and displayed, and let me play my "album". Since I get most of my music these days in a similar way, the m3u file recognition was the best part of Navidrome.

As I mentioned, this wasn't a feature comparison, so I don't intend to insult or disparage any die-hard users of the other apps here, nor denigrate the creaters. I just simply wanted to install the app, upload the music, and play it. In this respect, on my setup, using minimal troubleshooting, only Navidrome met my expectations. You may have better luck with your installations; your own Navidrome install might not work! But if you too are looking for a music app that just gets installed, and gets playing your music, I suggest Navidrome.

@scooke Ah, now that I've uninstalled my previous 0.13.0 install and installed the newer 0.16.0 from the Cloudron store, I do now also get the {"message":"Internal Server Error"} message.

@humptydumpty Interesting, I actually did not realize this app was not getting updated. I'm actually running 0.13.0 on Cloudron, not the latest in the Cloudron Store! Good thing I've not really committed much data to it. I will upgrade my current Vikunja to the latest on the Cloudron Store, and try the Windows desktop app again. Maybe this time it will work.

@nebulon This is somewhat related, and the answer may already exist - is there a way to have the apps named for the backups? Such as prepending the domain, or the app name, to the long string? I've been in similar predicaments when trying to locate the backup for an app. Obviously, as I've started doing, one answer is to make a list, maybe in excel, of my Cloudron apps, their locations, and the probable backup name (which I gleaned from the Storage window for each app wherein there is a line telling me the location of the app within the cloudron, such as /home/yellowtent/appsdata/4145s2c0-hbs57-2g8n-kiw3-2h89si6d82y9 so that when I am looking for a backup I can compare the lengthy names used. But it would be much faster if it looked like /home/yellowtent/appsdata/location-4145s2c0-hbs57-2g8n-kiw3-2h89si6d82y9.
There is probably some reason, such as location reuse confusion, but I know that would have helped me a number of times. More directly to your question, maybe it would help someone find the Cloudron-based backups and delete them, so including the date would also help, I guess, and thereby clear some room out.

@humptydumpty said in Desktop app login issue:

e/api/v1/info

I just checked the same, curious, and received:
{"version":"0.13.1","frontend_url":"https://vikunja.example.com","motd":"","link_sharing_enabled":true,"max_file_size":"20MB","registration_enabled":true,"available_migrators":null,"task_attachments_enabled":true}

I wonder if any of those setting might be affecting your Cloudron app. For example, does "link_sharing_enabled" have to be true? I have no idea, I'm just trying to add to the discussion.

EDIT: I just downloaded version 0.16.0 for Windows and received the same error message. So, I guess it ain't the settings!

@marcusquinn Never give up.

@robi @marcusquinn This looks like it would be great for teaching and learning English (and I guess any other language). Old-school Language Corners could go digital!

@marcusquinn Hang in there @marcusquinn. Bonne courage.

@msbt I recently used Nextcloud for something similar and it was sooo nice to be able to make an upload folder for different people, and them only. And then it was all on one central site making it easier for me to use the images and txt files they uploaded. Plus, you get to either buy a cool new domain, or use a subdomain of the cool domain you already have for the event. Makes it seem more "professional" to me.

@jdaviescoates I like that they are still using Cloudron. It's interesting to me that their user-initiated installation all takes place on and from the local machine, not the server. That actually worries me because if my laptop dies, and I haven't made that most recent backup, what happens to my server setup? I like that Cloudron can do its work on the server. Of course, this point has not alot to do with their reason (morr libre) for trying to move away from Cloudron. I just thought I'd check out the blog and the service since you mentioned it. Seems easier to use than caprover, albeit with far fewer ready-to-go apps.

@doodlemania2 I'm just in the process of setting up a new instance. I wonder if I could ask your opinion about something. I'm partial to a shorter address for the users, leaning towards @me@example.com, rather than @me@mastodon.example.com. Is there a good critical reason to use a three part domain for the Mastodon url (mastodon.example.com), or can I just stick with the shorted one?

I wouldn't mind including your relay. I'll pop the details in two instances at first, but I think I will eventually just stick with one. Thanks!