@nebulon said in Other pricing model for small installation:

dev license

and for the dev license, it is one dev license per server/installation ?

Our subscriptions are per Cloudron instance, so per server. We might add multihost or some kind of cluster feature in the future, but so far there was no strong focus on this yet.

@nebulon said in Do the Cloudron MailServer have a TRACKER_ID ?:

thunderbird plugins installed?

you got me, I forgot my mailhop plugin ;s

OK, I did another round of searching for answers.. I understood a lot from these two posts - https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html and https://schub.wtf/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html (from one person behind diaspora).

It seems the apps started out initially just federating with instances of themselves. When this was the case, they used webfinger for discovering accounts and information about an account. All the apps are just using @username@installation_domain (and not root domain). Peertube has no setting like LOCAL_DOMAIN - https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example#L6 . Same for pixel fed - https://github.com/pixelfed/pixelfed/blob/dev/.env.example#L7 . I guess nobody has gotten to the point of having the same @username@rootdomain to be used across apps. This makes sense because the apps don't really talk to each other apart from providing an activitypub stream. Think of it as each of those document editors supporting MSXML. None of them could load each others stuff in the very early days.

In essence, the correct approach for Cloudron for now is to not let LOCAL_DOMAIN be configurable in mastodon. It's just confusing that it even exists without the surrounding standards to support it across apps.

Thanks, I have added both to 4.5 roadmap

wow that’s way more than cool! i’m gradually discovering the magic of Cloudron. Loving it!

Great news! Than I can install on my small server. Have a nice evening

@jdaviescoates You are welcome to suggest merge requests to https://git.cloudron.io/cloudron/docs if you have lots of minor changes (and it feels painful to open a forum thread/suggestion).

In the past, I think people have recommended integrating with netdata. I don't have experience with netdata but wanted to throw the idea out there.

Other than that, current graphs is rendered using data collected by graphite/carbon.

My point of the 443 port issue was so ya'll could fix the docs. I have manually setup SRV records, that's why I thought it'd be nice to automatically set them up. Also, I meant to put this under discussion, not sure how it ended up in support. Thanks.

BTW: There are now official docker-compose scripts: https://git.tt-rss.org/fox/ttrss-docker-compose

@nebulon said in Feature request: Optionally restrict user profile editing:

That sounds like an important use-case indeed and goes into a whole field of more fine-grained control over what users can and cannot do. So far we have tried to not overcomplicate the access control settings, but we are open to small useful adjustments. Given that Cloudron has a special permissions group, the admins and then simply the rest of the other users, would it be sufficient for your use-case to have an admin setting to prevent non-admins from changing their own profile? And if so, what fields should be protected?

agreed!!

The dark mode is good but in some conditions.

@msbt said in Piwigo vs. OAuth Login!!:

Hey @williamgomes,
that error animation is mine and I eventually fixed it, you can find the repo with a working version in this thread. However, a few plugins are not working properly because they use an absolute path (which is non-standard in this environment), which then requires you to manually edit the path in the plugin files to make it work.

I haven't updated to piwigo 2.10 yet because I currently don't have an active gallery, but I reckon you could fork it and just replace the version number 😉

THX for help!

@necrevistonnezr said in Runcloud.io vs ServerPilot.io vs Cloudron vs Sandstorm:

I don't remember this link being there (that you removed) when this topic was opened a few months ago

you can see the edit history of a posting. It was only added on the 19th of november at 23:40. Honestly also @KathleenMcArthur feels a bit like a spam bot posting backlinks to earn some referrals.

Hi,

I'm very sad to hear that Cloudron core code has become proprietary software. Like @ryangorley, I've always been promoting Cloudron as a great well-supported open source self-hosting option.

I too want you guys to succeed but I fail to see a valid reason to turn Cloudron into proprietary software if it is still being developed in the open.

My thoughts on the reasons you gave:

The technical reason is that the code base has subscription, appstore and sign up logic. It's unclear what the license should be if it requires the cloudron.io service to work.

I-am-not-a-lawyer but I'm pretty sure that you can still be under an open source license. I mean, the situation is not "ideal" as an user can't easily self-host without relying on the cloudron.io external service, but anyone is free to create a fork and reimplement these functions. Also, I don't know if it's the case anymore but we used to be able to install cloudron Docker packages built manually without cloudron.io. So in a way, Cloudron was self-hostable, just without the user friendly App Store.

The non-technical reason is that we were spending too much time explaining why we call ourselves opensource and charge for it.

It should be pretty simple for customers to understand, they are paying for a service of maintenance and support (indirectly funding the development of the core product). That is no different than let's say a WordPress maintenance service to have plugins/themes kept up-to-date by a company.

Worse case, if you really want to give proprietary software to some customers, why not dual-license? Contributions would be made under both AGPL and your proprietary license. This way, it's still open source and potential contributors would be a lot more inclined to become involved.

Anyway, I wish that a compromise can be found where Cloudron still remain a great open source self-hosting option!

https://git.cloudron.io/cloudron/box/issues/654

Interesting, this was simply missed I guess. I have added it now and it will be part of the next release.

It will look like this then:
Screenshot_2019-11-05 Cloudron.png

Hi and welcome on board! The warning you are seeing is, because it is never a good idea to store the backups at the very same disk/server. Ideally those should be stored in some other datacenter or such. For Cloudron the backups also are per-app to allow per-app restore if an update failed or something else is broken. This makes the backup service for the whole server not very useful, nevertheless it is still some safety net of course.

Ideally you should choose between one of the storage providers we currently support https://cloudron.io/documentation/backups/#storage-providers For your case DigitalOcean Spaces might be a good option.