@girish yes, seems to be entirely self-hosted.
There is no landing page or app front page.
You get an error if you try to access the URL.
It just needs to be running, and then typically in the settings of a browser extension (under Advanced) you can specify your custom url (in form of https://app.domain.tld/v2)
LanguageTool is one of the built-in "services", as they call their packaged apps. Terminology a little strange, but hey ho.
So really it is just a question of :
installing Coolify (which has nice easy install script),
setting up the FQDN for Coolify,
specifying a "destination" (docker)
selecting the Services link in the left sidebar
press the + button and choosing LanguageTool
select the 'destination' (docker), fill in the blanks including the URL for the 'service'
remember to actually start it ! (doesn't auto-start on installation)
That's all that's needed from memory.
I can reinstall the service if you need 💯 % certainty of steps.
Coolify is interesting, but quite sparse in terms of apps.
Not a patch on Cloudron.
Seems more angled to deploying own written apps.
Links to Github nicely to pull repo, but I can't get my Cloudron Gitlab linked.
@ruihildt Updates to packages are rolled out slowly. So if a user tries to check for an update manually (i.e they click for 'check for updates') and they are not part of the rollout, they get shown that message. Generally, it is safe to update anyway but we are just being careful here.
@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.
@rmdes Yes, I have been doing some load tests with Cloudron app vs Vanilla WP vs OpenLite Speed. Generally, having redis is not much of a difference. What makes the big difference is static page caches like W3 Total Cache. It's also the reason OLS on first run appears so fast (it has a cache plugin enabled by default). Redis cache is for objects and dynamic pages, it's not going to make things much fast.
Note that one pain of these static cache plugins is that you have to clear the cache manually (or set some timer to re-generate the cache).
After thinking about it, the graph chosen is better to view memory usage (which fluctuate much more than disk).
I would then suggest separating both information:
keep the current graph for the app usage (the Y axis adapting to the app using the most memory)
add a bar for total memory used, modelled on the total disk usage (could be a single colour for memory usage)
total disk usage
This would help maximize the amount of information you can visualize in one go and help detect spikes better.
Both ActivityPub federated. A federated model for Reddit-like boards are interesting, as it brings the ability to selfhost specific subboards you’re interested in hosting while still be part of one big network of boards.
This is why I’d vote for a federation-friendly software: writing clones of popular services isn’t what’s hard anymore, amassing the network of users is.
Right now with cloudron, some apps supports LDAP, some don't.
If I need to do a cloudron setup comprising apps that are all LDAP, I of course use LDAP in order to get one login to rule them all.
But if I do a cloudron setup where an app is not LDAP, I prefer to have all app not using LDAP.
It's confusing to have to explain to people that for those X apps, you need to use the same login, but for those X apps, it's separate logins, even though it's all based on the same main domain.
That's why I prefer to have both LDAP and non LDAP version of an app available.
In the case of Firefly, I think LDAP is even less useful, because it's personal finance and probably less useful in an organization context. For example, if I want to give a Firefly instance for a friend, I don't need to have an additional LDAP user. I'd prefer to have the friend has its own login with the app.