Hi everyone, I just launched https://easyindie.app to promote the idea of self-hosting via ‘one-click install’ systems like Cloudron, Caprover, and Yunohost. Any feedback is welcome and the code is open-source.
Hope this encourages more people to own their data.
thanks to everyone for the feedback, great to hear you are receptive to the idea.
i'm personally super excited to get cloudron working for myself, it feels like the slickest and most robust option. i had it working but i need to save up so i can purchase the full version. congrats to this community on creating something so awesome and empowering with a sustainable business model too, y'all are trailblazers.
@girish Interesting, there seem to be many 'alternative' lists like this:
but BTW focuses on open-source. None seem to focus on 'easy to install' though…
@timconsidine thanks! it's actually 'comfortable text reading width' which i carry over from blogging and writing, but i might want to rethink this as it's not text-based ;).
i need to also have other options for going through the list, i never thought people would 'go through' it, assumed that people search for what they know already.
thanks again for all your great feedback. i have truly underestimated how important it is to browse via list and will make sure to add that next and let you all know. i actually had that working before and took it out! 
re: the discussion about comparing platforms, i thought i had built in a filter for platforms but apparently i didn't, so i quickly deployed that now. you can search for 'yunohost' for example and see the apps that are there. might be easier to spot which ones aren't yet on cloudron. and of course there is the export of project data https://easyindie.app/projects.json for those who like to wrangle json.
The number one feedback from various communities is to show the apps as a list instead of icons, made a small update for this today. Hope it's easier to navigate:
Is there a faster way to get an app to the latest version than manually triggering the update for each version between the current and latest? I didn't upgrade to Ghost 5 for a while and now I can't jump to 5.9, I must go through 5.4, 5.4.1, 5.4.2, etc…
@jdaviescoates The "App Passwords" is a pretty amazing feature, didn't know about that. I tried it and it works well, but it's still possible to login with the main account. I guess I worry that if someone can brute force guess the main account via one app, then it compromises all the apps…
@girish the icons are a bit shaky, i'm trying to fetch them and serve them from my domain, but i had deployment issues and wasn't able to fix it in time. hey it works on localhost 
hmm the deep linking is a good idea, i was more focused on making sure people install because i think the cloudron interface is excellent and will carry the rest of the way. thanks for the info will make a note for later.
@jdaviescoates Makes sense, I forgot about that option.
It seems to allow me to login only via a specified account which is great, but if I try to move my data from the old installation via Cloudron backup, I get this error:
Invalid configuration for YOURLS LDAP plugin. Check PHP error log.
Maybe it's copying the Access Control settings for the app?
Is there a faster way to get an app to the latest version than manually triggering the update for each version between the current and latest? I didn't upgrade to Ghost 5 for a while and now I can't jump to 5.9, I must go through 5.4, 5.4.1, 5.4.2, etc…
@BrutalBirdie I did also check but I think I'm at 60% of capacity.
@nebulon ok I was able to grep 0data * to find the file with chat.0data.app and deleted it, then ran systemctl restart nginx without issue. All is good.
@nebulon said in Inaccessible because of expired certificates:
remove the nginx configs for those two apps
How do I do this?
@nebulon said in Inaccessible because of expired certificates:
Afterwards re-save the location setting of the ghost instances through the Cloudron dashboard (or hit repair depending on its state) to rebuild the nginx config for it.
I had re-booted the droplet and can't seem to access the dashboard anymore, but maybe the first thing will resolve that?
FYI there's a typo at journactl here https://docs.cloudron.io/troubleshooting/#nginx-error
(sorry I can't figure out how to sign into your GitLab)
I am getting some kind of nginx error but i think it's different
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: Starting nginx - high performance web server...
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 nginx[6173]: nginx: [emerg] cannot load certificate "/home/yellowtent/platformdata/nginx/cert/chat.0data.app.cert": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/home/yellowtent/platformdata/nginx/cert/chat.0data.app.cert','r') error:2006D080:BIO routines:BIO_new_file:no such file)
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: nginx.service: Failed with result 'exit-code'.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: Failed to start nginx - high performance web server.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: nginx.service: Scheduled restart job, restart counter is at 5.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: Stopped nginx - high performance web server.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: nginx.service: Start request repeated too quickly.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: nginx.service: Failed with result 'exit-code'.
Jun 09 07:24:43 cloudron-ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: Failed to start nginx - high performance web server.
Two of my Ghost installations are not accessible because of expired certificates, and it seems the Cloudron installation is also not accessible for the same reason. How can I resolve this?
I changed the "User management" section in Cloudron to enable only one specific (non-superadmin) user, but it seems like I can still login with the superadmin credential. Is this by design?
There's also https://community.tt-rss.org/t/typeerror-window-requestidlecallback-is-not-a-function/1755/26
To ‘just make it work’ on a server:
Create themes-local/local-overrides.js
Put a content of https://github.com/pladaria/requestidlecallback-polyfill/blob/master/index.js 97 there (a polyfill for this property).
Done
@girish said in Disable Cloudron user login:
go to the filemanager of the new instance and delete the
/app/data/user/plugin/yourls-ldap-pluginand see if that helps.
Bingo! That was what I needed. It was actually a symlink and not possible to delete via the file manager, but I was able to rm yourls-ldap-plugin via the shell and then restart the app. Works as desired now, thank you 