You may be interested in the What's coming in Cloudron 7.0 thread if you haven't seen it.
Notably (imo):
If I recall correctly, it's possible to get a single certificate from letsencrypt that covers several domains. This is promoted by letsencrypt as a way to "work around" the rate limit -- which is enforced per-certificate, not per-domain. Adding this feature to cloudron might be a nice way to prevent hitting the rate limit, especially during a restore operation where many domains are added at once.
For any that remember the bad old days of 90's/00's forums, Discourse' UI is a breath of fresh air to the whole space and forced many existing forum softwares to modernize. (Potentially including this one.) From that perspective, Discourse did the whole online community a great service.
That said, the hosting-difficulty perspective does not lean in favor of Discourse.
@brutalbirdie btw, you can get raw strings from jq directly without having to strip quotes with the -r option:
ID=$(jq -r ".id" CloudronManifest.json)
VERSION=$(jq -r ".version" CloudronManifest.json)
This does one better than just stripping quotes since it will also decode other escaped characters (not that that applies in this case).
Home Assistant / home-assistant.io
Awaken your home
Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.
Pretty awesome application and community. Today I was able to set it up on my Pi3, connected a zigbee usb controller, set up a few light bulbs, and already created scripted automations all within an hour or so. Strikingly straightforward to set up.
I think it would be great if we were able to manage an instance in Cloudron, maybe even on a Pi. I think this would be a great use case for the multi-cloudron feature coming in 7.0.
Home assistant has a Docker-based deployment option; though it also has a bunch of device / hw integrations (zigbee usb controller, for example) which could delay a fully-featured implementation.
@mehdi said in proxyAuth addon:
It's by far the easiest auth system to implement first if you write something custom.
I don't think it is.
I'm just saying that if you can build your app assuming it's behind an authenticating reverse-proxy, it frees you from a LOT of work designing a system to authenticate the user with credentials or whatever. It's just username = request.Headers["X-Forwarded-User"], done. No validation, no encryption, no hmac, no password hashing function, no password storage, no password resets, etc etc etc
I did some searching ("reverse proxy authentication", "header proxy auth"). I offer these examples for your consideration:
Perhaps this solution is more common in enterprise apps. Probably for the security reasons I mentioned before.
There's also RFC 7615 / Proxy-Authenticate on MDN which seems related.
Thoughts?
Edit also:
I think it would be nice if more apps supported the option to switch to proxyAuth+X-REMOTE-USER-based authentication for multi-user apps. I prefer proxy-based auth for a couple reasons:
Of course, all apps may not support this yet, and sometimes you do want a public-facing service, and some apps could never work like this (bitwarden), etc, hence "optional".
I use Roam Research and it's nice for notes, but it's expensive, not self-hosted, and not foss.
There is also Logseq, which is foss roam research alternative that syncs to github that I've tried and like. It's not quite as polished, but it's very new, and imo would be worth it to gain self-hosting. One of the things I was hoping to do when I decided to try cloudron was wrap up logseq into a cloudron app and publish it. But to fully connect the dots here, I'd prefer if it synced to gitea on my cloudron instead which I don't think it currently supports.
If we ever get the code-server app rolling, maybe a combo code-server + foam vscode extension could be interesting here.
I've been struggling with how to pronounce it as well; so far my internal monologue has been settling in the direction of "Andre-a // Git-eh-ah", but stealing the t from git: "Gi-tee-ah". It doesn't sound like it has "git" anymore, but at least there's "tea". Have the devs given any talks on Gitea? I'd rather settle on something instead of sounding it out 4-5 times every time I read it lol
Hi!
I'm interested in using git LFS storage from my gitea app but I'm worried that my server could run out of space with many large files. Gitea supports any s3-like storage as a backend for LFS and attachments (see Gitea Config Cheat Sheet). So, using the gitea app terminal I edited /app/data/app.ini to add the following configuration and restarted gitea from the dashboard:
[server]
LFS_START_SERVER = true
[storage.my-storage]
STORAGE_TYPE = minio
SERVE_DIRECT = true
MINIO_ENDPOINT = s3.us-west-001.backblazeb2.com
MINIO_ACCESS_KEY_ID = {secret-id}
MINIO_SECRET_ACCESS_KEY = {secret-key}
MINIO_BUCKET = my-bucket
MINIO_LOCATION = us-west-001
MINIO_USE_SSL = true
[lfs]
STORAGE_TYPE = my-storage
[attachment]
STORAGE_TYPE = my-storage
MAX_SIZE = 50
And it seems to work, great! Yes, I'm actually using backblaze b2, because it's much more cost efficient than amazon's service. Yay compatibility!
/app/data/app.ini the correct place to add gitea custom configurations?
@girish said:
do you know if these extensions are run in-process or out of process?
Looking through the extensions it appears all of them are defined as separate docker containers, so "separate process". I think Matrix's general strategy is to allow plugging in to the server via api, instead of modifying the server itself.
I'd be interested in all the bridges, though there are a lot. If we're not careful, we'll have 20+ apps just for matrix. 
Thanks @girish, I created a feature request here!
@scooke, Cloudron would know when the user switches DNS configurations when they choose a different provider on the "Domains & Certs" settings page for their domain.
@nebulon said:
we don't overwrite existing DNS records, if they were not setup by Cloudron as such, to mitigate the risk of breaking a mixed setup.
That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite?
I recently encountered some issues after I switched from wildcard DNS configuration to provider-based automatic DNS configuration.
When you create an app with provider-DNS configured, cloudron will use your provider's API to automatically create the DNS subdomain record to point to your server so cloudron can serve the app. But if you create the app while you have wildcard DNS configured, no specific subdomain will be created. This is expected.
However, if you create the app under wildcard-DNS, then switch to provider-DNS, then the subdomains that would normally have been created when running under provider-DNS are not created automatically when switching between DNS configurations. This can cause a problem when the user deletes their wildcard DNS record because they assume that Cloudron will use provider-DNS to provision DNS entries for all apps.
I propose that Cloudron add a feature to check the DNS entries and reprovision DNS records as required when the user switches DNS configurations. I could imagine this could be implemented by triggering automatically as soon as the user switches DNS configurations, or as a button on the dashboard to recheck that dns entries for all apps are correctly assigned (including my.).
I started my configuration out with wildcard setup, but then decided to switch to provider-based dns after installing a couple apps. Then I deleted the wildcard DNS record and tried to use the apps...
These are two minor issues which I was able to solve, but which I didn't see explicitly noted anywhere.
https://ip and done... something else on the dashboard. (Maybe save on the domain page?)I think it would be neat if Cloudron performed these steps automatically when switching from wildcard to provider-based dns.
It seems to be a v2/v3 split. From https://github.com/kerberos-io/opensource/blob/master/README.md (emphasis mine)
Kerberos Open source (v3) is a cutting edge video surveillance management system made available as Open Source under the MIT License. This means that all the source code is available for you or your company, and you can use, transform and distribute the source code; as long you keep a reference of the original license. Kerberos Open Source (v3) can be used for commercial usage (which was not the case for v2). Read more about the license here.
To me (IANAL, etc) it seems the license shouldn't be a particular problem as long as it's based on v3.
@plusone-nick said in Proposal: Free-Tier Alterations 
:
It was more of a "its the free tier so its their problem to deal with" proceed at your own risk but fully rethinking it again that might be a good recipe for disaster, leaving people out to dry.
I'm glad you came around, this is definitely the better way to think about it. Sure, the license terms may say that you're on your own, no support etc; but users don't interact with license terms, they interact with your product. If someone has a bad time because of choices you enabled them to make with your product, somebody has to pay something ($, time, ...) to fix it, be it staff, the community, or even the product's reputation. I hope the team avoids going into future-support-debt in exchange for a short-term growth spurt.
I'm not sure I'd want fancy, distributed filesystems on by default for most apps. I feel like most apps would need custom changes to explicitly support distributed storage, and I'm skeptical that a blanket drop-in distributed-fs solution could meet the performance and reliability needs of the diversity of cloudron users.
I'd rather have multi-node app management than distributed app runtime. Manage all your cloudron nodes and assign apps between them, migrate them etc, but most apps can still only be deployed to one cloudron instance at a time. At least I think this would be a better scaling/ha goal for a v1 implementation.
@imc67 I think password changes would require the user to always type in their old password. The password-derived key could be used to encrypt a second, randomly generated key that is the actual key for encrypting emails, that way a password change would only require re-encrypting the random key, not the whole mailbox. Password resets by admin would be impossible unless you did something like encrypt the old key with a key derived from the admin's password too.
What about this: self-host your email storage & webmail, but have a cloudron running on a $5 vps that acts purely as a personal SMTP relay with pinned IP. Emails are never stored on disk, so at most a spying host can only see new correspondence as it flows. (Not perfect, but it's an improvement on just giving up.) Can cloudron be configured as an email relay for another cloudron? It would be nice if you could do that with the free version.